Pourquoi la POO est-elle difficile? [fermé]


92

Quand j'ai commencé à utiliser un langage orienté objet (Java), je me suis plutôt contenté de "Cool" et j'ai commencé à coder. Je n'y ai jamais vraiment pensé jusqu'à récemment, après avoir lu beaucoup de questions sur la programmation orientée objet. L’impression générale que j’entends est que les gens ont du mal à le faire. Puisque je n'y ai pas pensé aussi dur et que je ne dirais pas que je suis un génie, je pense que j'ai dû manquer quelque chose ou l'avoir mal comprise.

Pourquoi la POO est-elle difficile à comprendre? Est- ce difficile à comprendre?


72
Je réponds avec: Ce n'est pas difficile à comprendre, mais difficile à maîtriser. La programmation dans son ensemble se fait de cette façon.
Steven Evers

2
euh, ce n'est pas? Peut-être que les programmeurs qui ne peuvent pas programmer ont du mal à blâmer les oops au lieu de leurs lignes de code? Je ne sais pas mais je n'ai jamais entendu dire que c'était difficile à comprendre. Cependant, j’ai vu ppl dire que fonctionnel est bizarre, d’autant plus qu’ils ne peuvent pas changer la valeur de leur variable.

5
@ acidzombie42: fonctionnel n'est pas bizarre du tout. il n'est pas nécessaire d'écrire une liste de commandes pour modifier le contenu des variables représentant un emplacement dans la RAM. les variables représentent des valeurs, vous ne changez pas de valeurs; 42 reste 42, x reste x - quel que soit x. vous écrivez des fonctions qui associent leurs paramètres aux résultats. les valeurs sont les suivantes: nombres, listes de valeurs, fonctions de valeurs en valeurs, programmes produisant des effets secondaires et une valeur résultante lors de l'exécution, etc. de cette façon, le résultat de la fonction principale sera calculé par le compilateur, c’est-à-dire le programme qui peut être exécuté.
comonad

5
J'ai appris Haskell récemment. Plus j'apprends et je comprends en programmation fonctionnelle, plus je pense que la POO est difficile. Je pense que la raison principale en est que la POO tente de lier les données (objet / classe) à la fonction qui les opère (méthode). C’est la source du problème et de nombreux modèles de conception OOP sont conçus pour éviter de lier les données et les fonctions ensemble. Exemple, le modèle d'usine est utilisé pour séparer le constructeur (qui est une fonction) de l'objet réel sur lequel il opère.
ming_codes

1
Parce que c'est mal nommé. Il devrait s'agir d'une programmation orientée sujet, en ce sens que le sujet exécute l'action (verbe) et que l'objet reçoit l'action - John a lancé la balle. Donc, johnsBall.throw () n'a pas vraiment de sens.
Chris Cudmore

Réponses:


120

J'ai personnellement trouvé la mécanique de la POO assez facile à comprendre. La partie difficile pour moi était le "pourquoi" de cela. Lorsque j’y ai été exposé pour la première fois, c’était une solution à la recherche d’un problème. Voici quelques raisons pour lesquelles je pense que la plupart des gens trouvent cela difficile:

  1. IMHO enseigner OO depuis le début est une idée terrible. Le codage procédural n'est pas une "mauvaise habitude" et constitue le bon outil pour certains emplois. Les méthodes individuelles dans un programme OO ont tendance à être de toute façon assez procédurales. En outre, avant d’apprendre suffisamment bien la programmation procédurale pour que ses limitations deviennent visibles, l’objet d’accueil ne semble pas très utile à l’élève.

  2. Avant de pouvoir réellement comprendre OO, vous devez connaître les bases des structures de données et des fonctions de liaison tardive / d'ordre supérieur. Il est difficile de provoquer un polymorphisme (qui consiste essentiellement à faire passer un pointeur sur des données et un ensemble de fonctions qui agissent sur les données) si vous ne comprenez même pas les concepts de la structuration des données au lieu d'utiliser uniquement des primitives et de transmettre des fonctions d'ordre supérieur / pointeurs vers des fonctions.

  3. Les modèles de conception doivent être enseignés comme étant quelque chose de fondamental pour OO, pas quelque chose de plus avancé. Les modèles de conception vous aident à voir la forêt à travers les arbres et à donner des exemples relativement concrets d'OT pouvant simplifier des problèmes réels, et vous voudrez bien les apprendre de toute façon. En outre, une fois que vous avez vraiment un impact positif, la plupart des modèles de conception deviennent évidents après coup.


5
réponse fabuleuse, surtout le numéro 1. Bien sûr, les méthodes dans OO ressemblent à des méthodes dans une langue procédurale, mais elles sont maintenant logées dans des objets qui ont aussi un état.
Dan Rosenstark

3
J'aime particulièrement vos premier et troisième points. Mon ami est gaga pour les motifs, et je lui répète que si vous utilisez une bonne POO, la plupart d'entre eux découlent très naturellement du problème initial.
CodexArcanum

7
+1 pour "La partie difficile pour moi était le" pourquoi "de celui-ci". Il faut du temps et des efforts pour comprendre et appliquer les bases du langage (encapsulation), les principes de conception et les méthodes de refactorisation, en vue de solutions communes (modèles de conception).
Belun

12
Je suis d'accord avec n ° 1, avec la mise en garde que vous devez faire un meilleur travail d'expliquer OO à des personnes qui savent déjà programmer de manière procédurale que ce qui était fait quand j'apprenais. Non, il n'est ni utile ni informatif de parler d'une Catclasse dont hérite Mammal, utilisez un exemple réel d'un programme réel que nous aurions écrit de manière procédurale. Comme une simple structure de données.
Carson63000

