•  22-10-2019
  •  | 
  •  

Question

Quand je commencé à utiliser un langage orienté objet (Java), je suis assez juste allé « Cool » et le codage commencé. Je ne l'ai jamais vraiment pensé jusqu'à ce que récemment après avoir lu beaucoup de questions sur la POO. L'impression générale que je reçois est que les gens luttent avec elle. Depuis que je ne l'ai pas pensé aussi dur, et je ne dirais pas que je suis tout génie, je pense que je dois avoir manqué quelque chose ou mal compris.

Pourquoi est-POO difficile à comprendre? , il est difficile de comprendre?

Était-ce utile?

La solution

Je trouve personnellement la mécanique de la POO assez facile à saisir. Le plus dur pour moi a été le « pourquoi » de celui-ci. Quand je suis d'abord exposé à lui, il semblait comme une solution à la recherche d'un problème. Voici quelques raisons pour lesquelles je pense que la plupart des gens trouvent qu'il est difficile:

  1. IMHO l'enseignement OO depuis le début est une très mauvaise idée. codage de procédure n'est pas une « mauvaise habitude » et est l'outil idéal pour certains emplois. Les méthodes individuelles dans un programme OO ont tendance à être assez procédural à la recherche de toute façon. En outre, assez bien avant d'apprendre la programmation procédurale pour ses limites pour devenir visible, OO ne semble pas très utile à l'étudiant.

  2. Avant de pouvoir vraiment saisir OO, vous devez connaître les bases de structures de données et la liaison tardive / fonctions d'ordre supérieur. Il est difficile de Grok polymorphisme (qui est essentiellement passe autour d'un pointeur vers des données et un tas de fonctions qui fonctionnent sur les données) si vous ne comprenez même pas les concepts de structuration des données au lieu d'utiliser les primitives et le passage autour des fonctions d'ordre supérieur / pointeurs vers des fonctions.

  3. modèles de conception doivent être enseignées comme quelque chose de fondamental à 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 concrets de relativement où OO peut simplifier les problèmes réels, et vous allez vouloir les apprendre par la suite de toute façon. De plus, une fois que vous avez vraiment OO, la plupart des modèles de conception deviennent évidents avec le recul.

Autres conseils

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

Tout d'abord, au moins dans « POO pur » (par exemple, Smalltalk) où tout est un objet, vous devez tordre votre esprit dans une configuration plutôt naturelle de penser à un certain nombre (pour un seul exemple) comme un objet intelligente au lieu d'une valeur - car en réalité, 21 (par exemple) vraiment juste une valeur. Cela devient particulièrement problématique quand d'une part on vous dit qu'un grand avantage de la POO est de modélisation en réalité de plus près, mais vous commencez en prenant ce qui ressemble beaucoup comme une vue inspiré LSD de même les parties les plus évidentes de base et de réalité.

En second lieu, l'héritage en POO ne suit pas les modèles mentaux de la plupart des gens de très près non plus. Pour la plupart des gens, classer les choses plus fait spécifiquement pas ont partout près des règles absolues nécessaires pour créer une hiérarchie de classes qui fonctionne. En particulier, la création d'un class D héritant d'un autre moyen de class B que les objets de la part de class D absolument, positivement tous les caractéristiques de class B. class D peut ajouter de nouvelles et différentes caractéristiques propres, mais tous les caractéristiques de class B doit rester intacte.

Par contre, quand les gens classifient les choses mentalement, ils suivent généralement un modèle beaucoup plus lâche de. Pour un exemple, si une personne fait des règles sur ce qui constitue une classe d'objets, il est assez typique que presque une règle peut être transgressée tant que suffisamment d'autres règles sont respectées. Même les quelques règles qui ne peuvent pas vraiment être cassé peut presque toujours être « tendu » un peu quand même.

Juste par exemple, considérer « voiture » en tant que classe. Il est assez facile de voir que les vaste majorité de ce que la plupart des gens pensent que « voitures » ont quatre roues. La plupart des gens, cependant, ont vu (au moins une image de) une voiture avec seulement trois roues. Certains d'entre nous de l'âge requis Rappelez-vous aussi une voiture de course ou deux des années 80 au début des (environ) qui avaient six roues - et ainsi de suite. Ce qui nous laisse avec trois choix:

  1. Ne rien affirmer sur le nombre de roues d'une voiture a -. Mais cela tend à conduire à l'hypothèse implicite que ce sera toujours 4, et le code qui est susceptible de briser pour un autre numéro
  2. Assertion que toutes les voitures ont quatre roues, et juste classer les autres comme « non voitures », même si nous savons qu'ils sont vraiment.
  3. Concevoir la classe pour permettre la variation du nombre de roues, juste au cas où, même si il y a une bonne chance cette capacité ne sera jamais nécessaire, utilisé ou testé correctement.

