Code de procédure vs code OOP

19

J'ai terminé un projet en PHP de plus de 13 000 lignes en style procédural [parce que je le connais très bien, bien que je connaisse la POO], et le projet fonctionne parfaitement.

Mais dois-je le convertir en POO? [ parce que le monde est occupé avec la POO ]

Mon code n'a besoin d'aucune des fonctionnalités de la POO [encapsulation, héritage essentiellement ...]!

Donc qu'est ce que je devrais faire?

Et quel genre d'aide j'obtiendrai si je le convertis en POO?

Sourav
la source
21
Veuillez nous tenir informés si vous devez modifier ce projet. Il serait intéressant de savoir si vous êtes content d'avoir pris cette décision ou si vous le regrettez.
JeffO
2
Vous avez besoin d'encapsulation. OO est une façon de l'obtenir; peut-être en avez-vous un autre qui fonctionne pour vous, mais d'une manière ou d'une autre, vous devez contrôler les dépendances du code.
Marcin
Que diriez-vous d'une anecdote pour vous: il y a quelques années, j'ai travaillé sur une application web de taille moyenne écrite principalement en JavaScript (ne demandez pas). Le style de codage était largement procédural. Lorsque le projet était presque terminé, je me suis trouvé insatisfait de la façon dont le code a été écrit et j'ai réécrit une partie importante de celui-ci dans OOP-JavaScript. Cela a retardé la réalisation du projet et nous avons fini par faire relativement peu d'entretien sur le projet par la suite. Je me suis toujours demandé si tout ce codage en valait la peine ;-)
Pandincus
oui ça valait le coup. garder les portes de la réutilisabilité ouvertes en vaut toujours la peine.
Chani
1
La question est: vous attendez-vous à de nouveaux développements? La programmation procédurale est l'approche la plus simple et la plus rapide lorsque vous savez exactement ce dont vous avez besoin et que cela ne changera pas. Toute modification du code procédural sera pénible, dans la POO, ce serait beaucoup plus facile.
Kamil Tomšík

Réponses:

52

Mon code n'a besoin d'aucune des fonctionnalités de la POO

Vous avez répondu à votre propre question - si vous n'avez pas besoin de POO dans ce cas et que votre projet fonctionne, ne le convertissez pas.

Cependant, vous devriez envisager d'utiliser la POO pour votre prochain projet - mais seulement si cela est approprié.

Il n'y a rien de intrinsèquement mauvais avec la programmation procédurale - tant qu'elle est utilisée à l'endroit approprié.

ChrisF
la source
2
+1 d'accord "vous devriez envisager d'utiliser la POO pour votre prochain projet".
Cary Chow
11
+1 oui, si cela fonctionne correctement, ne le corrigez pas.
setzamora
4
Je dirais que si cela fonctionne correctement maintenant, ne le changez pas, mais vous ne savez jamais quelle sera la prochaine demande de fonctionnalité.
JeffO
7
"vous devriez envisager d'utiliser la POO pour votre prochain projet", mais ne l'utilisez que si cela a du sens. Certaines choses sont mieux écrites sur le plan de la procédure, d'autres conviennent mieux à la POO. Utilisez ce qui est approprié.
TMN
@TMN - c'est implicite - je devrais le rendre explicite.
ChrisF
16

Non et pas seulement parce que vous n'avez pas besoin de POO.

Si votre programme est déjà terminé et fonctionne correctement, alors dans plus de 90% des cas, il est inutile de réécrire le code fini pour une raison quelconque.

La POO n'est pas toute puissante, il y a beaucoup d'endroits où la POO ne devrait pas être utilisée, alors ne l'utilisez pas simplement parce que la POO est la tendance.

Skeith
la source
1
Par «code fini», voulez-vous dire que cela fonctionne?
JeffO
@eff O oui monsieur! c'est parfait :)
Sourav
Il a dit qu'il avait terminé le projet et qu'il fonctionnait parfaitement. Pour moi, cela signifie qu'il est soit prêt à être livré au client, soit a été livré au client en supposant qu'il y en ait un. Par fini, je veux dire testé et prêt à être expédié, bien sûr, si des bugs majeurs apparaissent, une réécriture peut entrer en jeu.
Skeith
Veuillez préciser "les nombreux endroits où la POO ne doit pas être utilisée".
Falcon
3
@Falcon, peu importe la qualité de la conception de votre code OOP, mais si le domaine problématique lui-même est mal mappé au modèle OO, votre conception OOP est forcément merdique. Il existe de nombreux domaines problématiques qui ne devraient jamais être exprimés en termes de POO .
SK-logic
8