4
-1 Les motifs de conception sont tellement surestimés aujourd'hui. Ils sont importants, certes, mais: d’abord, ils sont importants pour tous les paradigmes: fonctionnels, structurés, ainsi que OO; et deuxièmement, ils ne font pas partie du paradigme, mais constituent un complément pratique que vous pouvez utiliser, comme beaucoup d'autres. @SoftwareRockstar l'explique bien dans sa réponse.
CesarGon

56

Je pense qu'il y a quelques facteurs qui n'ont pas encore été mentionnés.

Tout d’abord, du moins dans la "pure OOP" (par exemple, Smalltalk) où tout est un objet, vous devez tordre votre esprit dans une configuration peu naturelle pour penser à un nombre (pour un seul exemple) comme un objet intelligent au lieu de juste une valeur - car en réalité, 21(par exemple) n'est vraiment qu'une valeur. Cela devient particulièrement problématique lorsque d’un côté on vous dit que l’un des grands avantages de la POO est de modéliser plus fidèlement la réalité, mais vous commencez par prendre ce qui ressemble beaucoup à une vue inspirée par le LSD des parties les plus fondamentales et les plus évidentes de réalité.

Deuxièmement, l'héritage en POO ne suit pas de près les modèles mentaux de la plupart des gens. Pour la plupart des gens, classer les choses de manière plus spécifique n’a pas la moindre ressemblance avec les règles absolues nécessaires pour créer une hiérarchie de classes qui fonctionne. En particulier, créer un class Dqui hérite d’un autre class Bsignifie que les objets de class Dpartage partagent absolument, positivement toutes les caractéristiques de class B. class Dpeut ajouter des caractéristiques nouvelles et différentes, mais toutes les caractéristiques de class Bdoivent rester intactes.

En revanche, lorsque les gens classifient les choses mentalement, ils suivent généralement un modèle beaucoup plus souple. Par exemple, si une personne établit des règles sur ce qui constitue une classe d'objets, il est assez typique que presque toutes les règles puissent être enfreintes tant que suffisamment d'autres règles sont suivies. Même les quelques règles qui ne peuvent pas vraiment être enfreintes peuvent presque toujours être "étirées" un peu.

Juste par exemple, considérons "voiture" en tant que classe. Il est assez facile de voir que la grande majorité de ce que la plupart des gens considèrent comme des "voitures" a quatre roues. La plupart des gens, cependant, ont vu (au moins une photo de) une voiture avec seulement trois roues. Quelques-uns d'entre nous du bon âge se souviennent également d'une voiture de course ou de deux voitures du début des années 80 (ou plus) à six roues - et ainsi de suite. Cela nous laisse fondamentalement trois choix:

  1. N'affirmez rien sur le nombre de roues d'une voiture - mais cela tend à laisser supposer implicitement que ce sera toujours 4 et que le code risque de casser pour un autre numéro.
  2. Affirmer que toutes les voitures ont quatre roues et classer simplement les autres comme "pas des voitures" même si nous savons qu’elles le sont vraiment.
  3. Concevez cette classe de manière à permettre la variation du nombre de roues, juste au cas où, même s'il y a de fortes chances pour que cette capacité ne soit jamais nécessaire, utilisée ou testée correctement.

L’enseignement de la programmation orientée objet vise souvent à créer d’énormes taxonomies - par exemple, des morceaux de ce qui serait une hiérarchie géante de toute la vie connue sur la Terre, ou quelque chose du même ordre. Cela soulève deux problèmes: tout d’abord, cela a tendance à amener beaucoup de gens à se concentrer sur d’énormes quantités d’informations qui n’ont absolument rien à voir avec la question à l’examen. À un moment donné, j'ai assisté à une discussion assez longue sur la manière de modéliser les races de chiens et sur la question de savoir si, par exemple, le "caniche miniature" devait hériter du "caniche de taille normale", ou inversement, ou s'il devait exister une base abstraite "Caniche" "class, avec" caniche grandeur nature "et" caniche miniature "qui en héritent tous les deux. Ce qu’ils semblaient tous ignorer, c’était que l’application était censée permettre de garder trace des permis de chiens,

Deuxièmement et surtout, cela amène à mettre l’accent sur les caractéristiques des articles plutôt que sur les caractéristiques importantes pour la tâche à accomplir. Elle conduit vers les choses de modélisation comme ils sont, où ( la plupart du temps) ce qui est vraiment nécessaire est la construction du modèle le plus simple qui comblera nos besoins, et d' utiliser l' abstraction pour répondre aux nécessaires sous-classes pour adapter l'abstraction que nous avons construit.

Enfin, je le répète: nous suivons lentement le même chemin emprunté par les bases de données au fil des ans. Les premières bases de données suivaient le modèle hiérarchique. Hormis le fait de se concentrer exclusivement sur les données, il s’agit d’un héritage unique. Pendant un court laps de temps, quelques bases de données ont suivi le modèle de réseau - essentiellement identique à l'héritage multiple (et vu sous cet angle, les interfaces multiples ne sont pas assez différentes des classes de base multiples pour être remarquées ou gérées de manière pertinente).

