La POO elle-même n'a pas beaucoup changé depuis sa création. Quelques nouveaux angles ont été explorés, mais les principes fondamentaux restent les mêmes. Au contraire, les connaissances collectives accumulées au fil des ans rendent la vie du programmeur plus facile que compliquée. Les modèles de conception ne sont pas un obstacle; ils fournissent une boîte à outils de solutions aux problèmes standard, distillés par des années et des années d'expérience.
Alors, pourquoi percevez-vous la POO aujourd'hui plus complexe que lorsque vous avez commencé à l'utiliser?
L'une des raisons peut être que le code auquel vous êtes exposé devient plus complexe - non pas parce que la POO est devenue plus complexe, mais parce que vous avez progressé dans l'échelle d'apprentissage et que vous devez lire des bases de code plus grandes et plus complexes.
Une autre raison peut être que, même si le paradigme de la complexité n'a pas changé, la taille et la complexité d'un projet logiciel moyen peuvent très bien avoir. Avec une puissance de traitement disponible sur les téléphones portables de niveau client qui aurait été un rêve fou pour un développeur sur un serveur il y a moins de deux décennies, le grand public s'attend en gros à une interface graphique animée épurée, même pour l'application la moins chère, et à des ordinateurs de bureau d'entrée de gamme plus puissants. qu’un "superordinateur" des années 1980, il est tout à fait naturel que la barre ait été relevée depuis les débuts de Smalltalk et de C ++.
Et puis, il y a le fait que dans les applications modernes, la concurrence et le parallélisme sont la norme plutôt que l'exception, et les applications ont souvent besoin de communiquer entre différentes machines pour générer et analyser tout un zoo de protocoles. Bien que la POO soit un excellent paradigme organisationnel, elle a ses limites, comme tout autre paradigme: par exemple, elle ne fournit pas beaucoup d’abstraction pour la concurrence (la plupart des implémentations étant plus ou moins une réflexion ultérieure, ou totalement externalisées aux bibliothèques). , et ce n’est pas la meilleure approche possible pour construire des analyseurs syntaxiques et transformer des données. La programmation moderne rencontre fréquemment les limites du paradigme de la programmation orientée objet et les modèles de conception ne peuvent vous mener que loin. (Personnellement, Je considère que le fait que nous ayons besoin de modèles de conception en est un signe: si le paradigme fournissait ces solutions immédiatement, il serait plus expressif pour ces problèmes et les solutions standard seraient évidentes. Il n'y a pas de modèle de conception permettant de décrire l'héritage de méthode, car il s'agit d'une fonctionnalité essentielle de la programmation orientée objet; mais il existe un modèle d'usine, car la POO ne fournit pas un moyen naturel évident de construire des objets de manière polymorphe et transparente.)
De ce fait, la plupart des langages POO modernes intègrent des fonctionnalités issues d'autres paradigmes, ce qui les rend plus expressifs et plus puissants, mais également plus complexes. C # en est le principal exemple: il a des racines évidentes de POO, mais des fonctionnalités telles que les délégués, les événements, les types de données variantes, les attributs, les fonctions anonymes, les expressions lambda, les génériques, etc., sont issues d'autres paradigmes, notamment de la programmation fonctionnelle. .