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

https://stackoverflow.com/questions/24270

09-06-2019
|

Question

Aussi loin que je peux dire, malgré les innombrables millions ou des milliards dépensés sur la programmation orientée objet, l'éducation, les langues et les outils de la programmation orientée objet n'a pas amélioré la productivité du développeur ou de la fiabilité des logiciels, ni réduit les coûts de développement.Peu de gens l'utilisation de la programmation orientée objet dans tous les sens rigoureux (peu de gens adhèrent ou de comprendre les principes tels que le LSP);il semble y avoir peu d'uniformité ou de la consistance aux approches que les gens prennent pour des problèmes de modélisation de domaines.Trop souvent, la classe est utilisée simplement pour son sucre syntaxique;il met l'fonctions pour un type d'enregistrement dans leur petit espace de noms.

J'ai écrit une grande quantité de code pour une grande variété d'applications.Bien qu'il y a eu des endroits où la vraie substituables le sous-typage joué un rôle important dans l'application, celles-ci ont été assez exceptionnel.En général, bien que beaucoup de lip service est donnée de parler de "réutilisation" la réalité est que si un morceau de code ne exactement ce que vous voulez faire, il y a très peu coût-efficace "re-use".Il est extrêmement difficile de classes de conception pour être extensible dans le droit chemin, et donc le coût de l'extension est normalement si grande que la "réutilisation" n'est tout simplement pas la peine.

À bien des égards, cela ne m'étonne pas.Le monde réel n'est pas "OO", et l'idée implicite dans OO--que l'on peut modéliser des choses avec une certaine classe de la taxonomie--me semble très viciée à la base (je peux m'asseoir sur une table, un tronc d'arbre, le capot d'une voiture, quelqu'un tour, mais pas un de ceux est-une chaise).Même si nous nous déplaçons vers la plus abstraite domaines, OO modélisation est souvent difficile, contre-intuitif, et en fin de compte inutile (considérez les exemples classiques de cercles/ellipses ou des carrés/rectangles).

Donc ce qui me manque ici?Où est la valeur de la programmation orientée objet, et pourquoi tout le temps et l'argent n'a pas à faire des logiciels mieux?

La solution

Il n'y a pas de preuve empirique suggère que l'orientation de l'objet est un moyen plus naturel pour les gens à réfléchir sur le monde.Il y a certains travaux dans le domaine de la psychologie de la programmation qui montre que l'OO n'est pas en quelque sorte plus adapté que les autres approches.

Des représentations orientées-objet ne semble pas être universellement plus utilisables ou moins utilisable.

Il ne suffit pas d'adopter OO méthodes et exigent des développeurs pour utiliser ces méthodes, car cela pourrait avoir un impact négatif sur la productivité des développeurs, ainsi que la qualité des systèmes développés.

Qui est de "Sur la facilité d'utilisation de OO Représentations" de Communications de l'ACM Oct.2000.Les articles on compare OO contre le processus de l'approche axée sur.Il y a beaucoup de l'étude de la façon dont les gens qui travaillent avec le OO méthode de "penser" (Int.J.de l'Homme-Ordinateur Études de 2001, numéro 54, ou de l'Interaction Homme-Ordinateur 1995, vol.10 a un thème entier sur OO études), et à partir de ce que j'ai lu, il n'y a rien pour indiquer une sorte de naturalité à l'OO approche qui, mieux que plus traditionnelle approche procédurale.

Autres conseils

Le monde réel n'est pas "OO", et l'idée implicite dans OO--que l'on peut modéliser des choses avec une certaine classe de la taxonomie--me semble très fondamentalement vicié

Ce qui est vrai et a été observé par d'autres personnes (prendre Stepanov, inventeur de la STL), le reste est un non-sens.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.Bien sûr, ceci n'est vrai que pour les “bons” de la programmation orientée objet design.Sloppy design ne donne aucun avantage.Mais bon, découplée de la conception peut être modélisé en utilisant la programmation orientée objet et n'est pas bien d'utiliser d'autres techniques.