Cependant, il y a bien longtemps, les bases de données ont largement convergé vers le modèle relationnel (et même si elles ne sont pas du code SQL, les bases de données "NoSQL" actuelles sont aussi relationnelles à ce niveau d'abstraction). Les avantages du modèle relationnel sont suffisamment connus pour que je ne me permette pas de les répéter ici. Je rappellerai simplement que l’analogue le plus proche du modèle relationnel que nous avons en programmation est la programmation générique (et désolé, mais malgré son nom, les génériques Java, par exemple, ne sont pas vraiment éligibles, bien qu’ils constituent un tout petit pas dans la bonne direction).


Très bien dit, et surtout que la plupart des problèmes de POO que vous posez ne concernent pas seulement les débutants qui le comprennent, mais plutôt des problèmes de POO en général que la plupart des programmeurs de POO apprennent à réfléchir. Je travaille depuis peu avec la conception de jeux où un modèle de composant fonctionne très bien, ce qui correspond plus étroitement à la notion de modèle relationnel qu'à un modèle hiérarchique.
CodexArcanum

7
Heh, je pensais juste à cela l'autre jour. Comme tous les premiers supports d'apprentissage que j'ai lus sur OOP semblaient se concentrer sur l'héritage, alors que mon expérience me dit de plus en plus que l'héritage est généralement inutile, voire nuisible.
rmac

Cela ressemble à de la programmation orientée table , même si je dirais que je réalise maintenant que la POO n'est pas la solution miracle du développement logiciel.
OnesimusUnbound

1
@OnesimusUnbound: la différence est que la programmation générique est un moyen pratique et concret de réaliser quelque chose, alors que la programmation orientée table est principalement un délire de fous sur une théorie sur la manière dont quelque chose pourrait fonctionner (lisez les anciens posts de TopMind dans comp.object, et vous Je vais voir ce que je veux dire - en fait, les messages ne sont peut-être pas tous vieux; pour autant que je sache, il continue même aujourd'hui).
Jerry Coffin

3
C'est pourquoi les interfaces sont si géniales. Vous prenez la modélisation d'héritage et l'inversez en une approche d'abord. Par exemple, avec l'exemple de chien, on peut supposer que chaque chien a un genre et jusqu'à deux super-espèces (une pour chaque parent) pour une race particulière. Il peut également y avoir une propriété de liste contenant des traits, mais la variété possible rend inutile de les intégrer dans une structure définie. Il est préférable de procéder à une recherche approfondie pour explorer les caractères et combiner des races similaires en fonction de ces résultats.
Evan Plaice

26

La POO nécessite la capacité de penser de manière abstraite; un cadeau / malédiction que peu de gens, même les programmeurs professionnels, ont réellement.


35
Toute la programmation est abstraite.
JeffO

28
@ Jeff O - Je ne suis pas d'accord. La programmation ne nécessite que la capacité de dire à quelqu'un comment faire quelque chose étape par étape. Si vous pouvez dire à quelqu'un comment faire un sandwich au beurre d'arachide et à la gelée, vous avez la possibilité de taper des commandes dans une interface de programmation. C'est un ensemble de compétences complètement différent de celui de la modélisation abstraite de l'ap, du sandwich B & J et de la manière dont il interagit avec le monde.
John Kraft

16
Donner à quelqu'un deux crayons, puis un autre crayon et lui demander combien de crayons il a, c'est concret. 2 + 1 = 3 est abstrait.
JeffO

17
Je suis d'accord avec Jeff. La programmation consiste essentiellement à gérer les abstractions. Du moins, cela vaut pour tout, sauf le flux de programme le plus élémentaire (car tout le reste sera trop complexe sans abstractions). Il y a une phase distincte dans l’apprentissage à programmer lorsque le novice apprend à contrôler les abstractions. C'est là que la métaphore de la recette tombe. La programmation n'a rien à voir avec la cuisson et, même si un algorithme individuel peut être assimilé à une recette, la programmation est fondamentalement différente de la mise en œuvre d'algorithmes isolés.
Konrad Rudolph

2
@ KonradRudolph Grand point. +1 pour "Tout le reste sera trop complexe sans abstractions" .
Karthik Sreenivasan le

21

Je pense que vous pouvez résumer la difficulté de base de cette façon:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

Bien sûr, les gens peuvent s’habituer à la cartographie de "gauche" en 270, et ouais, en disant "Car.Turn" au lieu de "tourner la voiture" n’est pas un si énorme bond en avant. MAIS, pour bien manipuler ces objets et pour les créer, vous devez inverser votre façon de penser.

Au lieu de manipuler un objet, nous lui demandons de faire les choses lui-même. Cela ne vous semblera peut-être plus difficile, mais il est étrange de dire qu’une fenêtre s’ouvre. Les gens qui ne sont pas habitués à cette façon de penser doivent lutter sans cesse avec cette bizarrerie jusqu'à ce qu'elle devienne naturelle.


7
Bonne perspicacité. Je pense que le problème est que dans la vie réelle, il n'y a pas grand chose qu'un "objet" puisse faire qui ne soit pas lié à d'autres objets. OO fonctionne bien dans la mesure où il est dit aux objets de modifier leur état interne: rectangle.enlarge (margin_in_pixels) mais j'ai réalisé les limites il y a des années. Un jour, nous, les programmeurs, installions du matériel. Quelqu'un a mal entendu "tourner.tour" Drôle, mais ça m'a fait penser: bien sûr, une vis peut changer l'orientation, mais c'est vraiment une opération entre le cabinet et la vis; aucun objet ne peut effectuer la tâche elle-même. OO n'est tout simplement pas assez bon.
DarenW

3
+1, après des années d'écriture "substr (date, 0,4)", il est difficile d'écrire "date.substring (0,4)"
ern0

4
+1 pour l'extrait de code. Il décrit clairement un processus de pensée réel.
Karthik Sreenivasan le

2
Je voudrais en fait le lire comme une commande que vous envoyez. Comme dans "Dites à la voiture de tourner à gauche". Oop était basé sur l’envoi de messages à des objets, c’est ainsi que je l’interprèterais.
Bunglestink

1
Bonne perspective, alors, peut-être que la programmation orientée objet est plus adaptée à la modélisation de "systèmes d'agents"?
Qbik

21

Tout paradigme nécessite une certaine poussée "à la limite" à saisir, pour la plupart des gens. Par définition, il s’agit d’un nouveau mode de pensée. Il faut donc laisser de côté certaines notions anciennes et bien comprendre pourquoi ces nouvelles notions sont utiles.

Je pense que le problème tient en grande partie au fait que les méthodes utilisées pour enseigner la programmation informatique sont plutôt médiocres en général. La POO est si courante maintenant qu'elle n'est plus aussi perceptible, mais vous la voyez souvent dans la programmation fonctionnelle:

  • des concepts importants sont cachés derrière des noms impairs (FP: Qu'est-ce qu'une monade? OOP: Pourquoi les appelle-t-on parfois des fonctions et des méthodes d'autres fois?)

  • Les concepts étranges sont expliqués en métaphore plutôt qu'en termes de ce qu'ils font réellement, ou pourquoi vous les utiliseriez, ou pourquoi quiconque pensait les utiliser (FP: Une monade est une combinaison spatiale, elle enveloppe du code. OOP: An objet est comme un canard, il peut faire du bruit, marcher et hérite de Animal)

  • les bonnes choses varient d'une personne à l'autre, il est donc difficile de dire quel sera le point de basculement pour un élève et souvent, l'enseignant ne s'en souvient même pas. (FP: Oh, les monades vous permettent de cacher quelque chose dans le type et de le continuer sans avoir à écrire explicitement ce qui se passe à chaque fois. OOP: Oh, les objets vous permettent de garder les fonctions pour une sorte de données avec ces données.)

Le pire, c’est que, comme l’indique la question, certaines personnes comprendront immédiatement pourquoi le concept est bon et d’autres pas. Cela dépend vraiment du point de basculement. Pour moi, il était essentiel de comprendre que les objets stockaient des données et des méthodes pour stocker ces données. Ensuite, tout le reste était une extension naturelle. Ensuite, j'avais des sauts plus tard, comme la réalisation du fait qu'un appel de méthode à partir d'un objet est très similaire à faire un appel statique avec cet objet comme premier paramètre.

Les petits sauts plus tard aident à affiner la compréhension, mais c'est le premier qui prend une personne de "La POO n'a pas de sens, pourquoi les gens font-ils cela?" to "OOP est le meilleur, pourquoi les gens font-ils autre chose?"


8
Je déteste particulièrement le métaphorisme, le plus souvent, ils confondent plutôt que de décrire.
Lie Ryan

3
"Ensuite, j'avais des sauts plus tard, comme la réalisation du fait qu'un appel de méthode à partir d'un objet est très similaire à un appel statique avec le même paramètre que cet objet." J'aimerais que cela soit davantage souligné dès le début, comme c'est le cas dans des langages comme Python.
Jared Updike

1
Mon problème avec l'utilisation de métaphores pour expliquer les concepts est que l'enseignant s'arrête souvent à la métaphore, comme si cela expliquait tout. Non, ce n'est pas une explication complète. c'est juste une illustration pour nous aider à comprendre l' esprit de l' explication.
Jhocking

Très bonne réponse! +1 pour expliquer que la première étape de la compréhension de la programmation orientée objet sera plus importante que ce qui viendra plus tard sous forme d'extensions naturelles avec une bonne compréhension de la base. : D
Karthik Sreenivasan le

Idem sur l'apprentissage "saut": Quand j'ai commencé à percevoir la POO comme une construction "simplement" modulaire / structurée / par étapes, mais sur des stéroïdes; quand j'ai réécrit des programmes COBOL très anciens et mutilés au-delà de la maintenabilité. Malgré la portée globale de COBOL, j’avais essentiellement appliqué les principes OO avec des structures d’enregistrement personnalisées, des variables à usage unique et des paragraphes (méthodes) étroitement ciblés, modulaires et structurés.
radarbob

15

Parce que l'explication de base de la programmation orientée objet a très très peu à voir avec la manière dont elle est utilisée sur le terrain. La plupart des programmes d’enseignement l’essaient d’utiliser un modèle physique, tel que "Pensez une voiture en tant qu’objet, et roule en tant qu’objets, et les portes, et la transmission ...", mais en dehors de quelques cas obscurs de programmation de simulation, les objets sont beaucoup plus souvent utilisés pour représenter des concepts non physiques ou pour introduire un indirection. L'effet est que cela fait que les gens le comprennent intuitivement de manière erronée.

Enseigner à partir de modèles de conception est une bien meilleure façon de décrire la POO, car il montre aux programmeurs comment résoudre certains problèmes de modélisation réels à l'aide d'objets, plutôt que de les décrire de manière abstraite.


13

Je suis en désaccord avec la réponse de dsimcha pour l'essentiel:

  1. Enseigner OO depuis le début n'est pas vraiment une mauvaise idée en soi, ni enseigner des langues procédurales. Ce qui est important, c’est que nous apprenions aux gens à rédiger un code clair, concis et cohérent, qu’il s’agisse de OO ou de procédure.

  2. Les méthodes individuelles dans de bons programmes OO NE SONT PAS tendance à être procédurales. Cela devient de plus en plus vrai avec l'évolution des langages OO (lisez C # car autre que C ++, c'est le seul autre langage OO que je connaisse) et leur syntaxe devient de plus en plus complexe de jour en jour (lambdas, LINQ to object, etc.). La seule similitude entre les méthodes et procédures OO dans les langages procéduraux est la nature linéaire de chacun, ce qui, je le doute, changerait de sitôt.

  3. Vous ne pouvez pas maîtriser un langage procédural sans comprendre les structures de données. Le concept de pointeur est aussi important pour les langages procéduraux que pour les langages OO. Pour passer des paramètres par référence, par exemple, ce qui est assez courant dans les langages procéduraux, vous devez comprendre les pointeurs autant que nécessaire pour apprendre un langage OO.

  4. Je ne pense pas du tout que les modèles de conception devraient être enseignés tôt dans la programmation OO, car ils ne sont pas fondamentaux du tout pour la programmation OO. On peut certainement être un bon programmeur OO sans rien connaître des modèles de conception. En fait, une personne peut même utiliser des modèles de conception bien connus sans même savoir qu'ils sont documentés en tant que tels avec leurs noms propres et que des livres sont écrits à leur sujet. Ce qui doit être enseigné fondamentalement, ce sont les principes de conception tels que la responsabilité unique, la fermeture ouverte et la séparation des interfaces. Malheureusement, beaucoup de personnes qui se considèrent comme des programmeurs OO de nos jours ne connaissent pas ce concept fondamental ou choisissent simplement de l'ignorer et c'est pourquoi nous avons tellement de code OO de déchets.

Pour répondre à la question de l'affiche originale, oui, OO est un concept plus difficile à comprendre que la programmation procédurale. C'est parce que nous ne pensons pas en termes de propriétés et de méthodes des objets de la vie réelle. Par exemple, le cerveau humain ne considère pas facilement «TurnOn» comme une méthode de télévision, mais le considère comme une fonction de l’allumage humain de la télévision. De même, le polymorphisme est un concept étranger au cerveau humain qui voit généralement chaque objet de la vie réelle par un seul "visage". Encore une fois, l'héritage n'est pas naturel pour notre cerveau. Ce n'est pas parce que je suis développeur que mon fils en serait un. De manière générale, le cerveau humain doit être formé pour apprendre le langage OO, tandis que les langages procéduraux lui sont plus naturels.


2
+1 - Moi aussi, je ne pense pas que les modèles de conception soient nécessaires à l'enseignement OOP au niveau fondamental, vous pouvez être un bon programmeur OOP et ne connaître aucun modèle de conception. D'un autre côté, vous avez tendance à voir les modèles de conception connus émerger naturellement des bons programmeurs POO. Les modèles de conception sont toujours découverts, pas inventés.
Gary Willoughby

1
+1 - Excellente réponse. J'aime le 4ème point que vous avez énoncé. Il est très vrai que l' on peut être un bon programmeur OO sans savoir ce que sont vraiment les modèles de design!
Karthik Sreenivasan le

Je suis d'accord avec # 4 parce que la plupart des modèles de conception ne sont qu'une approche bubblegum / duct tape pour coder de manière expressive autour des limites du langage. Dans d'autres paradigmes, les modèles de conception peuvent être complètement différents et basés sur leurs propres contraintes. Je suis en désaccord avec 2, LINQ et les lambdas sont toujours exécutés de manière procédurale, ils fournissent simplement des abstractions soigneusement emballées de niveau supérieur. Consacrez un temps considérable au développement avec un langage procédural / fonctionnel typé dynamiquement, tel que JavaScript, et vous verrez ce que je veux dire.
Evan Plaice

6

Je pense que beaucoup de programmeurs ont d’abord des difficultés avec la conception et la planification initiales. Même si quelqu'un fait tout le design pour vous, il est toujours possible de rompre avec les principes de la POO. Si je prends un tas de code spaghetti et le dépose dans une classe, est-ce vraiment la POO? Quelqu'un qui ne comprend pas la POO peut toujours programmer en Java. Aussi, ne confondez pas la difficulté à comprendre avec ne pas vouloir suivre une certaine méthodologie ou être en désaccord avec elle.


5

Vous devriez lire des objets jamais? Eh bien, presque jamais. (Adhésion à l'ACM requise) par Mordechai Ben-Ari qui suggère que la POO est tellement difficile, car ce n'est pas un paradigme qui est naturel pour modeler quoi que ce soit. (Bien que des réserves soient émises au sujet de l'article, car les critères qu'il pense qu'un programme doit satisfaire pour indiquer qu'il est écrit selon le paradigme de la programmation orientée objet par opposition à un paradigme de procédure utilisant un langage orienté objet ne sont pas clairs.)


5

La programmation orientée objet en soi n'est pas difficile.

La partie difficile consiste à bien le faire. Où placer la séparation entre le code afin de pouvoir déplacer facilement des éléments vers l'objet de base commun et les étendre ultérieurement? Comment rendre votre code utilisable par d’autres personnes (extension de classes, insertion de proxies, méthode de substitution) sans passer à travers les étapes pour le faire.

C’est la partie la plus difficile, et si cela est bien fait, cela peut être très élégant et, si cela est mal fait, cela peut être très maladroit. Mon expérience personnelle est qu’il faut beaucoup de pratique pour avoir été dans toutes les situations où vous souhaiteriez que vous l’ayez fait différemment, afin de le faire suffisamment bien cette fois - ci.


"Mon expérience personnelle est qu'il faut beaucoup de pratique pour avoir été dans toutes les situations où vous souhaiteriez que vous l'ayez fait différemment, afin de le faire suffisamment bien cette fois." La POO semble être une liste codifiée de moyens de ne pas commettre d'erreur, ce qui n'a pas de sens tant que vous ne l'avez pas fait de manière erronée.
Jared Updike

@ Jared, pas tout à fait. Comparez cela à la résolution de sodukus. Il existe différentes astuces pour le résoudre, mais cela prend du temps et de la pratique pour bien le faire sans revenir en arrière.

Si on pense à un "objet de base commun" comme un ancêtre commun, alors cela devient clair. C'est vraiment aussi simple que cela. C'est difficile à comprendre car il y a tellement d'explications trompeuses de la part de gens qui cherchent à avoir l'air malins.
annoying_squid

4

Je viens de regarder une vidéo de Richard Feynman qui explique comment des gens peuvent avoir des méthodologies complètement différentes dans leur tête lorsqu'ils pensent - je veux dire complètement différent.

Lorsque je fais de la conception de haut niveau, je visualise des objets, je peux les voir, voir leurs interfaces et voir quelles voies doivent être parcourues par les informations.

J'ai également du mal à me souvenir des détails et j'ai trouvé que OO était un excellent outil d'aide à l'organisation. Il était beaucoup plus facile de trouver une fonctionnalité que de parcourir une liste de sous-routines mal organisée.

Pour moi, OO était un grand avantage, mais si vous ne visualisez pas de la même manière ou si vous ne faites pas une architecture de haut niveau, c'est probablement inutile et ennuyeux.


+1, je ressens la même chose, mais il y a beaucoup de pressions dans la direction opposée, y compris Ruby mixins ... ce qui vous fait comprendre que la stricte OO n'est pas pour tout le monde.
Dan Rosenstark

@Yar Oui, c'est à peu près ce que je disais. Personnellement, je ne peux personnellement rien imaginer de mieux (et Ruby m'a conduit au NUTS pendant une année d'utilisation), mais je commence à accepter que tout le monde a une vision différente. Peut-être que certaines personnes utilisent le toucher ou l'audition pour réfléchir au lieu de visualiser et OO ne les prend pas pour elles.
Bill K

Je pense que cela contribue également à encourager des conventions de nommage plus naturelles. Vous n'avez plus besoin de coder le type d'une fonction dans le nom de la fonction (comme INSTR) - car le nom est attaché au type (comme string::find)
Ken Bloom

@Ken même si je suis d'accord, je pense que c'est plus une question de dactylographie forte que d'OO - Ruby a OO mais vous perdez beaucoup d'informations de type à cause de la frappe au canard - Ruby a simplement tendance à dire "envoyer (le)" et à attendre vous devez savoir quelle méthode magique "il" doit implémenter pour fonctionner.
Bill K

@ Bill, tu as raison. C'est plus une question de langages qui supportent la programmation générique. Vous pouvez obtenir de belles conventions de nommage naturelles avec des systèmes de modules et de classes de types comme celui de Haskell, et Haskell n’a aucun sens. Si C était surchargé, vous pourriez obtenir le même genre de noms génériques en C.
Ken Bloom

4

Je l' avais fait la programmation d' un peu juste GW-Basic et Turbo Pascal avant d' être introduit à OO, donc d' abord il SAVIEZ faire ma tête.

Je ne sais pas si c'est ce qui arrive aux autres, mais pour moi, c'était comme ça: mon processus de pensée concernant la programmation était purement procédural. Comme dans "tel ou tel événement, tel ou tel événement se produit ensuite", etc. Je n'ai jamais considéré que les variables et les données étaient autre chose que des acteurs éphémères du déroulement du programme. La programmation était "le flux d'actions".

Je suppose que ce qui n’était pas facile à comprendre (aussi stupide que cela me paraisse à l’heure actuelle), c’est l’idée que les données / variables ont vraiment de l’importance , dans un sens plus profond que le simple fait d’être des acteurs éphémères dans un «flux» de programmes. Autrement dit: j'ai continué à essayer de comprendre ce qui se passait plutôt que ce qui est , ce qui est la véritable clé pour le comprendre .


Point de vue intéressant. Alors que je lutte pour donner du sens à un projet C ++ massif, je pense que je suis l’inverse, pensant principalement en termes de données, le "chemin du signal" de bits allant de "entrées" à certaines "sorties". Bien que moi aussi j'ai beaucoup travaillé sur Basic et Pascal, mes premières réflexions techniques ont été en électronique.
DarenW

3

Je ne pense pas que ce soit difficile à comprendre, mais il se peut que beaucoup de programmeurs interrogés soient nouveaux dans le concept et proviennent de langages procéduraux.

D'après ce que j'ai vu / lu, beaucoup de gens (du moins sur les forums) recherchent un «résultat» de la POO. Si vous êtes un programmeur procédural qui ne retourne pas et ne prolonge pas son code, il peut être difficile de comprendre les avantages.

En outre, il y a beaucoup de mauvaises OOP, si les gens lisent / voient cela, il est alors facile de voir pourquoi ils pourraient trouver cela difficile.

OMI, vous devez attendre le déclic ou être enseigné par une personne ayant de vraies connaissances, je ne pense pas que vous puissiez vous précipiter.


5
Si vous venez d'un milieu académique, les types de programmes de jouets que vous écrivez là-bas semblent vraiment inutiles en POO. J'ai commencé à apprendre le C à l'université, et c'était assez facile à comprendre car chaque programme comptait une page, moins de 100 lignes. Ensuite, vous essayez d’apprendre la POO et il faut tout ce bagage et cette surcharge d’objets pour faire la même chose, et cela semble inutile. Mais tant que vous n'avez pas écrit un programme sur plusieurs fichiers et quelques milliers de lignes, il est difficile de comprendre pourquoi un style de programmation est utile.
CodexArcanum

3

Je pense que la raison pour laquelle la POO est difficile pour beaucoup est que les outils ne le facilitent pas vraiment.

Les langages informatiques actuels sont une abstraction de ce qui se passe dans l'ordinateur.

La programmation orientée objet est un moyen abstrait de représenter les abstractions.

Nous utilisons donc une abstraction pour construire des abstractions avec une abstraction. Ajoutez à cela que nous résumons généralement des interactions physiques / sociales très complexes et, ce n’est pas étonnant.


2

En fait, j'ai un blog intitulé "Luttes dans la programmation orientée objet", qui est né de certaines de mes difficultés à l'apprendre. Je pense que c’était particulièrement difficile pour moi de comprendre car j’avais passé beaucoup de temps à utiliser la programmation procédurale et j’ai eu du mal à comprendre l’idée qu’un objet puisse être représenté par un ensemble d’attributs et de comportements (j’étais habitué à simplement une collection de variables et de méthodes).

En outre, il existe de nombreux concepts qui rendent un langage orienté objet - héritage, interfaces, polymorphisme, composition, etc. Il y a vraiment beaucoup à apprendre sur sa théorie avant de pouvoir écrire du code efficacement, et de manière orientée objet. En termes de programmation procédurale, il s’agit simplement de comprendre des choses comme l’allocation de mémoire pour les variables et les appels de point d’entrée à d’autres méthodes.


D'accord - l'un des problèmes que les gens rencontrent avec OO est qu'ils se sont formés à penser «procéduralement». OO n'a rien de intrinsèquement difficile, mais si vous "connaissez" les techniques procédurales, il serait assez surprenant de voir une autre façon de structurer les choses.
Kirk Broadhurst

Nul doute que c’est une façon de penser totalement différente de la programmation procédurale. Mais contrairement à ce que beaucoup disent, ce n’est pas A) une façon de penser non naturelle, et B) compliquée. Je pense juste que ce n'est pas bien enseigné.
annoying_squid

2

Motivation. Il est plus difficile d'apprendre quelque chose quand on ne voit pas pourquoi, et aussi quand on ne peut pas regarder ce qu'on a fait et se demander si on l'a bien fait ou pas.

Ce qu'il faut, ce sont des petits projets qui utilisent OO pour faire des choses utiles. Je suggérerais de parcourir un livre sur les modèles de conception et d'en trouver un qui soit évidemment utile et qui fonctionne bien avec OO. (J'ai utilisé Strategy la première fois que je l'ai essayé. Quelque chose comme Flyweight ou Singleton serait un mauvais choix, car ce sont des façons d'utiliser des objets en général, de ne pas utiliser d'objets pour accomplir quelque chose.)


Les gens parlent toujours de Singleton, mais ensuite il est toujours invité à la fête. Mais c’est vrai, c’est le DP non-OO OO.
Dan Rosenstark

-1

Je pense que cela dépend de l'âge (l'âge en tant qu'indicateur de l'expérience) et, plus important encore, de l'intérêt. Si vous êtes "jeune" (c'est-à-dire vert, peut-être) et que vous n'avez jamais pensé autrement, cela semble assez simple. D'autre part, si vous pensez que c'est la chose la plus cool que vous ayez jamais vue - ce qui m'est arrivé à 28 ans ou quelque chose du genre - c'est facile à dire.

