Les algorithmes décrivent ce que l'ordinateur doit faire. La structure décrit comment l'algorithme est présenté [dans le code source]. La POO est un style de programmation qui exploite certaines structures "orientées objet".
Les livres d'algorithmes évitent souvent la POO car ils sont axés sur l'algorithme, pas sur la structure. Les fragments de code qui dépendent fortement de la structure ont tendance à être de mauvais exemples à mettre dans un livre d'algorithmes. De même, les livres OOP évitent souvent les algorithmes car ils encombrent l'histoire. Le point de vente de la POO est sa fluidité, et son rattachement à un algorithme le rend plus rigide. Il s'agit plus de l'objectif du livre qu'autre chose.
Dans le code réel, vous utiliserez les deux côte à côte. Vous ne pouvez pas résoudre les problèmes informatiques sans algorithmes, par définition, et vous aurez du mal à écrire de bons algorithmes sans structure (POO ou autre).
Comme exemple de flou, prenez la programmation dynamique. Dans un livre d'algorithmes, vous décririez comment prendre un ensemble de données homogène dans un tableau et utiliser la programmation dynamique pour arriver à une solution. Dans un livre OOP, vous pouvez rencontrer une structure telle que Visitor, qui est un moyen de faire des algorithmes arbitraires sur un ensemble d'objets hétérogènes. L'exemple de livre DP pourrait être considéré comme un visiteur très simple opérant sur des objets dans un ordre généralement ascendant. Le modèle des visiteurs pourrait être considéré comme le squelette d'un problème de DP, mais sans la viande et les pommes de terre. En réalité, vous constaterez que vous avez souvent besoin des deux à la fois: vous utilisez le modèle Visitor pour gérer l'hétérogénéité de votre ensemble de données (DP est mauvais à cela) et vous utilisez DP dans la structure de Visitor pour organiser votre algorithme afin de minimiser le temps d'exécution (Visitor ne fait pas
Nous voyons également des algorithmes fonctionner au-dessus des modèles de conception. Il est plus difficile d'exprimer des exemples dans un petit espace, mais une fois que vous avez une structure, vous commencez à vouloir manipuler cette structure et vous utilisez des algorithmes pour le faire.
Y a-t-il des problèmes qui ne peuvent être présentés et résolus que par la POO?
C'est une question plus difficile à répondre que vous ne le pensez. Pour la première commande, il n'y a aucune raison de calcul pour laquelle vous avez besoin de la POO pour résoudre un problème. La preuve simple est que chaque programme OOP est compilé jusqu'à l'assemblage, qui est décidément un langage non-OOP.
Cependant, dans le plus grand schéma des choses, la réponse commence à hésiter vers oui. Vous êtes rarement limité simplement par des méthodologies informatiques. La plupart du temps, il y a des choses comme les besoins de l'entreprise et les compétences des développeurs qui entrent en ligne de compte. De nombreuses demandes ne pourraient pas être écrites aujourd'hui sans POO, non pas parce que la POO est en quelque sorte fondamentale pour la tâche, mais parce que la structure fournie par la POO était essentielle pour garder le projet sur la bonne voie et dans les limites du budget.
Cela ne signifie pas que nous n'abandonnerons jamais OOP à l'avenir pour une nouvelle structure amusante. Il dit simplement que c'est l'un des outils les plus efficaces de notre boîte à outils pour une fraction étonnamment importante des tâches de programmation qui existent aujourd'hui. Les problèmes futurs peuvent nous amener à aborder le développement en utilisant différentes structures. D'une part, je m'attends à ce que les réseaux neuronaux nécessitent une approche de développement très différente, qui peut ou non se révéler «orientée objet».
Je ne vois pas la POO disparaître dans un avenir proche en raison de la façon dont les concepteurs d'algorithmes pensent. À ce jour, le schéma habituel est que quelqu'un conçoit un algorithme qui ne tire pas parti de la POO. La communauté OOP se rend compte que l'algorithme ne correspond pas vraiment à la structure OOP, et n'a vraiment pas besoin de le faire, alors ils enveloppent l'intégralité de l'algorithme dans une structure OOP et commencent à l'utiliser. Considérez boost::shared_ptr. Les algorithmes de comptage de références qui reposent à l'intérieur shared_ptrne sont pas très conviviaux pour la POO. Cependant, le modèle n'est pas devenu populaire jusqu'à ce qu'il shared_ptrcrée un wrapper OOP autour de lui qui expose les capacités des algorithmes dans un format structuré OOP. Maintenant, il est si populaire qu'il est devenu la dernière spécification pour C ++, C ++ 11.
Pourquoi est-ce si réussi? Les algorithmes sont excellents pour résoudre les problèmes, mais ils nécessitent souvent un investissement de recherche initial important pour comprendre comment les utiliser. Le développement orienté objet est très efficace pour encapsuler de tels algorithmes et fournir une interface qui nécessite moins d'investissement initial pour apprendre.