Comment expliquer OOP concepts à une personne non technique?
J'essaie souvent d'éviter de dire aux gens que je suis programmeur parce que la plupart du temps je finis par leur expliquer ce que cela signifie vraiment. Quand je leur dis que je programme en Java ils posent souvent des questions générales sur le langage et comment il diffère de x et y. Je ne suis pas non plus bon pour expliquer les choses parce que 1) je ne 'ai pas beaucoup d'expérience dans le domaine et 2) Je déteste vraiment expliquer les choses aux personnes non techniques.
Ils disent que vous comprenez vraiment les choses une fois que vous les expliquez à quelqu'un d'autre, dans ce cas, comment expliqueriez-vous OOP terminologie et concepts à une personne non technique?
J'essaie généralement de décrire la programmation orientée objet en utilisant des exemples du monde réel.
Par exemple, je pourrais dire qu'une classe appelée Vehicle décrit les choses minimales qu'un véhicule est. Je vais demander à la personne de me dire ce qu’elle pense qu’un véhicule est. Parfois, ils disent des choses comme "Eh bien, comme une voiture ou un camion", et je hoche la tête et je suis d'accord avec eux. Je demanderai ensuite quelles sont les différences entre une voiture et un camion. Parfois, ils mentionnent la taille, parfois le but et d'autres choses.
Ensuite, je leur demanderai d'oublier une voiture ou un camion et je leur demanderai simplement de continuer à décrire un véhicule:
"Oh, ça bouge"
"Il a un opérateur ou un chauffeur"
etc...
Bientôt, nous savons ce qu'est un véhicule et j'ai dit qu'en OOP nous définirions un véhicule, et pour les besoins de l'argument dire qu'il peut se déplacer et lui donner une sorte de conducteur. Ensuite, je vais demander, ok, alors qu'est-ce qu'une voiture a?
"Des portes"
"Les fenêtres"
Et puis un camion ....
"Portes" "fenêtres" "Plus de roues!"
Bientôt, après beaucoup de discussions, l'autre personne a généralement identifié:
1) Ce qui constitue un véhicule
2) Qu'est-ce qui constitue une voiture
3) Ce qui constitue un camion
4) Ce qui constitue un avion.
Le tout sans aucun détail technique. Nous avons divisé les propriétés de chacun dans les bonnes zones. Ils comprennent l'héritage ("Ouais, une voiture est un véhicule, un camion est un véhicule, mais une voiture n'est pas un camion, c'est SIMPLE, duh!").
Ils comprennent même le polymorphisme, "Bien sûr, ils font essentiellement la même chose, mais cela pourrait le faire légèrement différemment.". Nous pouvons parler de comportement et où cela devrait vivre dans notre arbre d'objets.
Selon leur formation et leurs antécédents, certains l'obtiennent plus rapidement que d'autres. Mais quand je compare OOP à des objets réels, la plupart des gens l'obtiennent toujours. En fait, j'ai trouvé dans des conversations avec des gens non techniques des choses auxquelles je n'avais jamais pensé. Les véhicules ne le font pas doivent être habités, par exemple (drones), mais un programmeur aurait-il pensé à l'opérateur du véhicule comme une propriété de celui-ci? Je ne dis pas qu'il est bon ou mauvais d'avoir un opérateur mentionné, mais cela nous fait penser sur ce que nous modélisons et ce que nous essayons de réaliser lorsque nous développons des logiciels.
Maintenant, la spécialisation partielle des modèles, d'autre part .... :)
Les objets sont des noms, les méthodes sont des verbes.
Voici une version de ma réponse en conserve que je donne à la personne ultra non technique:
La programmation est une tentative de créer une représentation de la réalité sur l'ordinateur. Il existe déjà de nombreux outils et appareils qui le font déjà - pensez à la façon dont une feuille de calcul nous permet de représenter plus facilement la comptabilité ou les statistiques, ou comment une présentation PowerPoint nous permet de stocker et d'afficher nos présentations.
Parfois, nous devons intégrer des représentations personnalisées de la réalité dans des applications nouvelles ou existantes qui reflètent nos processus métier. Il existe de nombreuses façons de programmer, et l'une des façons les plus courantes de programmer est la programmation orientée objet, où le code que nous construisons est spécifiquement conçu pour reproduire les concepts de la réalité. Les "choses" ont en réalité des attributs et des comportements. Par exemple, un être humain a souvent les bras et les jambes, la couleur des cheveux, l'origine ethnique et peut souvent parler et marcher.
Parler et marcher peut prendre différentes formes, telles que la langue que l'on parle ou la vitesse ou la manière dont on marche.
Les êtres humains ont souvent des interactions avec d'autres types de "choses", qu'il s'agisse d'animaux, d'autres humains, d'autres organismes vivants ou d'objets inanimés. Il existe en réalité des thèmes qui ont souvent besoin d'un moyen d'être représentés, comme les interactions entre les "choses", la catégorisation des choses, etc. Il existe une "logique métier" très compliquée qui doit être représentée dans le logiciel que notre organisation utilise.
La programmation orientée objet fournit un moyen de représenter avec précision ces "concepts du monde réel" et "logique métier".
-> Cette déclaration est généralement suffisante pour conjurer leur curiosité (ou peut-être les ennuyer aux larmes), mais s'ils ont plus de questions, la déclaration ci-dessus (je crois) jette des bases décentes pour la conversation. Je ne pense pas vraiment que la personne non technique s'intéresse trop à la terminologie technique telle que "Abstraction", "Composition", "Polymorphisme", etc., mais si c'est le cas, le langage que j'ai utilisé dans la déclaration en conserve me permet pour tirer des exemples basés sur elle.
J'ai toujours appris OOP comme ceci:
Vous avez une horloge, et elle indique l'heure - eh bien, dans la programmation, vous mettez tout le code et tout ce que vous devez faire tous ensemble (cela semble assez évident, mais les gens ne le faisaient pas auparavant au début). Quoi qu'il en soit, cela s'appelle encapsulation.
Maintenant que vous avez une horloge, vous voudrez peut-être un réveil - eh bien, une fois que vous avez tout rassemblé, vous pouvez y ajouter des choses pour le faire plus - comme régler l'alarme et la faire sonner. Cela s'appelle héritage.
En outre, vous regardez l'horloge que j'ai sur mon poignet, mais vous pouvez d'autres horloges qui ressemblent à une horloge grand-père ou une horloge numérique. Cela semble différent, mais c'est toujours une horloge - enfin, cela s'appelle polymorphisme.
Et là, vous avez les 3 coins de la programmation orientée objet. Tout le reste n'est que du codage.
J'ai parlé d'une conversation que j'ai eue avec ma femme à ce sujet, dans cette réponse ici: https://softwareengineering.stackexchange.com/questions/45464/how-to-convince-non-programmer-his- les notions-sur-les-ordinateurs-sont-fausses/45467 # 45467
EDIT: La question à laquelle j'ai répondu a été modérée, donc je vais reprendre ma réponse ici.
Assise dans un restaurant avec ma femme, elle m'a demandé "Que signifie Orienté Objet?"
J'ai commencé à parler de la réutilisation et de l'encapsulation du code et du polymorphisme, et à un moment donné, j'ai réalisé que ses yeux étaient finement vitrés.
J'ai donc sorti un paquet Splenda du conteneur. J'ai dit: "Voici un objet. Quelles sont ses propriétés?"
Elle a dit: "C'est rectangulaire, il est fait de papier, il contient des splenda, il est bleu, il y a une impression dessus."
J'ai ramassé un paquet de sucre. "Qu'est-ce qu'il a en commun avec celui-ci?"
Elle a dit: "La rectangulaire, le papier, qu'il y a de l'impression."
J'ai dit: "Qu'en est-il qu'ils contiennent tous les deux quelque chose de sucré?"
Elle a dit: "Bien sûr."
J'ai dit: "Donc, ce sont les deux exemples de ce que nous pourrions appeler un paquet édulcorant abstrait. Un paquet édulcorant platonique idéal, si vous le souhaitez."
Elle a dit: "Bien sûr."
J'ai dit: "Et chacun a des propriétés héritées du paquet abstrait, puis des variations sur celui qui sont spécifiques à son type de chose."
Elle a dit: "D'accord. Oh! Et si je voulais faire, comme, un paquet de Saccharine, je prendrais le générique, et définirais les détails à ce sujet pour la Saccharine, et alors j'aurais ça!"
J'ai dit: "Bingo: programmation orientée objet".
Vous et moi savons qu'elle vient de se familiariser avec le modèle de conception Factory. Peu importe. Il illustre l'héritage, l'encapsulation, l'identité de classe d'objet ... Du bon.
Je leur dirais simplement de s'inscrire à un cours en OOP s'ils veulent vraiment le comprendre.
Je veux dire, toutes ces analogies comme Car.startEngine (); sommes, avouons-le - pur rap. Quand j'ai commencé pour la première fois OOP il y a de nombreuses années, je les ai trouvées pour ne faire qu'abstraire le domaine encore plus loin.
Au lieu d'expliquer simplement que OOP concerne la gestion de la complexité des langages procéduraux, près de 80% des auteurs de livres de programmation supposent que les programmeurs sont des idiots désemparés qui doivent être parlés en simple (voir l'ironie ici?) termes.
Oui, il est parfaitement normal d'expliquer les listes et les vecteurs, car c'est ce avec quoi nous travaillons principalement, pas Car.Engine et PoliceMan.Arrest (sauf si vous êtes un développeur de jeu, mais encore une fois, vous devez toujours avoir eu votre part du ancien).
Revenons au sujet, je leur dirais simplement que je crée des objets intangibles qui existent uniquement dans l'esprit du programmeur, à des fins de traitement de la paie/de jeu/de navigation par navette spatiale, etc.
S'ils ont encore des questions, arrêtez de discuter, car cela n'en vaut pas la peine. La plupart des gens ne parviennent pas à imaginer des notions abstraites et ont besoin d'exemples pour à peu près tout (ce qui signifie vraiment plus de simplification/spécialisation du sujet réel).
Cette question semble pouvoir être close, néanmoins ...
Comme la plupart des choses, OOP est en fait très simple à expliquer au niveau conceptuel. Les programmeurs modélisent les objets; et:
- les objets ont un état (champs/membres de données)
- les objets ont des actions (méthodes/fonctions)
- les objets s'appuient les uns sur les autres (héritage)
Ce sont des centaines de détails plus fins, bien sûr. Mais si vous essayez simplement de donner à quelqu'un un aperçu de 10 secondes, je pense que c'est un bon début. Y a-t-il des concepts spécifiques que vous avez du mal à expliquer?
L'exemple du téléphone mobile:
Imaginez que vous êtes propriétaire d'une usine, vous voulez décrire un téléphone générique
- Étape 1: Énumérez les propriétés génériques de ces téléphones , par exemple: hauteur, poids, couleur, etc.
- Étape 2: Liste de ces fonctions génériques de téléphones par exemple: passer un appel, recevoir un appel, envoyer des sms, etc.
Maintenant que vous avez votre "plan directeur" générique, créez-moi les téléphones suivants:
Téléphone 1:
Hauteur-> 102mm
Poids-> 85g
Couleur-> Rose
Téléphone 2:
Hauteur-> 125 mm
Poids-> 96g
Couleur-> Rouge
J'aime l'exemple de la voiture pour expliquer l'héritage (j'ai tendance à utiliser des animaux plutôt que des véhicules mais c'est la même idée) mais pour expliquer comment fonctionne un programme orienté objet, je me réfère à une analogie que j'ai lue une fois sur le site Web de Chris Crawford: le programme est comme une bureaucratie vraiment efficace. Tous les différents objets du programme sont comme les différents départements d'une bureaucratie; chaque département a ses propres tâches désignées, ils ont des entrées bien définies (à qui parler et quels formulaires remplir,) et d'autres départements ne savent souvent pas grand-chose de ce qui se passe à l'intérieur. Les RH sont comme une usine abstraite, l'informatique est un singleton, etc.
Obtenir un message d'erreur parce que vous avez tapé la mauvaise chose dans un programme informatique, c'est exactement comme remplir le mauvais formulaire à soumettre à un bureau.
La POO est une simplification grossière si quelque chose - une abstraction - du processus de pensée humaine et de la compréhension du monde pour projeter la fonctionnalité dans un "vide" numérique pour imiter numériquement les processus familiers et les classifications. À bien des égards, il s'agit davantage de notre état de langage primitif que de "penser plus comme des ordinateurs".
Si la programmation imitait la réalité ou la pensée humaine, elle serait bien plus organique, chaotique et aléatoire - même latérale. Au lieu de cela, nous simplifions la réalité en petits pas, "logique 2 + 2", catégories brutes, petits outils réutilisables et raisonnement préhistorique.
Nous essayons toujours de trouver comment télécharger nos pensées et nos désirs dans un protocole et un langage commun et pour ma part, les historiens seront fascinés par sa grossièreté sophistiquée un jour - comme nous voyons maintenant les hiéroglyphes. Ce n'est pas du tout "intelligent" - cela met simplement en évidence comment nous ne pouvons pas facilement expliquer comment nous décidons ou comprenons même les choses les plus simples. L'informatique est toujours au niveau "un chien est un chien parce que ce n'est pas un chat" de l'évolution de la pensée - c'est des millénaires derrière même le langage parlé de base.
Il existe deux types d'assistants. Il y a le gars qui fait bouger des choses spécifiques avec des mots magiques. Il a un mot pour invoquer le feu. Il a un mot pour faire apparaître un poulet congelé de nulle part. Et un autre mot pour créer un pot de force (je préfère ma force verte, brillante et translucide) pleine de bonté fraternelle. Avec la bonne application de ses mots, il peut produire un poulet frit.
Et puis il y a le OOP magicien. Qui invoque juste un lutin qui sait comment aller à l'épicerie, acheter un poulet (ou des ingrédients pour tout autre aliment que vous voulez qu'il prépare), le faire cuire, et vous servir le dîner. OOP Wizard n'a pas besoin de dire à son lutin comment le faire. Il a juste besoin de lui faire savoir ce qu'il veut lequel dans ce cas est du poulet frit. Non seulement cela, le OOP magicien peut invoquer d'autres serviteurs pour dire à son imp-chef quoi faire.
Donc, le gars de l'incantation impressionne lors des fêtes, mais l'assistant OOP est celui que vous voulez lorsque vous allez démarrer un restaurant magique avec un tas de personnages (comme, par exemple, un serveur Unicorn en colère) , et un troll floor manager) qui doivent tous travailler ensemble. Si vous essayez d'invoquer chaque étape du problème de la résolution de "restaurant", vous pouvez facilement vous emmêler dans les détails et il est très facile de faire des erreurs. Le OOP magicien pré-entraîne ses serviteurs à trier les détails pour lui afin qu'il puisse se concentrer sur la résolution du problème le plus important en faisant interagir son peuple.
Sans oublier qu'il est plus facile de réutiliser votre chef-lutin pour votre problème de cafétéria d'école primaire, c'est de séparer toutes les ordures que vous pourriez ou non réutiliser lorsque vous le faites une étape à la fois en appelant des mots et les mots qui appellent d'autres ensembles de mots (qui deviendront de plus en plus nombreux car vous devrez gérer une plus grande variété de problèmes).
Pour être honnête, avec une application très, très prudente, l'assistant d'incantation peut tout faire aussi vite que l'assistant OOP. Il peut décomposer les choses de la bonne manière, de sorte que l'appel des bons sorts ne nécessite pas plus de travail de sa part que l'assistant OOP. Mais le travail est beaucoup plus difficile à comprendre ou à dupliquer et beaucoup plus difficile à réutiliser de grandes parties car il est tout lié pour un complexe spécifique problème.
Je pense que la meilleure façon d'expliquer à un type non technique à propos de OOP est de les relier à eux.
Essentiellement OOD & OOP veulent que vous pensiez au système que vous concevez et implémentez comme un monde d'interaction.
Permet donc, par souci d'argument (qui ne se passe jamais bien sur Internet), de dire que vous expliquez à OOD & P à un collecteur d'ordures. Son nom est Bob. Vous aviez l'habitude d'aller à l'école avec lui il y a 15 ans, vous l'avez rencontré dans un bar et vous feignez tous les deux de vous intéresser à la vie de l'autre.
"Alors, John, tu dis que tu es un programmeur. Mon neveu est dans toutes ces bêtises. Continue à parler de programmation orientée objet, ou quelque chose comme ça. De quoi s'agit-il?" Notez que Bob est britannique de la façon dont il a mal orthographié.
"Eh bien, Bob," répondez-vous, grimaçant de façon orientée. "C'est assez simple vraiment. Tu ramasses les ordures, non? Quoi, tu fais généralement ton travail?"
"Eh bien, je suis la camionnette en ville ramassant les ordures et les mettant dans la camionnette", répond Bob, perplexe.
"Excellent. Eh bien, imaginez que j'écris un programme pour simuler cela. Dans la conception orientée objet, la première étape consiste à déterminer quels objets il y a. Dans votre travail, il semble y avoir des rues, des poubelles, vous et la camionnette. Ce sont nos objets. Ensuite, nous devons savoir quels comportements chaque objet exécute. Je ne sais pas comment cela fonctionne dans le monde réel, mais supposons que l'on vous parle de rues qui ont besoin d'être nettoyées. Il y a un comportement - les rues préviennent quand elles ont besoin d'être nettoyées. . Cela signifie que quelque chose doit être à l'écoute des rues qui ont besoin d'être nettoyées. Je suppose que puisque vous suivez la camionnette, la camionnette écoutera les rues qui doivent être nettoyées - c'est deux. Un troisième est, évidemment, vous suivez la camionnette. est que vous mettez des ordures dans la camionnette. Vous voyez également si une poubelle est pleine. Je suppose que la fourgonnette devra vous avertir quand elle est pleine, et vous devrez l'écouter. Ce sont nos comportements. C'est essentiellement tout ce que vous La programmation orientée objet est essentiellement la manière dont vous implémentez ent le design. Cela diffère d'une langue à l'autre. "
Bob s'est endormi dans sa bière. Tu t'en vas.