D'autre part, si vous pensez, comme l'ont fait bon nombre de mes étudiants Java, "pourquoi apprenons-nous cela, ce n'est qu'une lubie", il est pratiquement impossible d'apprendre. Cela est vrai avec la plupart des technologies.


1
OO une mode? Quel âge ont vos étudiants - je suppose que cette "lubie" est plus âgée qu'ils ne le sont (premier OO que j'ai connu - que je savais que je connaissais - était Simula vers 1983/24 et Simula n'était pas nouvelle à ce moment-là)
Murph

@Murph C'était vers 2004-2005 et les étudiants avaient certainement plus de 45 à 50 ans (programmeurs professionnels chez Iberia).
Dan Rosenstark

ok, je peux voir comment ils ont pu rater le début de la chose OO. Mais en 2004/2005, nous étions déjà bien familiarisés avec .NET, qui est pratiquement un mur OO (-: il existe des projets en cours de développement que l’on pourrait qualifier de manies, mais ceux qui ne font pas long feu ont tendance à évoluer rapidement en bonnes choses
Murph

1
@Murph pour être honnête, ces gars-là étaient des programmeurs sur ordinateur qu'ils essayaient de convertir en Java. C'était en fait une expérience amusante et unique (tarif pas normal pour mes journées Java Trainer). Il est vrai, cependant, qu'ils ont vu beaucoup de choses aller et venir, mais évidemment, OO est plus qu'une mode. Sur une note séparée: j'espérais un peu que ce test unitaire allait devenir une lubie, mais maintenant je constate que j'ai beaucoup de tests unitaires à écrire ... :)
Dan Rosenstark

