Quel est le point de la programmation orientée objet?

dans mon expérience de révision du code et de la conception des projets que j'ai traversé, la valeur de OOP n'est pas pleinement réalisé parce que beaucoup de développeurs ont pas correctement conceptualisé le modèle orienté objet dans leurs esprits. Ainsi, ils ne programment pas avec OO design, très souvent en continuant à écrire du code procédural descendant faisant des classes un joli plat design. (si vous pouvez même appeler ce "design" en premier lieu)

il est assez effrayant d'observer comment peu de collègues savent ce qu'est une classe abstraite ou une interface, et encore moins bien concevoir une hiérarchie de l'héritage pour répondre aux besoins de l'entreprise.

cependant, quand un bon design OO est présent, c'est tout simplement la joie de lire le code et de voir le code se mettre naturellement en place dans les composants intuitifs/classes. J'ai toujours perçu l'architecture et la conception des systèmes comme la conception des divers services et des emplois de personnel dans un société - tous sont là pour accomplir un certain travail dans le grand schéma des choses, émettant de la synergie nécessaire pour propulser l'organisation/système.

qui, bien sûr, est tout à fait rare malheureusement. Tout comme le rapport entre les objets physiques magnifiquement conçus et horriblement conçus dans le monde, on peut dire la même chose de l'ingénierie et de la conception logicielles. Avoir les bons outils à disposition n'est pas nécessairement communiquer les bonnes pratiques et les résultats.

peut-être un capot, un tour ou un arbre n'est pas une chaise mais ils sont tous ISittable.

je pense que ces choses du monde réel sont des objets

c'est vrai?

quelles sont les méthodes utilisées pour établir une facture? Oh, attendez. Il ne peut pas payer lui-même, il ne peut pas s'envoyer lui-même, il ne peut pas se comparer avec les articles que le vendeur a effectivement livré. Il n'a aucune méthode; il est totalement inerte et non fonctionnel. C'est un type d'enregistrement (une structure, si vous préférez), pas un objet.

de même que l'autre choses que vous mentionnez.

ce n'est pas parce que quelque chose est réel qu'il s'agit d'un objet au sens OO du mot. Les objets OO sont un couplage particulier de l'état et du comportement qui peuvent agir de leur propre chef. Ce n'est pas quelque chose qui est abondante dans le monde réel.