Enseigner POO se concentre souvent sur la construction d'énormes taxonomies - par exemple, des morceaux et des morceaux de ce qui serait une hiérarchie géante de toute vie connue sur la terre, ou quelque chose sur cet ordre. Cela pose deux problèmes: d'abord et avant tout, il a tendance à conduire de nombreuses personnes vers se concentrer sur d'énormes quantités d'informations qui est tout à fait hors de propos à la question à portée de main. À un moment donné, j'ai vu une discussion assez longue de la façon de modéliser les races de chiens, et si (par exemple) « caniche miniature » devrait hériter de « poodle pleine grandeur », ou vice versa, ou s'il devrait y avoir une base abstraite « caniche "classe, avec « les deux héritant de poodle grandeur nature » et « caniche miniature » il. Ce qu'ils semblaient tous ignorer était que l'application était censé traiter le suivi des licences pour les chiens, et dans le but à la main, il était tout à fait suffisant pour avoir un seul champ nommé « race » (ou quelque chose sur cet ordre) sans modélisation de la relation entre les races du tout.

En second lieu, et presque surtout, elle conduit à se concentrer sur les caractéristiques des articles, au lieu de se concentrer sur les caractéristiques qui sont 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 building le modèle le plus simple qui comblera nos besoins, et d'utiliser l'abstraction pour adapter les nécessaires sous-classes pour adapter l'abstraction que nous avons construit.

Enfin, je vais dire encore une fois: nous sommes lentement suivant le même chemin emprunté par les bases de données au cours des années. bases de données premières ont suivi le modèle hiérarchique. Autre que de se concentrer exclusivement sur les données, c'est l'héritage unique. Pendant une courte période, quelques bases de données ont suivi le modèle de réseau - essentiellement identique à l'héritage multiple (et vu sous cet angle, plusieurs interfaces ne sont pas assez différentes de plusieurs classes de base à l'avis préoccupais)

.

Il y a longtemps, cependant, les bases de données largement convergé sur le modèle relationnel (et même si elles ne sont pas SQL, à ce niveau d'abstraction des bases de données « NoSQL » actuelles sont trop relationnelle). Les avantages du modèle relationnel sont suffisamment bien connus que je ne vais pas les répéter ici. Je vais simplement remarquer que l'analogue le plus proche du modèle relationnel que nous avons dans la programmation générique est la programmation (et désolé, mais malgré le nom, Java génériques, par exemple, ne sont pas admissibles vraiment, mais ils sont un petit pas dans la direction à droite).

POO exige la capacité de penser abstraitement; un don / malédiction que peu de gens, même les programmeurs professionnels, ont vraiment.

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 se habituer à la cartographie de « gauche » comme 270, et oui, en disant « Car.Turn » au lieu de « tourner la voiture » est pas un énorme bond. Mais, pour bien traiter avec ces objets et de les créer, vous devez inverser la façon dont vous pensez normalement.

Au lieu de manipuler un objet, nous racontons l'objet de réellement faire les choses lui-même. Il ne peut pas se sentir plus difficile, mais dire une fenêtre pour lui-même semble ouvrir étrange. Les gens inutilisés à cette façon de penser doivent lutter avec cette bizarrerie encore et jusqu'à ce que finalement il devient en quelque sorte naturel.

Tout paradigme nécessite une certaine pression « sur le bord » à saisir, pour la plupart des gens. Par définition, il est un nouveau mode de pensée et donc il faut une certaine quantité de lâcher prise des notions anciennes et une certaine quantité de saisir pleinement pourquoi les nouvelles notions sont utiles.

Je pense que beaucoup du problème est que les méthodes utilisées pour enseigner la programmation informatique sont assez pauvres en général. OOP est si courante maintenant que ce n'est pas aussi perceptible, mais vous voyez encore souvent dans la programmation fonctionnelle:

  • concepts importants sont cachés derrière des noms bizarres (FP: Qu'est-ce qu'un monade POO: Pourquoi ils les appellent parfois des fonctions et des méthodes autres fois)

  • concepts étranges sont expliqués dans la métaphore au lieu en termes de ce qu'ils font, ou pourquoi vous souhaitez les utiliser, ou pourquoi quelqu'un n'a jamais pensé à les utiliser (FP: Une monade est une combinaison spatiale, il TERMINE un code POO. un objet est comme un canard, il peut faire du bruit, promenade et hérite de l'animal)

  • les bonnes choses varie d'une personne à l'autre, il est donc pas tout à fait clairement ce qui sera le point de basculement pour tout étudiant, et souvent l'enseignant ne peut même pas se souvenir. (FP: Oh, monades vous laisse cacher quelque chose dans le genre lui-même et le transporter sans avoir à écrire explicitement ce qui se passe chaque fois POO. Oh, les objets que vous permettent de garder les fonctions pour un type de données avec ces données.)