-1

Quel que soit le paradigme choisi (POO, fonctionnel, etc.), pour écrire un programme informatique, vous devez savoir quelles étapes votre programme fera.

La manière naturelle de définir un processus consiste à écrire ses étapes. Pour les tâches plus importantes, décomposez la tâche en étapes plus petites. C’est la procédure à suivre, c’est ainsi que l’ordinateur fonctionne, c’est ainsi que vous parcourez votre liste de contrôle étape par étape.

La POO est une façon de penser différente. Au lieu de penser à une liste de contrôle des tâches qui doit être effectuée étape par étape, vous pensez aux objets, à leurs capacités et à leurs relations. Vous allez donc écrire beaucoup d'objets, de petites méthodes et votre programme fonctionnera comme par magie. Pour y parvenir, vous devez vous tordre la tête ...

Et c'est pourquoi la POO est difficile. Puisque tout est un objet, tout ce qu'ils font est de demander à d'autres objets de faire quelque chose, et ces autres objets en font essentiellement. Ainsi, le contrôle dans un programme POO peut basculer sauvagement entre les objets.


-1

En tant que personne qui apprend actuellement la programmation et qui a quelques problèmes dans ce domaine, je ne pense pas que ce soit tellement que le concept soit difficile à comprendre, de même que les implémentations spécifiques de ce concept. Je dis cela parce que je comprends l'idée de la programmation orientée objet et que je l'utilise en PHP depuis environ un an, mais lorsque je passe à C # et que je regarde l'utilisation des objets par d'autres programmeurs, je trouve que beaucoup de gens le font de manière différente. que je ne comprends tout simplement pas. C’est précisément ce qui m’a amené à mieux comprendre les principes de la programmation orientée objet.

