J'ai souvent entendu dire que les objets n'avaient pas été livrés en termes de réutilisation de code. Êtes-vous d'accord? Si vous croyez qu'ils ne l'ont pas fait, pourquoi pas?

Non pas forcément.

Les objets offrent une meilleure sémantique, une meilleure organisation du code / des fonctionnalités et, éventuellement, une facilité d'utilisation.

Des bibliothèques bien conçues tiennent la promesse de réutilisation du code, pas des objets en soi.

Honnêtement, je ne suis pas sûr que la "réutilisation du code" soit vraiment ce que quiconque recherche (ou du moins, devrait rechercher). Ma philosophie est «composants logiciels», ce qui signifie une meilleure maintenabilité grâce à de bonnes interfaces et en évitant les couplages inutiles. La «réutilisation du code» est l'une des choses qui en découle parfois - du code inutilement dupliqué est un signe que vous avez organisé les choses de la mauvaise façon et bien sûr, c'est une douleur à maintenir.

Pour répondre un peu plus directement à la question, il existe une collection de très bons outils pour éviter de se répéter: héritage, traits, délégation, fonctions d'ordre supérieur, etc. Parmi ceux-ci, les gens ont tendance à confondre l'héritage avec OO dans son ensemble - et ils ont aussi tendance à en abuser un peu, si vous me demandez. C'est peut-être de là que vient une partie de l'ambiance "OO sucks": trouver un héritage coincé là où il n'a pas le droit naturel d'être :)

Non, les "objets" n'ont pas rendu la réutilisation du code plus facile ni plus courante. Les mêmes préoccupations qui empêchent le code d'être réutilisé dans un programme modulaire (la conception, le test et la documentation d'une API à usage général nécessitent beaucoup plus d'efforts initiaux que l'écriture d'une routine ponctuelle, et le jack de tous les métiers peut être le maître de rien - la logique destinée à être réutilisée n'est peut-être pas bien optimisée pour les utilisations auxquelles elle est réellement destinée) s'applique aux programmes OO, avec la préoccupation supplémentaire qu'un modèle d'objet mal conçu peut entraver la réutilisation de sinon réutilisables code.

OO est une abstraction pratique pour de nombreux problèmes, mais méfiez-vous du battage médiatique des années 80 et 90: il ne résout pas par magie les problèmes fondamentaux de notre métier pas plus qu'il ne vous fait de gaufres pendant que vous dormez.

Je ne m'attends pas à ce que TOUS les objets soient réutilisés, mais nous avons beaucoup d'objets que nous réutilisons sur de nombreux projets différents. Nous avons également des objets qui ne sont réutilisés que sur un seul projet. Nous consommons souvent les mêmes objets métier (ou objets de transfert de données) ainsi que des objets de logique métier à partir d'une application de bureau Click-Once, d'une application Web et d'une application téléphonique, le tout pour le même projet.

Où avez-vous entendu dire que OO ne permet pas de réutiliser? Et quel était le raisonnement? Peut-être que la conception de leurs objets les a forcés dans cette situation ...

Certains programmeurs copient et collent dans n'importe quelle langue et style.

De très bons programmeurs peuvent éviter la plupart des copier-coller dans presque toutes les langues.

Je trouve que les modèles OO ont tendance à encourager la réutilisation. J'ai vu du code Java écrit dans un style non OO (où les données étaient séparées du code en raison d'un ORM merdique) et la réutilisation était vraiment misérable - mais dans OO, les mêmes programmeurs ont fait un meilleur travail de conception ( et réutilisation).

Également dans les cas où nous utilisons des modèles non oo ou des anti-patrons oo tels que des setters / getters, des instructions switch, des classes internes anonymes, des fonctions énormes et autres, j'ai vu la réutilisation du code diminuer et le passe-partout augmenter ... de manière significative.

ps. Je sais que les gens auront des problèmes avec le paragraphe précédent, alors je vais vous expliquer un peu.

Les setters et les getters causent des problèmes OO car ils vous permettent d'opérer sur les membres d'un objet (un objet doit manipuler ses membres OWN) Cela distribue le code qui opère sur votre classe à travers d'autres classes vous obligeant à copier la fonctionnalité autour du setter / getter . Cela s'applique également aux propriétés - le simple fait que les propriétés soient plus faciles ne les rend pas «bonnes» dans toutes les situations.

Le code des classes internes anonymes ne peut pas du tout être réutilisé et les gens oublient que beaucoup de choses (comme les écouteurs) peuvent et doivent être des classes à part entière - cela s'applique également aux fermetures! Si vous avez utilisé une classe interne anonyme pour implémenter quelque chose comme un écouteur, vous êtes beaucoup plus susceptible de simplement copier et coller votre implémentation que d'extraire le code dans une méthode ou sa propre classe et de l'appeler à la place. Les fermetures peuvent également améliorer la réutilisabilité - tout dépend de la façon dont vous les utilisez.

Dans de nombreux cas, les fonctionnalités disponibles déterminent la façon dont vous structurez votre code. OO est encore plus puissant lorsqu'il s'agit de vous aider à visualiser tout votre code et comment il interagit, mais c'est une autre question.

Les objets n'ont pas plus de capacité à fournir une réutilisation de code qu'un monte-escalier ou un autre équipement de fitness peut entraîner une perte de poids. Les développeurs doivent être motivés à utiliser correctement les outils.

Une fois que les équipes logicielles accordent une plus grande valeur à la réutilisation du code testé qu'à la conservation de tous les détails dans leur tête, vous verrez des objets et des méthodes bien plus fins et donc plus de réutilisation du code.

Oui

La POO vous donne plus de façons de réutiliser le code

Non

il n'y a pas de solution miracle

Ça dépend

sur ce que vous y mettez et ce que vous attendez en retour!

Oui. Une bonne programmation orientée objet favorise la séparation des préoccupations, un faible couplage, une forte cohésion et la dissimulation d'informations. Ces éléments sont tous essentiels au code réutilisable.

Je dirais que le principal avantage de la POO est la modularité et la modifiabilité, plutôt que la réutilisation, mais c'est une autre question.

Les objets permettent de poursuivre le code, mais en tant que tel, ce n'est pas la technique la plus appropriée. Je pense que la réutilisation du code est favorisée par des techniques liées aux objets telles que l'héritage, le polymorphisme, la surcharge et les modèles.

Oui, ils le font, la possibilité d'étendre (hériter) d'une super classe contribue clairement à la réutilisation du code, je ne sais pas comment quelqu'un pourrait argumenter autrement. Vous pouvez simplement étendre une classe et remplacer une méthode, tout en utilisant le reste de la super classe, si cela ne facilite pas la réutilisation du code, je ne sais pas ce qui est

S'ils l'ont jusqu'à présent tenu leur promesse de réutilisation du code? Oui, si les programmes écrits avec OOP à l'esprit appliquent judicieusement les modèles de conception. Sinon, la plupart du temps non. Mais en regardant la popularité des programmes non triviaux à grande échelle que les systèmes Adobe, Google et similaires écrivent avec C ++ ou Java ou d'autres langages OOP, je dirais que OOP a un long chemin à parcourir avant de disparaître. Ce moment sera bien mieux adapté pour poser cette question et pourrait aider à préparer le terrain pour un nouveau paradigme.