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

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?

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.

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).

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.

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.

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?"

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.

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.

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.

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.)

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.

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.

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 .

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.

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.

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.

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.)

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.

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.

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.

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.

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.

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!