Bien sûr, je réalise que le problème vient probablement de mon manque d'expérience avec un langage natif-OOP et que, avec le temps, je trouverai de nouvelles façons d'utiliser des objets qui seront aussi peu clairs pour un nouveau programmeur que ce que je suis. en train de vivre. Jerry Coffin en parle à quelques reprises, notamment dans son commentaire:

Cela devient particulièrement problématique lorsque d’un côté on vous dit que l’un des grands avantages de la POO est de modéliser plus fidèlement la réalité, mais vous commencez par prendre ce qui ressemble beaucoup à une vue inspirée par le LSD des parties les plus fondamentales et les plus évidentes de réalité.

Je trouve cela très précis, car c’est l’impression que j’ai souvent lorsque je vois des personnes créer des cours pour des choses qui ne sont pas vraiment des choses - un exemple spécifique m’échappe, mais le plus proche que je puisse trouver à la volée est de traiter la distance comme un objet (je vais éditer la prochaine fois que je vois quelque chose qui cause cette même confusion). Parfois, la programmation orientée objet semble ignorer temporairement ses propres règles et devient moins intuitive. Cela se produit le plus souvent lorsque des objets produisent des objets, héritent d'une classe qui les encapsule, et cetera.

Je pense que pour quelqu'un comme moi, il est utile de penser que le concept d'objets a plusieurs facettes, l'une d'entre elles consistant à traiter quelque chose comme un objet alors que ce ne serait pas le cas autrement. Quelque chose comme la distance, avec juste un petit changement de paradigme, pourrait sembler être un objet théorique, mais pas un objet qui pourrait être tenu entre vos mains. Je dois penser à cela comme à un ensemble de propriétés mais à un ensemble de comportements plus abstrait, tel que l'accès à ses propriétés. Je ne suis pas sûr que ce soit la clé de ma compréhension, mais cela semble être le but de mes études actuelles.