Il y a beaucoup mieux, plus des modèles universels (Haskell type de modèle vient à l'esprit), mais ces derniers sont souvent plus complexes et/ou difficiles à mettre en œuvre efficacement.La programmation orientée objet est un bon compromis entre les deux extrêmes.

La POO n'est pas sur la création de ré-utilisable classes, son sujet de la création Utilisable classes.

Trop souvent, la classe est utilisée tout simplement pour son sucre syntaxique;il met les fonctions pour un type d'enregistrement dans leur petit espace de noms.

Oui, je trouve cela trop répandus ainsi.Ce n'est pas de la Programmation Orientée Objet.C'est l'Objet de Base de la Programmation et des données centrées sur la programmation.Dans mes 10 années de travail avec les Langages à objets, je vois la plupart des gens faire de l'Objet en Fonction de la Programmation.OBP se décompose très rapidement à mon humble avis, puisque vous êtes essentiellement faire les pires de ces deux mots:1) la Procédure de programmation sans avoir à respecter prouvé la programmation structurée méthodologie et 2) de la programmation orientée objet, sans avoir à respecter pour prouvé méthodologie de la programmation orientée objet.

OOP fait droit est une belle chose.Il rend très difficile les problèmes faciles à résoudre, et pour les non-initiés (ne cherche pas à son pompeux là), il peut paraître presque comme par magie.Cela étant dit, la POO est qu'un outil dans la boîte à outils de méthodes de programmation.Ce n'est pas la fin à toutes méthodologie.Il arrive juste pour répondre à de grandes applications d'entreprise bien.

La plupart des développeurs qui travaillent en programmation orientée objet, les langues sont en utilisant des exemples de la programmation orientée objet fait droit dans les cadres et les types qu'ils utilisent au jour le jour, mais ils ne sont simplement pas au courant de ça.Voici quelques exemples très simples:ADO.NET, Hibernate/NHibernate, la Journalisation des Cadres, dans les différentes langues des types de collection, la ASP.NET pile, Les JSP de la pile, etc...Ce sont toutes les choses qui s'appuient largement sur la programmation orientée objet dans leur code.

La réutilisation ne doit pas être un objectif de la programmation orientée objet - ou tout autre paradigme pour cette question.

La réutilisation est un effet secondaire d'une bonne conception et le bon niveau d'abstraction.Code réalise la réutilisation par faire quelque chose d'utile, mais ne pas le faire de façon à le rendre rigide.Il n'est pas question de savoir si le code est OO ou pas - on réutiliser ce qui fonctionne et n'est pas trivial à faire nous-mêmes.C'est le pragmatisme.

La pensée de OO comme une nouvelle façon d'arriver à la réutilisation par l'héritage est fondamentalement vicié.Comme vous le notez le LSP violations abondent.Au lieu de cela, OO est pas pensée comme une méthode de gestion de la complexité d'un problème de domaine.L'objectif est de maintenabilité d'un système au cours du temps.Le principal outil pour atteindre cet objectif est la séparation de l'interface publique d'une mise en œuvre privée.Cela nous permet d'avoir des règles comme "Cela ne devrait être modifiée à l'aide de ..." appliquée par le compilateur, plutôt que de la revue de code.

Avec cela, je suis sûr que vous serez d'accord, nous permet de créer et de maintenir extrêmement complexe systèmes.Il y a beaucoup de valeur, et il n'est pas facile de le faire dans d'autres paradigmes.

Presque religieux, mais je dirais que vous êtes en train de peindre une image trop sombre tableau de l'état moderne de la programmation orientée objet.Je dirais que c'est réellement a réduction des coûts, grands projets de logiciel maniable, et ainsi de suite.Cela ne veut pas dire que c'est résolu le problème fondamental de logiciels de la médiocrité, et cela ne signifie pas que le développeur moyen est un expert de la programmation orientée objet.Mais la modularité de la fonction de l'objet des composants a certainement réduit la quantité de code spaghetti dans le monde.

Je ne peux penser à des dizaines de bibliothèques du haut de ma tête qui sont magnifiquement réutilisable et qui ont permis d'économiser du temps et de l'argent qui ne peut jamais être calculé.

Mais dans la mesure où la programmation orientée objet a été une perte de temps, je dirais que c'est à cause du manque de programmeur de formation, aggravée par la courbe d'apprentissage abrupte de l'apprentissage d'une langue spécifique de la programmation orientée objet de la cartographie.Certaines personnes "get" de la programmation orientée objet et d'autres ne le sera jamais.