j'écris du code OO depuis environ 9 ans. À part l'utilisation de messages, il m'est difficile d'imaginer une autre approche. Le principal avantage que je vois totalement en ligne avec ce que le CodingTheWheel disait: la modularisation. OO me conduit naturellement à construire mes applications à partir de composants modulaires qui ont des interfaces propres et des responsabilités claires (c'est-à-dire un code peu articulé, très cohésif avec une séparation claire des préoccupations).

je pense que là où OO pauses c'est quand les gens créent des héritarchies de classe profondément imbriquées. Cela peut conduire à la complexité. Cependant, factoriser finctionality commune dans une classe de base, puis réutiliser que dans d'autres classes de descendants est une chose profondément élégante, IMHO!

en premier lieu, les observations sont quelque peu négligées. Je n'ai pas de chiffres sur la productivité des logiciels, et je n'ai aucune bonne raison de croire qu'elle ne va pas augmenter. De plus, comme il y a beaucoup de gens qui abusent de L'oo, une bonne utilisation de L'OO ne provoquerait pas nécessairement une amélioration de la productivité même si L'OO était la plus grande chose depuis le beurre d'arachide. Après tout, un incompétent chirurgien du cerveau est susceptible d'être pire que rien du tout, mais compétent peut être inestimable.

cela dit, OO est une manière différente d'organiser les choses, en attachant le code de procédure aux données plutôt que de faire fonctionner le code de procédure sur les données. Cela devrait être au moins une petite victoire en soi, car il y a des cas où l'approche OO est plus naturelle. Il n'y a rien qui empêche quiconque d'écrire une API procédurale en C++, Après tout, et donc l'option de fournir des objets à la place rend le langage plus polyvalent.

plus loin, il y a quelque chose que OO fait très bien: il permet à l'ancien code pour appeler le nouveau code automatiquement, sans aucune modification. Si j'ai un code qui gère les choses d'un point de vue procédural, et que j'ajoute une nouvelle sorte de chose qui est similaire mais pas identique à une précédente, je dois changer le code de procédure. Dans un système OO, j'hérite de la fonctionnalité, Je change ce que j'aime, et le nouveau code est automatiquement utilisé en raison du polymorphisme. Cela augmente la localisation des changements, et c'est une bonne chose.

l'inconvénient est que bon OO n'est pas gratuit: il faut du temps et des efforts pour l'apprendre correctement. Depuis que c'est un mot à la Mode, Il ya beaucoup de gens et de produits qui le font mal, juste pour le plaisir de le faire. Il n'est pas plus facile de concevoir une bonne interface de classe qu'une bonne API procédurale, et il y a toutes sortes d'erreurs faciles à faire (comme les hiérarchies profondes de classe).

pensez - y comme une sorte d'outil différent, pas nécessairement meilleur en général. Un marteau en plus d'un tournevis, par exemple. Peut-être que nous allons finalement sortir de la pratique de l'ingénierie logicielle comme savoir quelle clé à utiliser pour enfoncer la vis.

@Sean

cependant, la factorisation finctionalité commune dans une classe de base, puis réutiliser que dans d'autres classes descendantes est une chose profondément élégante, IMHO!

mais les développeurs "procéduraux" font cela depuis des décennies de toute façon. La syntaxe et la terminologie peuvent différer, mais l'effet est identique. Il y a plus à OOP que "réutiliser des fonctionnalités communes dans une classe de base", et je pourrais même aller jusqu'à dire que c'est difficile à décrire comme OOP du tout; appeler la même fonction à partir de différents bits de code est une technique aussi ancienne que la sous-procédure elle-même.

@Konrad

de la programmation orientée objet peut être imparfaite et ce n'est certainement pas la panacée, mais elle rend à grande échelle des applications beaucoup plus simple, car il est un excellent moyen de réduire les dépendances

C'est le dogme. Je ne vois pas ce qui rend OOP significativement meilleur à cet égard que la programmation procédurale de l'ancien. Chaque fois que je fais un appel de procédure Je m'isole des détails de la mise en œuvre.

pour moi, il y a beaucoup de valeur dans la syntaxe OOP elle-même. Utiliser des objets qui tentent de représenter des choses réelles ou des structures de données est souvent beaucoup plus utile que d'essayer d'utiliser un tas de différentes fonctions plates (ou "flottantes") pour faire la même chose avec les mêmes données. Il y a un certain "flux" naturel vers les choses avec une bonne OOP qui fait juste plus de sens à lire, écrire, et maintenir à long terme.

peu importe qu'une facture ne soit pas "object" avec des fonctions qu'il peut exécuter lui - même-l'instance object peut exister juste pour exécuter des fonctions sur les données sans avoir à savoir quel type de données est réellement là. La fonction "de la facture.toJson () "peut être appelé avec succès sans avoir à connaître le type de données" facture " est - le résultat sera Json, peu importe si elle vient d'une base de données, XML, CSV, ou même un autre objet JSON. Avec les fonctions de procédure, vous devez tout d'un coup en savoir plus sur vos données, et se retrouver avec fonctions comme " xmlToJson()", "csvToJson ()", " dbToJson ()", etc. Il devient finalement un gâchis complet et un énorme mal de tête si vous jamais changer le type de données sous-jacentes.

le but de OOP est de cacher la mise en œuvre réelle en l'abstrayant. Pour atteindre cet objectif, vous devez créer une interface publique. Pour faciliter votre travail tout en créant cette interface publique et garder les choses sèches, vous devez utiliser des concepts comme les classes abstraites, l'héritage, le polymorphisme et le design modèle.

donc pour moi, le véritable objectif primordial de OOP est de faciliter la maintenance et les changements futurs du code. Mais même au-delà de cela, il peut vraiment simplifier les choses beaucoup lorsqu'il est fait correctement dans des façons que le code de procédure n'a jamais pu. Peu importe s'il ne correspond pas au "monde réel" - la programmation avec du code n'interagit pas avec les objets du monde réel de toute façon. OOP est juste un outil qui rend mon travail plus facile et plus rapide - je vais aller pour cela d'un jour à l'autre.

@CodingTheWheel

mais dans la mesure où L'OOP a été une perte de temps, je dirais que c'est en raison du manque de formation des programmeurs, aggravé par la courbe d'apprentissage raide d'apprendre une langue OOP cartographie spécifique. Certaines personnes "obtiennent" de L'OOP et d'autres ne le feront jamais.

Je ne sais pas si c'est vraiment surprenant. Je pense que les approches techniquement saines (LSP étant la chose évidente) font difficile à utiliser , mais si nous n'utilisons pas de telles approches, cela rend de toute façon le code fragile et inextensible (parce que nous ne pouvons plus le raisonner). Et je pense que les résultats contre-intuitifs que OOP nous amène à faire en sorte qu'il n'est pas surprenant que les gens ne le remarquent pas.

de manière plus significative, puisque le logiciel est déjà fondamentalement trop difficile pour les humains normaux à écrire de manière fiable et précise, devrait-on vraiment vanter une technique qui est systématiquement mal enseignée et apparaît difficile à apprendre? Si les avantages étaient clairs, alors il pourrait être utile persévérer en dépit de la difficulté, mais cela ne semble pas être le cas.

@Jeff

relativement à la programmation procédurale directe, le premier principe fondamental de L'OOP est la notion de dissimulation et d'encapsulation de l'information. Cette idée conduit à la notion de classe qui sépare l'interface de mise en œuvre.

qui a l'implémentation la plus cachée: iostream de C++, ou fichier*s de C?

je pense que l'utilisation d'objets de contexte opaque (poignées dans Win32, Fichier*s en C, pour nommer deux exemples bien connus--Hell, HANDLEs live de l'autre côté de la barrière de mode du noyau, et il ne se trouve pas vraiment beaucoup plus encapsulé que cela) se trouve aussi dans le code de procédure; je me bats pour voir comment c'est quelque chose de particulier à OOP.

je suppose que c'est peut-être une partie de la raison pour laquelle je lutte pour voir les avantages: les parties qui sont évidemment bonnes ne sont pas spécifiques à L'OOP, alors que les parties qui sont spécifiques à L'OOP ne sont pas évidemment bonnes! (ce ne pas dire qu'ils sont nécessairement mauvais, mais plutôt que je n'ai pas vu la preuve qu'ils sont largement applicables et systématiquement bénéfiques).

dans le seul Blog dev que j'ai lu, par ce Joel-on-Software-fondateur-of-SO guy, j'ai lu il y a longtemps que L'OO ne conduit pas à des augmentations de productivité. Gestion automatique de la mémoire. Cool. Qui peut nier les données?

" je crois toujours que OO est à non-OO ce que la programmation avec des fonctions est à la programmation tout en ligne.

(Et je devrais le savoir, comme j'ai commencé avec GWBasic.) Lorsque vous reformatez le code pour utiliser les fonctions, variable2654 devient variable3 de la méthode dans laquelle vous êtes. Ou, mieux encore, il a un nom que vous pouvez comprendre, et si la fonction est courte, il est appelé value et c'est suffisant pour la pleine compréhension.

lorsque le code sans fonctions devient du code avec des méthodes, vous pouvez supprimer des miles de code.

quand vous reformatez le code pour être vraiment OO, b , c , q , et Z devenir this , this , this et this . Et puisque je ne crois pas à l'utilisation du mot-clé this , vous pouvez supprimer des miles de code. En fait, vous pouvez le faire même si vous utilisez this .

Je ne pense pas que OO soit une métaphore naturelle.

je ne pense pas que la langue est d'un naturel métaphore soit, je ne je pense que les "odeurs" de Fowler sont mieux que de dire "ce code a mauvais goût."Cela dit, je pense que OO n'est pas à propos de métaphores naturelles et les gens qui pensent que les objets juste pop-out à vous manquent fondamentalement le point. vous définissez l'univers objet, et de meilleurs univers objet résultent en un code qui est plus court, plus facile à comprendre, fonctionne mieux, ou tout cela (et certains critères que j'oublie). Je pense que les gens qui utilisent le clients/domaine d'objets naturels comme des objets de programmation manquent le pouvoir de redéfinir l'univers.

par exemple, quand vous faites un système de réservation de compagnie aérienne, ce que vous appelez une réservation pourrait ne pas correspondre à une réservation juridique/d'affaires du tout.

certains des concepts de base sont des outils vraiment cool

je pense que la plupart des gens exagèrent avec ce tout "quand tu as un marteau, ce sont tous des clous." Je pense que l'autre côté de la médaille/miroir est tout aussi vrai: quand vous avez un gadget comme le polymorphisme/héritage, vous commencez à trouver des utilisations où il s'adapte comme un gant/chaussette/lentilles de contact. Les outils de OO sont très puissants. Un seul héritage est, je pense, absolument nécessaire pour les gens de ne pas se laisser emporter, mon propre logiciel multi-héritage ne résiste pas.

Quel est l'intérêt de L'OOP?

je pense que c'est une bonne façon de gérer une base de code absolument massive. Je pense qu'il vous permet d'organiser et de réorganiser votre code et vous donne un langage pour le faire (au-delà du langage de programmation dans lequel vous travaillez), et modularise le code d'une manière assez naturelle et facile à comprendre.

OOP est destiné à être mal compris par la majorité des développeurs

C'est parce que c'est un processus d'ouverture des yeux comme la vie: vous comprenez OO de plus en plus avec l'expérience, et commencer à éviter certains modèles et d'employer d'autres que vous devenez plus sage. Un des meilleurs exemples est que vous arrêtez d'utiliser l'héritage pour les classes que vous ne contrôlez pas, et préférez le façade modèle à la place.

concernant votre mini-essai / question

je voulais vous dire que vous aviez raison. La réutilisabilité est une chimère, pour la plupart. Voici une citation D'Anders Hejilsberg sur ce sujet (brillant) d'ici :

si vous demandez aux programmeurs débutants de Ecrire un contrôle de calendrier, ils souvent penser à eux-mêmes, "Oh, je vais écrire le meilleur calendrier du monde le contrôle! Ça va être polymorphe à l'égard de le genre de calendrier. Il y aura des displayers, et des mungers, et ce, qu', et de l'autre." Ils nécessité d'expédier une demande de calendrier en de deux mois. Ils ont mis tout ça l'infrastructure en place dans le contrôle, puis passer deux jours rédiger une demande de calendrier merdique sur le dessus de cela. Ils vont penser que, "Dans le la prochaine version de l'application, je suis allez faire beaucoup plus."

une fois qu'ils commencent à penser à comment ils vont en fait mettre en œuvre toutes ces autres réalisations de leur conception abstraite, cependant, il s'avère que leur conception est complètement faux. Et maintenant ils en ont peint lui-même dans un coin, et ils ont de jeter le tout chose hors. J'ai vu que plus et plus. Je suis un croyant ferme en cours de minimaliste. Sauf si vous êtes réellement allons résoudre le problème général, n'essayez pas de mettre en place un cadre pour la résolution d'un spécifique, parce que vous ne savez pas ce que cadre de devrait ressembler à comme.

avez-vous déjà créé une fenêtre en utilisant WinAPI?

plus de fois que je ne me souviens.

alors vous devez savoir que vous définissez une classe (RegisterClass), créez une instance (CreateWindow), appelez les méthodes virtuelles (WndProc) et les méthodes de classe de base (DefWindowProc) et ainsi de suite. WinAPI prend même la nomenclature de SmallTalk OOP, appelant les méthodes "messages" (Messages de fenêtre).

alors vous saurez aussi qu'il ne fait pas d'expédition de message de ses propres, qui est un grand vide béant. Il a aussi un sous-classement merdique.

Les poignées

ne sont peut-être pas héréditaires, mais il y a final en Java. Ils n'ont pas besoin d'une classe, ils sont une réserve pour la classe: C'est ce que le mot "gérer" signifie. En regardant des architectures comme MFC ou WinForms. net, il est tout de suite évident qu'à l'exception de la syntaxe, il n'y a pas grand chose qui diffère de le WinAPI.

ils ne sont pas héritables ni dans l'interface ni dans la mise en œuvre, peu substituables, et ils ne sont pas substantiellement différents de ce que les codeurs procéduraux ont fait depuis toujours.

C'est vraiment ça? Les meilleurs morceaux de OOP sont justes... code de procédure traditionnel? C'est le problème?

je suis entièrement d'accord avec InSciTek Jeff 's réponse, je vais juste ajouter les améliorations suivantes:

• masquage et encapsulation de L'Information: critique pour tout code maintenable. Peut être fait en étant prudent dans n'importe quel langage de programmation, ne nécessite pas de fonctionnalités OO, mais le faire rendra votre code légèrement oo-like.
• héritage: il y a un domaine d'application important pour lequel tous ceux OO est-une-sorte-de et contenant un les relations sont un ajustement parfait: les Interfaces Utilisateur Graphiques. Si vous essayez de construire des interfaces graphiques sans prise en charge de la langue OO, vous finirez par construire des fonctionnalités de type OO de toute façon, et c'est plus difficile et plus sujet aux erreurs sans prise en charge de la langue. Glade (récemment) et X11 Xt (historiquement) par exemple.

utiliser des caractéristiques OO (en particulier des hiérarchies abstraites profondément imbriquées), quand il n'y a pas de point, est inutile. Mais pour certains domaines d'application, il y a vraiment un point.

je crois que le plus bénéfique pour la qualité de la programmation orientée objet est de données de masquage et de gestion. Cependant, il y a beaucoup d'exemples où L'OOP est mal utilisé et je pense que c'est là que la confusion entre en jeu.

ce n'est pas parce qu'on peut transformer quelque chose en objet qu'on doit le faire. Cependant, si le faire rendra votre code plus organisé/plus facile à lire alors vous devriez certainement.

un excellent exemple pratique où OOP est très utile est avec un " produit" classe et objets que j'utilise sur notre site web. Puisque chaque page est un produit, et chaque produit a des références à d'autres produits, il peut devenir très confus quant au produit auquel les données que vous avez se réfère. Cette variable "strURL" est-elle le lien vers la page courante, ou vers la page d'accueil, ou vers la page des statistiques? Bien sûr, vous pouvez faire toutes sortes de variables différentes qui se réfèrent à la même information, mais proCurrentPage->strURL, est beaucoup plus facile à comprendre (pour un développeur).

En outre, attacher des fonctions à ces pages est beaucoup plus propre. Je peux faire proCurrentPage - > CleanCache(); suivi de proDisplayItem->RenderPromo (); si je viens d'appeler ces fonctions et si j'avais supposé que les données actuelles étaient disponibles, qui sait quelle sorte de mal se produirait. En outre, si je devais passer les variables correctes dans ces fonctions, je suis de retour au problème d'avoir toutes sortes de variables pour les différents produits gisant autour.

au lieu de cela, en utilisant des objets, tous mes les données et les fonctions du produit sont belles et propres et faciles à comprendre.

cependant. Le gros problème avec L'OOP est quand quelqu'un croit que tout devrait être OOP. Cela crée beaucoup de problèmes. J'ai 88 tables dans ma base de données. Je n'ai que 6 cours, et peut-être que je devrais en avoir 10. Je n'ai pas besoin de 88 cours. La plupart du temps, accéder directement à ces tableaux est parfaitement compréhensible dans les circonstances où je l'utilise, et OOP serait en fait plus difficile / fastidieux d'accéder aux fonctionnalités de base de ce qui se passe.

je crois qu'un modèle hybride d'objets où utile et procédurale où pratique est la méthode la plus efficace de codage. C'est une honte que nous avons toutes ces guerres de religion où préconisent l'utilisation d'une méthode au détriment des autres. Ils sont tous les deux bons, et ils ont tous les deux leur place. La plupart du temps, les deux méthodes sont utilisées dans tous les grands projets (dans certains petits projets, une seule l'objet, ou quelques procédures peuvent être tout ce dont vous avez besoin).