Mon point de vue général sur les paradigmes (et pourquoi aucun des trois paradigmes majeurs n'est la bonne ou la mauvaise façon de programmer):

La programmation procédurale est bonne lorsque vous avez un problème simple à un niveau élevé (bien qu'il puisse être complexe à un bas niveau) et que vous souhaitez écrire du code linéaire simple et correspondant. Il est sans doute plus facile à écrire et à comprendre que OO et fonctionnel si le problème n'a pas besoin d'être fortement découplé. Exemples: code numérique, la plupart des petits scripts, la plupart des petits sous-problèmes une fois que vous avez décomposé les choses en utilisant OO ou fonctionnel.

Le code orienté objet est bon lorsque vous devez découpler fortement les problèmes car vous pouvez avoir plusieurs implémentations de certains problèmes. Exemple: la plupart des logiciels pour grandes entreprises. Vous pouvez, par exemple, vouloir dissocier fortement la logique métier de la logique de présentation, car ils devront probablement changer indépendamment.

La programmation de style fonctionnel est bonne lorsque vous avez besoin d'une forte séparation du mécanisme de la politique. Avoir une fonction de mécanisme qui accepte une fonction de politique est un bon modèle. (J'ai appris à ce sujet en regardant le module std.algorithm du langage de programmation D.) Le fait d' abstraire l' état mutable à la frontière entre la politique et le code du mécanisme rend généralement l'API plus facile à raisonner. Si l'état mutable est utilisé en privé dans l'un ou l'autre, il s'agit d'un détail d'implémentation. L'autre force de la programmation fonctionnelle est la simultanéité, pour des raisons évidentes.

dsimcha
la source
Merci pour l'excellente réponse décrivant chaque type de paradigme de programmation et fournissant des exemples de quand / comment les utiliser.
Kevin Peno
7

Le code "n'a jamais besoin de POO". Ce sont les programmeurs, dans la mesure où ils sont capables de penser dans différents modes, qui envisagent que tel ou tel problème particulier "nécessite" $ PARADIGM ou soit mieux résolu de cette façon.

Il arrive souvent que les programmeurs qui ne connaissent qu'un seul paradigme pensent que leur paradigme est le meilleur. Une taille unique, et nous devons tous dormir dans le lit de Procrustes, si tel ou tel est actuellement à la mode.

Ingo
la source
5

Vous ne devez convertir votre projet en POO que s'il existe une indication claire de la nécessité de POO. Les scénarios possibles dans lesquels cela peut se produire sont (entre autres):

  • intensifier le projet
  • ajouter plus de développeurs à l'équipe

et même dans ces scénarios, il peut ne pas être nécessaire de convertir votre projet en POO.

Timothy Groote
la source
Bon point, mais pouvez-vous me dire pourquoi il sera difficile de faire évoluer le projet ou d'ajouter plus de développeur dans l'équipe s'il s'agit d'un code procédural?
Sourav
La mise à l'échelle du projet peut impliquer l'ajout de structures relationnelles complexes au modèle d'application, auquel cas, il peut devenir rentable de passer à la POO. Si l'application évolue petit à petit et s'avère à la longue être plus facile à réaliser ou à comprendre dans la POO, les nouveaux développeurs peuvent «rattraper» plus rapidement, si le code est POO. Laisser un héritage de code non OO peut s'avérer être un problème plus tard lorsque le projet s'agrandit. un autre de ces cas où «les choses sont comme elles sont parce qu'elles sont arrivées de cette façon»
Timothy Groote
3
c'est exactement ce qui m'est venu à l'esprit lorsque j'ai lu la question. il dit qu'il a écrit 13 K lignes de code. j'espère qu'il ne sera pas gaspillé en n'utilisant qu'une seule fois. et s'il doit être réutilisé, alors oop deviendrait un must. sinon cela deviendrait un cauchemar pour les nouveaux développeurs
Chani
4

Les deux peuvent être bons, les deux peuvent être mauvais. Mais moderniser l'un pour ressembler à l'autre n'est jamais une bonne idée.

jwenting
la source
2

Si vous repensez à la raison pour laquelle OO a été inventé, vous verrez que vous n'avez pas du tout besoin de OOP, mais parfois cela vous facilite la vie.

À l'époque du codage C, un très gros programme pouvait devenir assez compliqué et difficile à utiliser. Ils ont donc inventé des façons de le diviser en morceaux modulaires. La POO adopte cette approche et la rend encore plus modulaire, en plaçant les données avec ces morceaux de logique de programme afin qu'ils soient encore plus séparés du reste du code.

Cela vous permet d'écrire des programmes de plus en plus gros, sûr que vous avez plutôt changé votre énorme éléphant d'une tâche en une centaine de tâches de la taille d'une souris. Le bonus supplémentaire est que vous pouvez prendre certaines de ces «souris» et les réutiliser dans d'autres programmes!

Bien sûr, le monde réel n'est pas tout à fait comme ça, et la réutilisation des objets n'a jamais tout à fait pris dans la façon dont il était prévu, mais cela ne signifie pas que c'est un paradigme inutile.

Ce qui est inutile, c'est une dépendance excessive à l'égard de l'un ou l'autre style de codage. Quiconque fait OO avec mille petites classes insignifiantes ne le fait pas vraiment bien - il se fait un cauchemar de maintenance pour lui-même (ou pour quelqu'un d'autre). Quiconque écrit une demande procédurale qui ne comporte que 3 fonctions rend également la vie difficile. Le meilleur moyen est le sol de taille moyenne, les objets de grande taille (parfois appelés composants, où nous semblions aller une fois) qui peuvent fournir une bonne quantité de code et de données autonomes qui sont beaucoup plus susceptibles d'être réutilisés indépendamment du reste de votre application.

Mon conseil pour la prochaine fois: essayez d'écrire votre code procédural habituel, mais créez un seul objet de votre structure de données principale. Voyez comment vous trouvez qu'il est plus facile de travailler avec que de transmettre des données d'une fonction à l'autre.

gbjbaanb
la source
0

Mon code n'a besoin d'aucune des fonctionnalités de la POO [encapsulation, héritage essentiellement ...]!

Comment sais-tu ça?

Avez-vous besoin de maintenir ce projet? Y a-t-il de nouvelles fonctionnalités prévues? Y aura-t-il d'autres personnes qui développeront avec vous? Vous êtes-vous répété? Le code est-il difficile à saisir?

Si la réponse est "oui", alors vous devriez peut-être commencer à penser à mettre en place un squelette OOP et à suivre cette voie.

vihus
la source