Inconvénient de la POO ?

Question

En général, je ne veux pas connaître les détails des inconvénients des POE, mais j'ai ressenti une certaine bizarrerie lors d'un entretien auquel j'ai participé récemment. La question qui m'était posée était de me dire un inconvénient des la programmation orientée objet (POO). À l'époque, j'estimais que la POO était le niveau de programmation le plus abouti après les modèles procédural et fonctionnel. Je lui ai donc répondu que je ne voyais pas du tout d'inconvénients.

Mais l'interlocuteur a dit qu'il y en avait peu, et je lui ai demandé d'en citer une, si cela ne le dérange pas. Il a donné un exemple que je ne digère pas bien. Il a dit qu'un modèle de POO n'implémente pas strictement les règles d'héritage et a cité l'exemple du satellite/de la fusée où les parties du corps se désintègrent périodiquement pour enlever du poids pendant le lancement de la fusée et a dit que l'héritage ne supporte pas cela.

Son exemple m'a semblé très bizarre, la raison étant l'application de l'héritage à cet exemple.

Je comprends que l'exemple qu'il a donné n'avait pratiquement aucun sens, mais j'avais ce doute -

Peut-on débrancher les hiérarchies de classes dynamiquement (je suis assez confiant que ce n'est pas possible en Java) dans une conception orientée objet ?

Answer 1

Juste parce que vous avez un marteau, ne veut pas dire que tout est un clou.

J'ai constaté que beaucoup de gens confondent souvent quand il faut appliquer composition vs. héritage quand on utilise la POO comme style de programmation. L'exemple que vous citez dans la question de l'entretien semble être un cas de ce type de confusion.

Une chose que j'ai apprise avec l'expérience, c'est que si l'héritage est un paradigme agréable pour exprimer les relations "IS-A" entre les entités dans une conception, il est souvent préférable de privilégier la composition plutôt que l'héritage .

Mais examinons le cœur de la question de l'interviewer : Quand la POO est-elle un bon choix de paradigme ? .

La POO fonctionne mieux avec les projets à grande échelle, multi-développeurs et multi-modules. Pour " développement dans les petites "Mais même dans ces cas, à moins que vous n'écriviez du code jetable, je pense que les grandes solutions évoluent souvent à partir de petites solutions. Mais même dans ces cas-là, à moins que vous n'écriviez du code à jeter, je dirais que les grandes solutions évoluent souvent à partir de petites, et que l'établissement d'une structure et d'une séparation des préoccupations dès le départ peut vous épargner des soucis plus tard.

En fin de compte, la programmation OOP exige également un certain niveau de rigueur et de planification de la conception, ainsi qu'une compréhension de la principes fondamentaux de l'orientation objet . Si vous n'êtes pas disposé à prendre le temps d'étudier et de comprendre ces principes ... alors peut-être que la programmation OOP n'est pas pour vous.

En outre, certains types de problèmes se prêtent également à des styles de programmation alternatifs. Par exemple, le traitement transformatif est tout à fait ammendable aux style de programmation fonctionnel - dans laquelle un résultat est calculé et transmis à des étapes de transformation successives pour produire un résultat final. Les problèmes pour lesquels vous devez rechercher ou interroger un domaine pour obtenir certaines informations correspondantes sont adaptés à la méthode suivante langages de requête (comme SQL) dans laquelle vous décrivez votre intention de manière déclarative plutôt qu'impérative.

La capacité à reconnaître le type de problème à résoudre permet de choisir le langage ou l'outil à utiliser. Les bons outils peuvent rendre un travail beaucoup plus facile... mais les mauvais peuvent le rendre plus difficile, voire impossible.

Answer 2

Je ne comprends pas bien son exemple.

Cependant, il est important de comprendre que la POO est très efficace pour les choses qui peuvent être modélisées naturellement avec elle, et est très inefficace pour d'autres choses (par exemple, les préoccupations transversales ou les aspects). C'est l'un des inconvénients de la POO. Un autre est qu'elle entraîne souvent un coût d'exécution dû à la répartition dynamique.

De plus, il est très facile d'abuser de la POO pour faire des abstractions insensées. Le fait qu'une fusée hérite d'un corps en est un exemple. D'après mon expérience, les développeurs novices soit ne font pas confiance à l'héritage et ne l'utilisent pas, soit sont trop enthousiastes et l'utilisent de manière incorrecte, alors que d'autres comportements (comme l'agrégation) sont plus appropriés. Avec le temps, l'expérience et la compréhension du mécanisme s'améliorent.

Je ne suis pas sûr de ce qu'il voulait dire par "le modèle de POO n'implémente pas strictement les règles d'héritage", puisque la POO n'est pas un modèle. Un problème potentiel est que l'on peut écrire un sous-type qui peut violer le principe de substitution de Liskov, de sorte qu'une méthode de surcharge ne se comporte pas "au moins" comme la méthode de surcharge. Il n'y a aucun moyen de vérifier automatiquement cela, il est donc possible d'écrire du code qui viole les principes de la POO.

Quant à votre dernière question "Peut-on débrancher les hiérarchies de classes dans une conception idéale orientée objet ?", je ne suis pas sûr de ce que vous voulez dire ici. Si vous demandez de modifier la hiérarchie au moment de l'exécution, et de faire en sorte qu'une relation de sous-typage n'existe plus à partir d'un certain point de l'exécution, alors oui. C'est possible avec certains langages tels que Smalltalk. Certains diront que c'est "plus de POO". Dans Smalltalk, les "méthodes" supportées par un type sont déterminées au moment de l'appel de la méthode sur la base de la hiérarchie actuelle et du contenu actuel de chaque classe. Bien que j'adore smalltalk, c'est une fonctionnalité dont je ne suis pas fou, car je préfère la vérification au moment de la compilation avec moins de surprises au moment de l'exécution.

Answer 3

Bien que je sois d'accord avec la conclusion de l'interviewer (la POO est défectueuse), sa logique semble être un non-sens. On dirait qu'il critique quelque chose qu'il ne comprend pas, car aucun programmeur OO compétent ne ferait hériter une fusée de ses propulseurs.

Les gens ont fait de bonnes critiques contre la POO, cependant. Par exemple, l'article de Steve Yegge L'exécution au royaume des noms .

Answer 4

Son exemple n'a aucun sens. Une fusée n'hérite pas d'un corps. Elle "a" un corps. C'est le confinement. Donc à un moment donné, vous "supprimez" la partie attachée à la fusée lorsqu'elle est larguée.

Answer 5

Bien que je ne comprenne pas entièrement l'exemple donné, comme il ressemble à une composition pour moi, je vais donner un inconvénient de la POO.

OO est difficile à tester

• Pas d'accès direct aux variables/attributs de classe en lecture/écriture - il peut être nécessaire d'introduire des getters et seeters, ce qui rompt l'incapsulation.

• L'héritage peut modifier le comportement d'une méthode dans une sous-classe.

• Les objets ont un état. Il peut être difficile de générer ces états car nous dépendons de l'interface publique.

• Les classes avec une cohésion loh peuvent être difficiles à tester car cela pourrait signifier que la classe fait plus que ce qui est spécifié.