Le pire est que, comme la question indique, certaines personnes se cassera immédiatement à comprendre pourquoi le concept est bon, et d'autres non. Cela dépend vraiment de ce que le point de basculement est. Pour moi, saisir que les objets stocker des données et des méthodes pour ces données était la clé, après que tout le reste correspond tout simplement comme une extension naturelle. Ensuite, je saute plus tard eu comme se rendant compte qu'un appel de méthode d'un objet est très similaire à faire un appel statique que cet objet comme premier paramètre.

Le petit saute plus tard aider à affiner la compréhension, mais il est une première qui prend une personne de « POO n'a pas de sens, pourquoi les gens font ça? » à « OOP est le meilleur, pourquoi les gens faire quoi que ce soit d'autre? »

Parce que l'explication de base de la POO a très, très peu à voir avec la façon dont il est utilisé dans le domaine. La plupart des programmes pour enseigner essayer d'utiliser un modèle physique, tels que « penser à une voiture comme un objet, et les roues comme des objets, et les portes, et la transmission ... », mais en dehors de certains cas obscurs de la programmation de simulation, les objets sont beaucoup plus souvent utilisés pour représenter des concepts non-physiques ou d'introduire indirection. L'effet est que cela rend les gens comprennent intuitivement dans le mauvais sens.

L'enseignement de modèles de conception est une bien meilleure façon de décrire POO, car il montre comment les programmeurs des problèmes de modélisation réels peuvent être efficacement attaqués avec des objets, plutôt que de décrire dans l'abstrait.

Je suis en désaccord avec la réponse de dsimcha pour la plupart:

  1. L'enseignement OO depuis le début n'est pas vraiment une mauvaise idée en elle-même, ni est l'enseignement des langues de procédure. Ce qui est important est que nous enseignons aux gens d'écrire claire, concise, le code cohérent, quel que soit OO ou de procédure.

  2. Les méthodes individuelles dans de bons programmes OO ne tendent pas à être procédurale regardant tout. Cela devient de plus en plus vrai avec l'évolution des langages OO (lire C # parce autre que C ++ qui est le seul autre langage OO Je sais) et leur syntaxe qui devient plus complexe par le jour (lambdas, LINQ à des objets, etc.). La seule similitude entre les méthodes et les procédures OO dans les langues de procédure est la nature linéaire de chacun, ce dont je doute changerait de sitôt.

  3. Vous ne pouvez pas maîtriser un langage procédural sans structures de compréhension des données non plus. Le concept de pointeur est aussi important pour les langues de procédure que pour les langues OO. Le passage de paramètres par référence, par exemple, ce qui est assez fréquent dans les langues de procédure, vous oblige à comprendre des pointeurs autant qu'il est nécessaire d'apprendre une langue OO.

  4. Je ne pense pas que les modèles de conception devraient être enseignées au début de la programmation orientée objet du tout, parce qu'ils ne sont pas fondamentales à la programmation OO du tout. On peut sans aucun doute être un bon programmeur OO sans savoir quoi que ce soit au sujet des modèles de conception. En fait, une personne peut-être même de modèles de conception bien connus sans même savoir qu'ils sont documentés en tant que tel avec les noms propres et que les livres sont écrits à leur sujet. Ce qui devrait être enseigné est fondamentalement les principes de conception tels que la responsabilité unique, ouvrir la liste fermer et Ségrégation Interface. Malheureusement, beaucoup de gens qui se considèrent Oo programmeurs ces jours-ci soit ne sont pas familiers avec ce concept fondamental ou tout simplement choisir de l'ignorer et c'est pourquoi nous avons tant de code OO des ordures là-bas. Seulement après une compréhension approfondie de ces et d'autres principes devraient concevoir des modèles introduits.