1
Une paire de points ou d'objets doit être considérée comme un objet. Et la distance doit être prise en fonction de l'objet. Utiliser des objets ne signifie pas que vous faites des objets à partir de tout.
Gangnus

Comme je l'ai dit, la distance était un mauvais exemple. En ce qui concerne la création d’un objet à partir de tout, je me réfère spécifiquement à ce que j’ai vu se dérouler, et non à ce que j’ai réellement fait - ce qui n’est rien pour le moment.
dsimer

Cela dépend de la langue - dans SmallTalk, la distance (et tout le reste) EST un objet. Mais en C #, vous avez mentionné que ce serait mauvais.
Gangnus

-2

Les terminologies ont été ma bosse sur la route lorsque j'ai appris les principes de la programmation orientée objet (POOP). C'est lorsque vous comprenez les principes fondamentaux que les éléments commencent à se mettre en place. Comme toutes les choses, apprendre de nouveaux concepts est un peu difficile.

Convenu que les modèles de conception devraient être conçus au moins parallèlement à la programmation orientée objet.


-2

Le principal obstacle pour moi était simplement de comprendre le concept abstrait de la programmation orientée objet. Maintenant, je suis très novice en programmation en général. Cela fait un an à un an et demi, et mon introduction à la programmation orientée objet a été initiée avec Actionscript and Processing. Lorsque j'ai appris le codage Actionscript pour la première fois, ce n'était pas dans la POO. J'ai appris à coder directement dans le panneau Actions et c'est ainsi que j'ai appris les bases de la programmation (variables, fonctions, boucles, etc.). J'ai donc appris que faire quelque chose directement sur la scène en Flash ou en traitement.

