Il est temps de s'éloigner de la POO
La POO est considérée comme le plus gros diamant de la couronne de l'informatique. La meilleure façon d'organiser votre code. La solution à tous les problèmes. Le seul moyen sûr d'écrire nos programmes. Le Dieu de la programmation nous a envoyé d'en haut ... Ce n'est que maintenant que le programmeur POO est obligé de ramasser un tas d'abstractions, de garder une trace de tous les objets partagés, de se souvenir de tonnes de «modèles de programmation» - et de consacrer son temps et son énergie à tout cela au lieu de résoudre le problème lui-même.
Beaucoup ont longtemps critiqué la POO, et il y a beaucoup de programmeurs très respectés parmi ces critiques. Et même Alan Kay - l'inventeur de la POO est dans leurs rangs!
L'objectif principal de tout développeur est d'écrire du code fiable. Si le code est bogué et ne fonctionne pas comme prévu, rien d'autre n'a d'importance. Quelle est la meilleure façon d'écrire un code fiable? Gardez le code simple. La simplicité est le contraire de la complexité . Il s'ensuit que l'objectif principal du développeur est de réduire la complexité du code.
Avertissement:
je ne suis pas un fan de la POO, il n'est donc pas surprenant que cet article semble biaisé pour beaucoup. Cependant, je donnerai des arguments pour défendre ma position.
Je comprends également très bien que la critique de la POO est très douloureuse pour beaucoup. Tant de lecteurs se sentiront personnellement offensés. Cependant, j'ai l'intention de dire ce que je pense être correct. Car mon objectif n'est pas d'offenser, mais de signaler les problèmes de la POO. Je ne critique pas
la POO d'Alan Kay . C'est généralement un génie. Personnellement, j'aimerais que la POO soit exactement ce que voulait Alan Kay. Ce que je critique, c'est la POO dans une implémentation C # ou Java.
Le problème est que la POO a longtemps été considérée comme la norme pour l'organisation du code logiciel. Et tant de gens pensent, y compris ceux qui occupent des postes sérieux dans l'industrie du logiciel, c'est pourquoi d'autres approches de programmation ne sont même pas envisagées dans la plupart des entreprises.
J'ai dû surmonter beaucoup de difficultés lorsque j'écrivais en langues POO. Et je me suis toujours demandé pourquoi ces difficultés surgissaient. Peut-être que je n’étais pas trop bon? Peut-être que j'avais besoin d'apprendre quelques douzaines de "modèles de programmation" supplémentaires? En fin de compte, je n'avais tout simplement plus la force pour tout ça.
Cet article vous racontera le voyage de dix ans que je suis passé de la POO à la programmation fonctionnelle. Depuis, je ne me souviens plus d’un cas où je suis tombé sur un projet pour lequel la POO conviendrait le mieux. De plus, les projets où la POO était utilisée tombaient sous le poids de la complexité du code - à partir d'un certain point, il était impossible de les maintenir et de les développer davantage.
TLDR
"Les programmes orientés objet sont l'alternative aux bons programmes."
Edsger W. Dijkstra, pionnier de l'informatique
Le but de la POO en était un: faire face à la complexité du code de procédure. En d'autres termes, la POO a été conçue pour améliorer l'organisation du code. Mais depuis lors, rien ne prouve que la POO soit meilleure que l'ancienne programmation procédurale.
La dure vérité est que la POO n'a pas fait la seule chose pour laquelle elle avait été conçue. Tout avait l'air bien sur le papier - nous avions des hiérarchies strictes d'animaux, de chiens, de personnes ... (et, bien sûr, des formes: rectangles, carrés et cercles - où pouvons-nous aller sans eux!) Mais à mesure que la complexité du code d'application augmentait, la POO n'a pas aidé à la réduire , mais au contraire augmenté - avec des tonnes de "modèles de programmation" nécessaires et il est difficile pour le programmeur de suivre où et comment les valeurs des variables changent. La POO a rendu de nombreuses procédures couramment utilisées, telles que la refactorisation et les tests, inutilement complexes.
Beaucoup de gens ne sont pas d'accord avec moi, mais le fait est que la conception de la POO en C # ou Java n'a pas été scientifiquement pensée, ce n'était pas le résultat de recherches scientifiques sérieuses. Contrairement à la programmation fonctionnelle, par exemple, dans Haskell, où le calcul lambda est une base théorique solide. La POO n'est pas basée sur quelque chose comme ça.
Dans les petits projets, la POO fonctionne assez bien. Mais que se passe-t-il lorsque le projet se développe? La POO est une bombe à retardement qui explose inévitablement lorsque le code du projet atteint une certaine taille. Les projets commencent à prendre du retard, les délais échouent, les développeurs sont à court d'énergie et l'ajout de nouvelles fonctionnalités devient presque impossible. En fin de compte, les entreprises sont obligées de marquer ce code comme «obsolète» et obligent les développeurs à réécrire.
La POO ne correspond pas très bien à la façon dont notre cerveau pense. Nous avons l'habitude de nous concentrer sur l'action: faire une promenade, parler à un ami, manger de la pizza. Notre cerveau a évolué vers «faire quelque chose», et non vers la construction d'une hiérarchie complexe d'objets abstraits.
Le code POO est non déterministe (contrairement à la programmation fonctionnelle): nous ne pouvons pas être sûrs qu'avec les mêmes données d'entrée, nous obtiendrons le même résultat à chaque fois. Cela rend très difficile la compréhension du fonctionnement du programme. Voici un exemple simple: comparez 2 + 2 et calculatrice.Ajoutez (2, 2) . La dernière expression, en théorie, doit toujours renvoyer 4, mais elle peut renvoyer 5, 3 ou même 1004, car les dépendances de l'objet Calculator peut changer son comportement de la manière la plus imprévisible.