Je pense que l'utilisation de l'opaque contexte des objets (Poignées en Win32, FICHIER*s en C, pour ne citer que deux exemples bien connus--l'enfer, Poignées de vivre de l'autre côté de la mode noyau de la barrière, et il n'a vraiment pas beaucoup plus que encapsulé qui) se trouve dans le code de procédure trop;J'ai du mal à voir comment c'est quelque chose de particulier à la programmation orientée objet.

HANDLEs (et le reste de la WinAPI) est OUPS!C ne prend pas en charge la programmation orientée objet très bien donc il n'y a pas de syntaxe particulière, mais cela ne signifie pas qu'il n'utilise pas les mêmes concepts.WinAPI est dans tous les sens du mot, un framework orienté objet.

Voir, c'est le problème avec chaque discussion portant sur la programmation orientée objet ou de techniques alternatives:personne n'est clair sur la définition, tout le monde parle d'autre chose et donc aucun consensus ne peut être atteint.Semble comme une perte de temps pour moi.

Ses un paradigme de programmation..Conçus pour rendre plus facile pour nous, simples mortels, de décomposer un problème en plus petits, réalisable pièces..

Si vous ne la trouvez pas utile..Ne l'utilisez pas, ne pas payer pour la formation et d'être heureux.

J'ai en revanche ne trouvent utile, donc je vais :)

Par rapport à la droite de procédure de programmation, le premier principe de base de la programmation orientée objet est la notion de se cacher de l'information et de l'encapsulation.Cette idée conduit à la notion de classe qui sépare l'interface de mise en œuvre.Ces sont extrêmement importantes et concepts de base pour mettre en place un cadre pour réfléchir à la conception du programme d'une manière différente et mieux (je pense) façon.Vous ne pouvez pas vraiment argumenter contre ces propriétés - il n'y a pas de compromis, et c'est toujours le moyen le plus propre à modulize choses.

D'autres aspects de la programmation orientée objet, notamment en matière d'héritage et de polymorphisme important, mais comme d'autres l'ont fait allusion, ceux-ci sont généralement plus utilisés.c'est à dire:Parfois, les gens utiliser l'héritage et/ou polymorphisme, car ils peuvent, non pas parce qu'ils devraient avoir.Ils sont des concepts puissants et très utile, mais qui doivent être utilisés à bon escient et ne sont pas automatiques gagner des avantages de la programmation orientée objet.

Par rapport à la réutilisation.Je suis d'accord la ré-utilisation est plus vendu pour la programmation orientée objet.C'est un effet secondaire possible de bien des objets définis, généralement de plus primitif et classes génériques et est une conséquence directe de l'encapsulation et de se cacher de l'information concepts.Il est potentiellement plus facile à être ré-utilisées parce que les interfaces bien définies les classes sont tout simplement plus clair et un peu de soi à la documentation.

Le problème avec la POO, c'est qu'il a été survendu.

Comme Alan Kay conçu à l'origine, c'était une excellente alternative à l'état de la pratique d'avoir des données brutes et tous-global routines.

Ensuite, certaines de gestion-consultant types accroché à elle et l'a vendu comme le messie de logiciels, et de lemmings-like, du milieu universitaire et de l'industrie a chuté après elle.

Maintenant, ils sont de lemmings-like tumbling après d'autres bonnes idées de la zone de survente, tels que la programmation fonctionnelle.

Donc, ce que je ferais différemment?Beaucoup, et j'ai écrit un livre à ce sujet.(C'est de l'impression - je ne suis pas un cent, mais vous pouvez toujours en obtenir des copies.)Amazon

Ma réponse constructive, c'est de regarder la programmation non pas comme une façon de modélisation des choses dans le monde réel, mais comme une façon de répondre aux besoins d'encodage.

Qui est très différente, et est basé sur la théorie de l'information (à un niveau que n'importe qui peut comprendre).Il est dit que la programmation peut être regardé comme un processus de définition de langues et de compétences est essentielle pour une bonne programmation.

Elle élève le concept de domaine spécifique de langues (Dsl).Il est d'accord avec insistance avec DRY (don't repeat yourself).Il donne un grand coup de pouce-jusqu'à la génération de code.Il en résulte dans le logiciel avec massivement au moins une structure de données que ce qui est typique pour les applications modernes.

Il vise à redynamiser l'idée que la solution réside dans l'inventivité, et que même bien accepté les idées doivent être remis en question.

Poignées (et le reste de la WinAPI) est de la POO!