Lorsque la POO est entrée en jeu, il était un peu difficile pour moi de comprendre au début que je pouvais créer des méthodes et des propriétés dans un objet pour pouvoir les utiliser et les réutiliser. Tout était très abstrait et difficile à traiter, mais les langages de programmation eux-mêmes étaient bien meilleurs, mais il a fallu un acte de foi pour établir ces liens au début.


wow une partie de cela n'a aucun sens. « Tout était très abstrait et difficile à traiter entre les classes et instances d'objets , etc. Mais les langages de programmation est devenu beaucoup plus facile à comprendre une fois que je suis arrivé POO Mais ce peu a fait un bond de Faitl pour rendre ces connexions au premier. »

-2

Recette

Bonne compréhension de la POO = bon mentor ou bons livres ou les deux + intérêt personnel + pratique.

Intérêt personnel

De mon expérience personnelle, l'intérêt personnel est un long chemin à franchir pour passer de la programmation procédurale à la POO avec les bons apports de mentors ou de bons livres, ou les deux combinés .

Pratique, pratique et pratique

Mon meilleur ami pour mieux comprendre la POO n’a été que pratique. Cela favorisera certainement vos capacités de POO.

Comme dit le proverbe «Il n’ya pas de substitut au travail acharné ni de raccourci vers le succès».

Bonne chance!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.