Décès de la technologie OOP [fermé]

J'ai entendu de nombreuses fois parler de la programmation orientée vers l'aspect, surtout que c'est la technologie de "prochaine génération" dans la programmation et qu'elle va "tuer" la POO.

Est ce juste? La POO va-t-elle mourir ou quelle peut être la raison de cela?

Chaque fois que quelqu'un vous dit qu'une technologie logicielle en tuera une autre ou dominera l'ensemble du marché / de l'utilisation / du public, n'oubliez pas ceci:

Un écosystème sain (dynamique mais stable) est composé d'une variété d'espèces très différentes.

Cela signifie que toute nouvelle technologie hyped passera par la courbe de battage médiatique et trouvera finalement son objectif spécifique à travers le temps et l'expérience avec elle.

Cela signifie également qu'un concept aussi extrême que la programmation orientée aspect est utile s'il est nécessaire, ce qui signifie, pas toujours et pas très souvent, en raison des coûts implicites.

Mais il a déjà sa place, comme la programmation OOP, comme la programmation générique, comme la programmation fonctionnelle, comme la programmation procédurale, etc.

Avez-vous remarqué que les langues les plus utilisées (et controversées) et largement répandues dans la vie réelle ne sont "pas pures"? C'est parce que permettre plusieurs paradigmes les rend plus flexibles pour changer de contexte au fil du temps et ils remplissent plus de niches d'utilisation.

OOP ne va pas mourir à cause d'AOP. AOP ajoute de la valeur, mais il vit en parfaite coexistence avec OOP. Je ne pense pas non plus que la programmation fonctionnelle tue la POO. La POO convient trop bien à de nombreux types de domaines problématiques, il ne serait pas logique de la remplacer par le paradigme fonctionnel.

Les paradigmes vont et viennent, mais le code hérité est éternel. Il y aura toujours du code C ++ à maintenir, donc la POO ne disparaîtra jamais complètement.

Réponse courte: Non, je ne pense pas.

Réponse plus longue: D'après ce que je comprends d'AOP, ce n'est pas un paradigme de programmation en soi (comme dans, il ne remplace pas la POO), mais plutôt un ajout, une boîte à outils qui vous aide à écrire des méthodes plus courtes, des classes plus simples et à responsabilité unique , etc. Mais cela ne remplace pas la POO.

La chose qui remplace (ou au moins en partie) la POO est la programmation fonctionnelle, qui est en réalité un paradigme de programmation différent (bien qu'il puisse être mélangé avec la POO, par exemple dans le langage de programmation Scala ). Il préfère les infrastructures de données immuables et toutes sortes de fonctionnalités sophistiquées qui ont tendance à frustrer les développeurs OOP, en particulier en ce qui concerne la concurrence.

On parle moins de POO ces jours-ci, car il est supposé être l'approche de facto dans de nombreuses situations. L'AOP n'a jamais démarré comme n'importe quel type de mouvement de masse.

Je me souviens d'avoir entendu parler de la programmation orientée aspect pour la première fois dans un tutoriel OOPSLA '97. Ils ont dit que cela allait tuer OO à l'époque. Depuis lors, OO n'a fait que croître au-delà des attentes les plus folles. L'AOP est encore à peine connu et n'a pratiquement aucun impact sur l'industrie informatique. Je pense que la réponse est évidente: AOP n'est pas un tueur d'OO.

Regardez certains systèmes AOP existants. Ils dépendent du fait que vous ayez du code écrit sous une forme quelconque - par exemple, Spring AOP dépend de la définition de vos méthodes sur une classe. Castle Windsor le prend en charge en C #, qui est un langage orienté objet.

Vous pourriez théoriquement passer de la programmation orientée objet à la programmation structurée tout en conservant la programmation AOP, mais en pratique, ce serait difficile. Il est facile de sous-classer quelque chose, de remplacer la méthode appropriée pour appeler les filtres avant / après appropriés et de le transmettre dans le processus d'injection de dépendance.

Il est extrêmement difficile de réécrire des appels de méthode statique pour acheminer vers une méthode de trampoline conçue pour appeler les filtres définis par l'utilisateur.

Donc, d'un point de vue d'implémentation commun, AOP nécessite OOP.

Bien que la POO ne soit certainement pas une solution miracle, la même chose peut être dite pour la POA. Il prend en charge la conception basée sur les composants, mais dans le schéma plus large, vos composants sont les nouveaux objets et les interfaces des composants sont fondamentalement une liste transactionnelle de méthodes, ce qui n'est PAS vrai POO.

De plus, l'AOP et la conception basée sur les composants prennent en charge un modèle de données anémiques, dont les gens plus intelligents que moi-même sont critiqués.

http://martinfowler.com/bliki/AnemicDomainModel.html

(Je sais que l'article ci-dessus est ancien, mais étonnamment pertinent)

L'essentiel est que les systèmes AOP sont là pour rester mais ils sont loin d'être parfaits également. Aucun système n'est parfait.