Sont-ils, d'ailleurs?Ils ne sont pas héritées, elles ne sont certainement pas substituables, ils manquent bien défini des classes...Je pense qu'ils ont largement en deçà de la "programmation orientée objet".

Avez-vous déjà créé une fenêtre à l'aide de WinAPI?Ensuite, vous devez savoir que vous définissez une classe (RegisterClass), créer une instance (CreateWindow), l'appel des méthodes virtuelles (WndProc) et de la classe de base des méthodes (DefWindowProc) et ainsi de suite.WinAPI prend même la nomenclature de SmallTalk de la programmation orientée objet, en appelant la méthode “messages” (Fenêtre de Messages).

Les poignées peuvent ne pas être héréditaire, mais ensuite, il y a final en Java.Ils ne manquent pas de classe, ils sont un espace réservé pour la classe:C'est ce que le mot “gérer” les moyens.En regardant les architectures comme MFC ou .NET WinForms il est immédiatement évident qu'à l'exception de la syntaxe, rien n'est plus différent de la WinAPI.

Oui la programmation orientée objet ne permet pas de résoudre tous nos problèmes, nous en sommes désolés.Nous sommes cependant de travail sur la SOA qui permettra de résoudre tous ces problèmes.

La programmation orientée objet se prête bien à la programmation informatique interne des structures comme GUI "widgets", où, par exemple SelectList et de la zone de texte peuvent être des sous-types d'Élément, qui a les mêmes méthodes telles que le "move" et "redimensionner".

Le problème, c'est 90% d'entre nous travaillent dans le monde de l'entreprise où nous travaillons avec des entreprises, des concepts tels que la Facture, d'Employé, de l'Emploi, de l'Ordre.Ces ne pas se prêtent si bien à la programmation orientée objet, car les "objets" sont des plus floues, sujettes à modification en fonction des activités de re-engineering et ainsi de suite.

Dans le pire des cas où l'OO est appliquée avec enthousiasme à des bases de données, y compris les violations flagrantes OO "améliorations" à des bases de données SQL - qui sont, à juste titre, ignorés, sauf par la base de données de noobs qui suppose qu'ils doivent être la bonne façon de faire les choses parce qu'ils sont plus récents.

Dans mon expérience de l'examen de code et de conception de projets, j'ai été à travers, la valeur de la programmation orientée objet n'est pas pleinement réalisé, parce que beaucoup de développeurs ont pas correctement conceptualisé le modèle orienté-objet dans leur esprit.Donc ils n'ont pas de programme avec OO design, très souvent, il continue à écrire de haut en bas du code de procédure de prise de classes, une jolie plat de la conception.(si vous pouvez même appeler ce "design" en premier lieu)

Il est assez effrayant de voir comment peu de collègues sais à propos de ce qu'est une classe abstraite ou une interface sont, a fortiori, de concevoir une hiérarchie d'héritage pour satisfaire les besoins de l'entreprise.

Toutefois, lorsque la bonne OO design est présent, il est juste de la pure joie de lire le code et de voir le code tombent naturellement en place intuitifs composants/classes.J'ai toujours perçu l'architecture du système et de la conception comme de la conception des différents ministères et emplois du personnel dans une entreprise, 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.Comme le ratio de l'magnifiquement conçus contre horriblement conçu objets physiques dans le monde, le même pouvez très bien être dit à propos de logiciel de conception et d'ingénierie.Avoir les bons outils à disposition ne confère pas nécessairement une bonne pratiques et des résultats.

Peut-être un bonnet, tour ou un arbre n'est pas un président, mais ils sont tous ISittable.

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

- Vous faire?

Quelles sont les méthodes ne avoir 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 éléments que le fournisseur effectivement livrés.Il n'a pas du tout les méthodes;c'est totalement inerte et non-fonctionnelles.C'est un type d'enregistrement (un struct, si vous préférez), et non un objet.

De même, les autres choses que vous mentionnez.

Juste parce que quelque chose est réel de ne pas en faire un objet dans le OO sens du mot.OO les objets sont une particularité du couplage de l'état et le comportement qui peuvent agir de leur propre chef.Ce n'est pas quelque chose qui est abondante dans le monde réel.

J'ai écrit OO code pour les 9 dernières années.Autres que l'utilisation de la messagerie, il est difficile pour moi d'imaginer autre approche.Le principal avantage que je vois complètement en ligne avec ce que CodingTheWheel dit:la modularisation.OO conduit naturellement à moi pour construire mes applications à partir de composants modulaires qui ont de bonnes interfaces et des responsabilités claires (c'est à direfaiblement couplé, hautement cohésif de code, avec une séparation claire des préoccupations).