Pour répondre à la question de l'affiche originale, oui, OO est un concept plus difficile à comprendre que la programmation procédurale. En effet, nous ne pensons pas en termes de propriétés et méthodes des objets de la vie réelle. Par exemple, le cerveau humain ne pense pas facilement de « Activ » comme méthode de la télévision, mais il voit en fonction de rotation humaine sur le téléviseur. De même, le polymorphisme est un concept étranger à un cerveau humain qui voit généralement chaque objet réel de la vie par un seul « visage ». L'héritage est à nouveau pas naturel de notre cerveau. Tout simplement parce que je suis un développeur ne veut pas dire que mon fils serait un. D'une manière générale, les besoins du cerveau humain à être formés pour apprendre OO tandis que les langues de procédure sont plus naturelles à elle.

Je pense que beaucoup de programmeurs ont de la difficulté à la conception et à la planification dès le départ pour commencer. Même si quelqu'un fait tout le design pour vous, il est encore possible de rompre avec des principes de la POO. Si je prends un tas de code spaghetti et le jeter dans une classe, est-ce vraiment POO? Quelqu'un qui ne comprend pas la POO peut encore programmer en Java. En outre, ne confondez pas la difficulté à comprendre avec pas disposé à suivre un certain Méthodologies ou en désaccord avec elle.