je n'ai pas de soins pour les réutiliser autant que je le fais pour des raisons de lisibilité. Ce dernier signifie que votre code est plus facile à modifier. Ça vaut de l'or dans l'art de la création de logiciels.

et OO est un moyen sacrément efficace pour rendre vos programmes lisibles. Réutiliser ou non réutiliser.

"Le monde réel n'est pas "OO","

vraiment? Mon monde est plein d'objets. J'utilise maintenant. Je pense que le fait d'avoir des "objets" logiciels qui modélisent les objets réels n'est peut-être pas une si mauvaise chose.

OO conceptions à des fins de choses (comme les Fenêtres, pas de monde réel de windows, mais les panneaux d'affichage sur mon écran d'ordinateur) laissent souvent beaucoup à désirer. Mais pour des choses comme les factures, les bons de commande, les réclamations d'assurance et ce que-pas, je pense ces choses du monde réel sont des objets. J'ai une pile sur mon bureau, donc ils doivent être réels.

le but de OOP est de donner au programmeur un autre moyen de décrire et de communiquer une solution à un problème en code aux machines et aux personnes. La partie la plus importante est la communication pour les personnes. OOP permet au programmeur de déclarer ce qu'ils signifient dans le code à travers des règles qui sont appliquées dans la langue oo.

contrairement à de nombreux arguments sur ce sujet, les concepts OOP et OO sont omniprésents dans tout le code, y compris le code EN non-OOP les langues comme C. de nombreux programmeurs avancés non-OO se rapprocheront des caractéristiques des objets, même dans les langues non-OO.

avoir construit OO dans le langage donne simplement au programmeur un autre moyen d'expression.

la plus grande partie de l'écriture de code n'est pas la communication avec la machine, cette partie est facile, la plus grande partie est la communication avec les programmeurs humains.