Je pense que là où OO pauses, c'est quand les gens créent profondément imbriqués les hiérarchies de classe.Cela peut conduire à la complexité.Cependant, l'affacturage communs finctionality dans une classe de base, puis de les réutiliser dans d'autres classes descendantes est profondément élégant chose, à mon humble avis!

En premier lieu, les observations sont un peu bâclée.Je n'ai pas de chiffres sur les logiciels de productivité, et n'ai pas de bonne raison de croire qu'elle ne va pas jusqu'.De plus, puisqu'il y a beaucoup de gens qui abusent OO, bonne utilisation de l'OO ne serait pas nécessairement entraîner une amélioration de la productivité, même si OO est la meilleure 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 étant dit, OO est une autre façon d'arranger les choses, en joignant le code de procédure de données plutôt que d'avoir le code de procédure opèrent sur des données.Cela devrait être au moins un petit gagner par lui-même, car il y a des cas où l'OO approche est plus naturel.Rien n'empêche quiconque de l'écriture d'une procédure API en C++, après tout, et ainsi, l'option de fournir des objets au lieu de cela fait la langue la plus polyvalente.

De plus, il y a quelque chose OO fait très bien:il permet à l'ancien code pour appeler le nouveau code automatiquement, sans aucune modification.Si j'ai le code qui gère les choses sur le plan procédural, et j'ai ajouter un nouveau genre de chose qui est similaire mais pas identique à une autre, j'ai du modifier le code de procédure.Dans un OO système, j'hérite de la fonctionnalité, de changer ce que j'aime, et le nouveau code est automatiquement utilisé en raison de polymorphisme.Cela augmente la localité de changements, et qui est une Bonne Chose.

L'inconvénient est que bon OO n'est pas libre:il faut du temps et des efforts pour l'apprendre correctement.Depuis c'est un grand mot à la mode, il y a beaucoup de personnes et de produits qui faire mal, juste pour le plaisir de le faire.Il n'est pas facile de concevoir une bonne interface de classe qu'un bon de procédure de l'API, et il y a toutes sortes de facile à faire des erreurs (comme deep hiérarchies de classe).

Pensez à elle comme une autre sorte d'outil, pas nécessairement meilleur.Un marteau en plus d'un tournevis, par exemple.Peut-être que nous finirons par sortir de la pratique de l'ingénierie du logiciel que de savoir qui de la clé à utiliser pour le marteau de la vis.

@Sean

Cependant, l'affacturage communs finctionality dans une classe de base, puis de les réutiliser dans d'autres classes descendantes est profondément élégant chose, à mon humble avis!

Mais "procédural", les développeurs ont fait que pendant des décennies, de toute façon.La syntaxe et de la terminologie peut varier, mais l'effet est identique.Il ya plus à la programmation orientée objet que "la réutilisation des fonctionnalités communes dans une classe de base", et je pourrais même aller jusqu'à dire que c'est difficile à décrire comme la programmation orientée objet à tous;appeler la même fonction à partir de différents morceaux de code est une technique vieille comme le sous-procédure elle-même.

@Konrad

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 fait de la POO nettement mieux dans ce sens que la programmation procédurale de la vieille.Chaque fois que je fais un appel de procédure, je suis isolant moi-même à partir des spécificités de la mise en œuvre.

Pour moi, il y a beaucoup de valeur dans la syntaxe de la programmation orientée objet lui-même.À l'aide d'objets qui tentent de représenter une réelle des choses ou des structures de données est souvent beaucoup plus utile que d'essayer d'utiliser un tas de différentes plat (ou "flottant") de fonctions pour faire la même chose avec les mêmes données.Il y a un certain naturel "flux" de choses avec une bonne programmation orientée objet que tout simplement plus de sens à lire, à écrire et à maintenir à long terme.