Vous devriez lire Objects jamais? Eh bien, presque jamais. (membres de l'ACM requis) par Mordechai Ben-Ari qui suggère que la POO est si difficile, parce que ce n'est pas un paradigme qui est en fait naturel pour quoi que ce soit la modélisation. (Bien que j'ai des réserves au sujet de l'article, car il ne sait pas quels sont les critères qu'il ressent un besoin de programme pour satisfaire à dire qu'il est écrit sur le paradigme de la POO par opposition à un paradigme procédural en utilisant un langage OO.)

Programmation orientée objet en lui-même est pas difficile.

Le plus dur vient à le faire bien. Où mettre la coupure entre le code de sorte que vous pouvez facilement déplacer les choses à l'objet de base commune, et de les étendre plus tard? Comment rendre votre code utilisable par d'autres (étendre les classes, les envelopper dans des procurations, la méthode de remplacement) sans sauter à travers des cerceaux pour le faire.

C'est la partie difficile, et si le droit peut être très fini élégant, et si mal fait peut être très maladroit. Mon expérience personnelle est que cela demande beaucoup de pratique pour avoir été dans toutes les situations où vous SOUHAITERAIS que vous l'avez fait différemment, afin de le faire assez bien ce temps.

Je regardais juste une vidéo de Richard Feynman discuter comment les gens peuvent effectivement avoir des méthodes complètement différentes en cours dans leur tête quand on pense -. Je veux dire complètement différent

Quand je fais la conception de haut niveau, j'arrive de visualiser des objets, je peux les voir, voir leurs interfaces et voir ce que pathways besoins d'information à parcourir.

J'ai aussi des problèmes de détails et Remembering trouvé OO être une grande aide organisationnelle - beaucoup plus facile de trouver la fonctionnalité que la numérisation à travers une liste sans organisation rigide de sous-routines

.

Pour moi, OO était un grand avantage, mais si vous ne visualisez pas la même façon ou ne font pas l'architecture de haut niveau, il est probablement inutile et ennuyeux.

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

Aucune idée si c'est ce qui arrive aux autres, mais pour moi ce fut comme ceci: mon processus de pensée sur la programmation était purement procédurale. Comme dans: « tel ou tel se produit, tel ou tel qui se passe à côté », etc. Je ne ai jamais considéré les variables et les données à quelque chose de plus que les acteurs éphémères dans le déroulement du programme. La programmation a été "le flux des actions".

Je suppose que ce qui n'a pas été facile à saisir (aussi stupide que qui ressemble à moi maintenant), l'idée était que les données / variables en fait importent vraiment , dans un sens plus profond que d'être éphémère acteurs dans le programme « flux ». Ou de mettre cette autre façon: je continué à essayer de le comprendre par ce que arrive , plutôt que par ce que , qui est la véritable clé de la saisir

.

Je ne pense pas qu'il est difficile à comprendre, mais il se peut que beaucoup de programmeurs sont nouveaux à l'interrogation du concept, en provenance de langues de procédure.

D'après ce que j'ai vu / lu beaucoup de gens (dans les forums au moins) un regard pour « résultat » de la POO. Si vous êtes un programmeur qui ne procédure va pas en arrière et modifier leur code prolonger, il peut probablement être difficile de comprendre les avantages.

En outre, il y a beaucoup de mauvais POO là-bas, si les gens lisent / voyant alors il est facile de voir pourquoi ils pourraient éprouver des difficultés.

OMI vous devez attendre jusqu'à ce qu'il soit clics »ou être enseignés par une personne ayant une connaissance réelle, je ne pense pas que vous pouvez vous précipiter.

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

langages informatiques d'aujourd'hui sont une abstraction de ce qui se passe dans l'ordinateur.

POO est une façon abstraite pour représenter des abstractions.

Nous utilisons donc une abstraction pour construire des abstractions avec une abstraction. Ajoutez à cela que ce que nous sont généralement rendus analytiques des interactions physiques / sociaux très complexes et, bien, pas étonnant.

J'ai fait un blog appelé « Luttes dans la programmation orientée objet, » qui est né d'une partie de mes luttes avec l'apprendre. Je pense qu'il a été particulièrement difficile pour moi de comprendre parce que je passé tellement de temps à la programmation procédurale, et j'ai eu un moment difficile obtenir ma tête autour de l'idée qu'un objet pourrait être représenté par un ensemble d'attributs et de comportements (j'étais habitué simplement une collection de variables et méthodes).

En outre, il y a beaucoup de concepts qui font un objet de langage orienté - héritage, interfaces, polymorphisme, composition, etc. Il y a vraiment beaucoup de choses à apprendre sur la théorie avant de pouvoir le code réellement écrire efficacement, et dans un manière orientée objet, alors que la programmation procédurale, il est tout simplement une question de compréhension 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 vous ne voyez pas pourquoi, et aussi quand vous ne pouvez pas regarder ce que vous avez fait et figure si vous l'avez fait droit ou non.

Ce qui est nécessaire est de petits projets qui utilisent OO pour faire des choses utiles. Je vous suggère de regarder à travers un livre sur les modèles de conception et de trouver celui qui est évidemment utile et fonctionne bien avec OO. (Je stratégie une fois que je l'ai essayé. Quelque chose comme Singleton ou Flyweight serait mauvais choix, car ils sont des façons d'utiliser des objets en général, ne pas utiliser des objets pour accomplir quelque chose.)

Je pense que cela dépend de l'âge (âge comme approximation de l'expérience) et, plus important encore, l'intérêt. Si vous êtes « jeune » (à savoir, vert, peut-être) et vous ne l'avez jamais pensé autrement, il semble assez simple. D'autre part, si vous pensez que c'est la chose la plus cool que vous avez jamais vu - est arrivé à moi à l'âge de 28 ou quelque chose - il est facile de grok.

D'autre part, si vous pensez, comme beaucoup de mes étudiants Java a fait, « pourquoi nous apprenons cela, il est juste un effet de mode », il est pratiquement impossible d'apprendre. Cela est vrai pour la plupart des technologies.

Quel que paradigme (POO, fonctionnelle, etc.) que vous choisissez, afin d'écrire un programme informatique, vous devez savoir quelles mesures votre programme fera.

La façon naturelle de définir un processus est en train d'écrire ses étapes, pour des tâches plus importantes que vous cassez la tâche en petites étapes. C'est la voie procédurale, voici comment l'ordinateur fonctionne, voici comment vous passez par votre étape de check-list par étape.

POO est une autre façon de penser. Au lieu de penser à une liste de tâches qui doit être fait par étape étape, vous pensez des objets, leurs capacités et leurs relations. Donc, vous allez écrire beaucoup d'objets, de petites méthodes et votre programme magie fonctionne. Pour ce faire, vous devez tordre votre esprit ...

Et voilà pourquoi OOP est difficile. Puisque tout est un objet, tout ce qu'ils ne demande d'autres objets à faire quelque chose, et les autres objets font essentiellement les quelques-uns. Ainsi, le contrôle dans un programme POO peut sauter d'une manière extravagante et-vient entre les objets.

Comme quelqu'un qui est actuellement la programmation et l'apprentissage ayant des problèmes dans ce domaine, je ne pense pas que ce soit tellement que le concept est difficile à comprendre que les implémentations spécifiques dudit concept. Je dis cela parce que je reçois l'idée de la POO, et je l'ai utilisé en PHP pendant environ un an, mais je passe à C # et de regarder l'utilisation d'autres programmeurs d'objets, je trouve que beaucoup de gens le font de manière que je ne comprends pas. Il est en particulier ce qui m'a conduit sur la voie de la recherche d'une meilleure compréhension des principes de la POO.

Bien sûr, je me rends compte que la question est très probablement mon manque d'expérience avec un langage natif-POO, et que le temps passe, je vais trouver de nouvelles façons d'utiliser les objets qui seront tout aussi clair à un nouveau programmeur comme ce que je vis actuellement. Coffin Jerry touche à cette opération plusieurs fois, en particulier dans son commentaire:

Cela devient particulièrement problématique lorsque d'une part vous dit que un gros avantage de la POO est la modélisation réalité de plus près, mais vous commencez au large en prenant ce qui ressemble beaucoup comme une vue inspiré LSD de même les parties les plus évidentes de base et de la réalité.

Je trouve cela d'être très précis, car il est l'impression que je reçois souvent en voyant quelqu'un créer des classes pour des choses qui ne sont pas vraiment les choses - un exemple spécifique me échappe, mais le plus proche, je peux venir avec à la volée est le traitement de la distance comme un objet (je modifier la prochaine fois que je vois quelque chose qui provoque cette même confusion). Parfois, POO semble ne pas tenir compte temporairement ses propres règles et devient moins intuitive. Ce plus souvent se produit pas lorsque des objets produisent des objets, hériter d'une classe qui les encapsulant, et ainsi de suite.

Je pense que pour quelqu'un comme moi, il aide à penser le concept d'objets comme ayant de multiples facettes, dont une comprend le traitement quelque chose comme un objet quand il ne serait pas autrement. Quelque chose comme la distance, avec juste un petit changement de paradigme, pourrait apparaître comme un objet théorique, mais qui ne pourrait se tenir dans la main. Je dois penser comme ayant un ensemble de propriétés, mais un ensemble plus abstraite des comportements, tels que l'accès à ses propriétés. Je ne suis pas positif que c'est la clé de ma compréhension, mais il semble être là où mes études actuelles conduisent.

terminologies étaient ma bosse sur la route lors de l'apprentissage des principes de la programmation orientée objet (MERDE). Il est quand vous obtenez une bonne connaissance des principes fondamentaux que les pièces commencent à tomber en place. Tout comme tout apprentissage de nouveaux concepts sont un peu dur.

convenu que les modèles de conception doivent être tought au moins parallèle à la POO.

Le principal saut pour moi était juste de comprendre le concept abstrait de la POO. Maintenant, je suis très nouveau à la programmation en général, j'ai été la programmation d'un an à un an et demi donc mon introduction dans POO était avec Actionscript et traitement. Quand j'ai appris le codage Actionscript, il n'a pas été en POO. J'ai appris à coder directement dans le panneau Actions et comment j'appris les principes de base de la programmation (variables, fonctions, boucles, etc.). Donc, je l'ai appris que faire quelque chose directement à la scène dans Flash ou traitement.

Quand OOP est venu dans les choses, se rendant compte que je pouvais créer des méthodes et des propriétés dans un objet pour pouvoir utiliser et de réutiliser moi était un peu difficile pour saisir au premier abord. Tout était très abstrait et difficile à traiter, mais les langages de programmation eux-mêmes beaucoup mieux, mais ce genre de a fait un bond de foi pour faire ces connexions au premier abord.

Recette

Bonne compréhension OOP = bon mentor ou Good Books Ou deux + Intérêt personnel + pratique.

Intérêt personnel

De mon expérience personnelle, l'intérêt personnels est un long chemin à traverser le pont de la programmation procédurale OOP avec les bonnes entrées de mentors ou de bons livres ou les deux combinés .

Pratique, pratique et pratique

Mon meilleur ami pour obtenir une meilleure compréhension de la POO n'a été que pratique. Cela favorisera certainement vos capacités POO.

Comme le dit le dicton « Il n'y a pas de substitut à travailler dur et pas de raccourci vers le succès. »

Bonne chance!

Licencié sous: CC-BY-SA avec attribution
scroll top