Code de procédure vs code OOP

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?

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é.

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.

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.

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.

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.

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.

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.

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.