Il n'est pas nécessairement question qu'une Facture n'est pas vraiment un "objet" avec les fonctions qu'il peut effectuer lui-même - l'instance de l'objet peut exister juste pour exécuter des fonctions sur les données, sans avoir de savoir quel type de données est réellement là.La fonction "de la facture.la méthode toJson()" peut être appelé avec succès sans avoir de savoir quel type de données "facture" est le résultat sera Json, peu importe si elle provient d'une base de données, XML, CSV, ou même un autre objet JSON.Avec les fonctions de procédure, vous, tout d'un coup ont pour en savoir plus au sujet de vos données, et jusqu'à la fin avec des fonctions comme "xmlToJson()", "csvToJson()", "dbToJson()", etc.Il finit par faire un désordre complet et un ÉNORME mal de tête si jamais vous changez le type de données.

Le point de la programmation orientée objet est de cacher la réelle mise en œuvre par le dégager de là.Pour atteindre cet objectif, vous devez créer une interface publique.Pour rendre votre travail plus facile, tandis que la création de cette interface publique et de garder les choses à SEC, vous devez utiliser des concepts tels que les classes abstraites, héritage, polymorphisme et modèles de conception.

Donc, pour moi, le véritable objectif primordial de la programmation orientée objet est de faire le futur code de maintenance et de changements plus facile.Mais même au-delà, il peut vraiment simplifier les choses quand il est fait correctement dans les moyens que le code de procédure ne pourrait jamais.Il n'a pas d'importance si elle ne correspond pas au "monde réel" - programmation avec le code n'est pas en interaction avec le monde réel des objets de toute façon.La POO est juste un outil qui rend mon travail plus facile et plus rapide, je vais aller pour que toute la journée.

@CodingTheWheel

Mais dans la mesure où la programmation orientée objet a été une perte de temps, je dirais que c'est à cause du manque de programmeur de formation, aggravée par la courbe d'apprentissage abrupte de l'apprentissage d'une langue spécifique de la programmation orientée objet de la cartographie.Certaines personnes "get" de la programmation orientée objet et d'autres ne le sera jamais.

Je ne sais pas si c'est vraiment surprenant, cependant.Je pense que, techniquement, le son des approches (LSP a été la chose la plus évidente) faire difficile à utiliser, mais si nous n'utilisons pas de telles approches, il rend le code fragiles et inextensible, de toute façon (parce que nous n'avons plus de raison à ce sujet).Et je pense que le résultat paradoxal que la programmation orientée objet, nous conduit à rend pas étonnant que les gens ne le ramasse pas.

De manière plus significative, puisque le logiciel est déjà fondamentalement trop dur pour l'homme normal à écrire de façon fiable et précise, doit-on vraiment être prônant une technique qui est toujours enseigné mal et semble difficile à apprendre?Si les avantages sont clairs, alors il pourrait être utile de persévérer en dépit de la difficulté, mais qui ne semble pas être le cas.

@Jeff

Par rapport à la droite de procédure de programmation, le premier principe de base de la programmation orientée objet est la notion de se cacher de l'information et de l'encapsulation.Cette idée conduit à la notion de classe qui sépare l'interface de mise en œuvre.

Qui a le plus caché de mise en œuvre:C++iostreams, ou C du FICHIER*s?

Je pense que l'utilisation de l'opaque contexte des objets (Poignées en Win32, FICHIER*s en C, pour ne citer que deux exemples bien connus--l'enfer, Poignées de vivre de l'autre côté de la mode noyau de la barrière, et il n'a vraiment pas beaucoup plus que encapsulé qui) se trouve dans le code de procédure trop;J'ai du mal à voir comment c'est quelque chose de particulier à la programmation orientée objet.

Je suppose que cela peut être une partie de pourquoi j'ai du mal à voir les avantages:les pièces qui sont évidemment bien ne sont pas spécifiques à la programmation orientée objet, considérant que les parties qui sont spécifiques à la programmation orientée objet sont évidemment pas bon!(cela ne veut pas dire qu'ils ne sont pas nécessairement mauvais, mais plutôt que je n'ai pas vu la preuve qu'ils sont largement applicables et constamment bénéfique).

Dans le seul dev blog que j'ai lu, par Joel-Sur-le-Logiciel-Fondateur-de-DONC les gars, j'ai lu il y a longtemps que OO ne conduit pas à l'augmentation de la productivité.Gestion automatique de la mémoire n'.Cool.Qui peut nier les données?

Je persiste à croire que OO est non-OO ce que la programmation avec des fonctions est de la programmation tout en ligne.

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

Lorsque le code avec des fonctions devient de code avec des méthodes, vous arrivez à supprimer des kilomètres de code.

Lorsque vous refactorisation de code pour être vraiment OO, b, c, q, et Z devenir this, this, this et this.Et puisque je ne crois pas à l'aide de la this mot-clé, vous obtenez pour supprimer des kilomètres de code.En fait, vous arrivez à le faire même si vous utilisez this.

Je ne pense pas OO est naturel métaphore.

Je ne pense pas que la langue est d'un naturel métaphore soit, je ne crois pas que Fowler "sent" sont mieux que de dire "ce code mauvais goût." Cela dit, je pense que l'OO n'est pas à propos des métaphores et des gens qui pensent que l' des objets apparaissent au sont fondamentalement manque le point. Vous définissez l'objet de l'univers, et le meilleur objet de l'univers de résultat dans le code qui est plus court, plus facile à comprendre, fonctionne mieux, ou de l'ensemble de ces quelques critères, je suis l'oubli).Je pense que les personnes qui utilisent les clients/domaine d'objets naturels comme des objets de programmation manquent le pouvoir de redéfinir l'univers.

Par exemple, lorsque vous effectuez une réservation de billets d'avion système, ce que vous appelez une réservation peut ne pas correspondre à une juridique/business réservation au tous les.

Certains concepts de base sont vraiment cool outils

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

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

Je pense que c'est une excellente façon de gérer un absolument énorme base de code.Je pense qu'il vous permet d'organiser et de réorganiser votre code et vous donne une langue pour le faire que dans (au-delà du langage de programmation dans lequel vous travaillez), et modularizes code dans un assez naturel et facile à comprendre.

La programmation orientée objet est destiné à être mal compris par la majorité des développeurs

C'est parce que c'est un eye-processus d'ouverture comme la vie:vous comprenez OO de plus en plus et avec de l'expérience, et de commencer à éviter certaines habitudes et en employant d'autres comme vous obtenez plus sage.L'un des meilleurs exemples est que vous arrêtez l'utilisation de l'héritage pour les classes que vous ne contrôlez pas, et préfèrent l' Façade motif de la place.

Concernant votre mini-essai/question

Je tiens à préciser que vous avez raison.La réutilisation est une pipe de rêve, pour la plupart.Voici une citation de Anders Hejilsberg sur ce sujet (brillant) à partir d'ici:

Si vous demandez les programmeurs débutants à écrire un calendrier de contrôle, ils ont souvent penser à eux-mêmes, "Oh, je vais écrire le meilleur du monde calendrier le contrôle!Ça va être polymorphe à l'égard du genre de calendrier.Il aura displayers, et mungers, et ce, qu', et de l'autre." Ils besoin d'expédier un calendrier d'application dans de deux mois.Ils ont mis tout cela l'infrastructure en place dans le contrôle, puis passer deux jours l'écriture d'un minable de l'application calendrier 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 sur la façon ils sont, en réalité, va mettre en œuvre l'ensemble de ces autres concretizations 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 out.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 les 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.

Avez-vous déjà créé une fenêtre à l'aide de WinAPI?

Plus de fois que je m'en souvienne.

Ensuite, vous devez savoir que vous définissez une classe (RegisterClass), créer une instance (CreateWindow), l'appel des méthodes virtuelles (WndProc) et de base-les méthodes de la classe (DefWindowProc) et ainsi de suite.WinAPI prend même la nomenclature de SmallTalk de la programmation orientée objet, en appelant la méthode “messages” (Fenêtre de Messages).

Ensuite, vous saurez également qu'il n'a pas de message d'envoi de son propre, qui est un grand vide béant.Il dispose également de merde de sous-classement.

Les poignées peuvent ne pas être héréditaire, mais ensuite, il y a final en Java.Ils ne manquent pas de classe, ils sont un espace réservé pour la classe:C'est ce que le mot “gérer” les moyens.En regardant les architectures comme MFC ou .NET WinForms il est immédiatement évident qu'à l'exception de la syntaxe, rien n'est plus différent de la WinAPI.

Ils ne sont pas héritables soit dans l'interface ou de la mise en œuvre, peu substituables, et ils ne sont pas fondamentalement différents de ce procédurale les codificateurs ont été fait depuis toujours.

Est-ce vraiment elle?Les meilleurs morceaux de la programmation orientée objet sont juste...les procédures classiques de code? C'est le big deal?

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

Se cacher de l'Information et de l'encapsulation:Critique pour n'importe quel code maintenable.Peut être fait en étant prudent dans tout langage de programmation, ne nécessite pas OO fonctionnalités, mais ce faisant, il fera de votre code légèrement OO-comme.
L'héritage:Il est important de connaître le domaine d'application pour lequel tous ceux OO est-une-sorte-de et contient-un les relations sont un ajustement parfait:Les Interfaces Utilisateur Graphiques.Si vous essayez de construire des Interfaces graphiques sans OO support de la langue, vous allez vous retrouver bâtiment OO comme caractéristiques de toute façon, et c'est plus difficile et plus enclin à l'erreur sans le support de la langue.Glade (récemment) et X11 Xt (historiquement) par exemple.

À l'aide OO fonctionnalités (surtout profondément imbriqués résumé des hiérarchies), quand il n'y a pas de point, c'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ù la programmation orientée objet est mal utilisé et je pense que c'est là que la confusion vient dans.

Juste parce que vous pouvez faire quelque chose dans un objet ne signifie pas que vous devriez.Toutefois, si cela permet de rendre votre code plus organisés et faciles à lire alors vous avez certainement doit.

Un grand exemple concret où la programmation orientée objet est très utile c'est avec un "produit" de la classe et les objets que j'utilise sur notre site web.Depuis chaque page est un produit, et chaque produit a des références à d'autres produits, il peut être source de confusion quant à ce qui produit les données que vous avez fait référence.Est-ce que "strURL" variable le lien de la page en cours, ou à la page d'accueil ou à la page de statistiques?Bien sûr, vous pourriez faire toutes sortes de différentes variables qui font référence à la même information, mais proCurrentPage->strURL, est beaucoup plus facile à comprendre (pour un développeur).

En outre, la fixation de fonctions à ces pages est beaucoup plus propre.Je peux faire proCurrentPage->CleanCache();Suivi par proDisplayItem->RenderPromo();Si je viens d'appeler ces fonctions et a assumer les données actuelles disponibles, qui sait quel genre de mal allait se produire.Aussi, si je devais passer les bonnes variables dans ces fonctions, je suis de retour pour le problème d'avoir toutes sortes de variables pour les différents produits autour de la pose.

Au lieu de cela, à l'aide d'objets, tous mes produits de données et les fonctions sont belle et propre et facile à comprendre.

Cependant.Le gros problème avec la POO, c'est quand quelqu'un croit que TOUT doit être de la programmation orientée objet.Cela crée beaucoup de problèmes.J'ai 88 tables dans ma base de données.Je n'ai que environ 6 classes, et peut-être que je devrais avoir environ 10 ans.Je certainement n'avez pas besoin 88 classes.La plupart du temps directement l'accès à ces tables est parfaitement compréhensible dans les circonstances que je l'utilise, et de la programmation orientée objet serait en fait de rendre plus difficile l'/fastidieuse pour les fonctionnalités de base de ce qui se passe.

Je crois qu'un modèle hybride d'objets où l'utile et de procédure, où la 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 deux de bon, et ils ont tous deux leur place.La plupart du temps, il y a utilise pour les deux méthodes dans chaque grand projet (Dans certains projets de plus petite taille, un seul objet, ou de quelques procédures peuvent être tout ce que 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 sacrément moyen efficace pour rendre vos programmes lisibles.La réutilisation ou pas de les 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 un logiciel "objets" modèle de l'objet réel peut-être pas une 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 les choses du monde réel, comme des factures, des commandes, des réclamations d'assurance et qu'est-ce-pas, je pense que ces choses du monde réel sont des objets.J'ai une pile sur mon bureau, donc ils doivent être réels.

Le point de la programmation orientée objet est de donner le programmeur un autre moyen de décrire et de communiquer une solution à un problème dans le code de machines et de personnes.La partie la plus importante est la communication pour les personnes.La programmation orientée objet permet au programmeur de déclarer ce qu'ils signifient dans le code par le biais de règles qui sont appliquées dans le langage OO.

Contrairement à beaucoup d'arguments sur ce sujet, la programmation orientée objet et les concepts OO sont omniprésentes tout au long de l'ensemble du code, y compris le code, dans la non-programmation orientée objet, les langages comme le C.Beaucoup avancé non-OO programmeurs vont rapprocher les caractéristiques des objets de même dans les langages à objets.

Ayant OO construit dans la langue donne simplement le programmeur un autre moyen d'expression.

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

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow