Comment expliquer la programmation orientée objet à quelqu'un qui n'est codé qu'en Fortran 77?

Ma mère a fait sa thèse à Fortran, et maintenant (plus d'une décennie plus tard) a besoin d'apprendre le c ++ pour les simulations de fluides. Elle est capable de comprendre toute la programmation procédurale, mais peu importe à quel point j'essaie de lui expliquer des objets, ça ne colle pas. (Je travaille beaucoup avec Java, donc je sais comment fonctionnent les objets) Je pense que je pourrais l'expliquer de manière trop élevée, donc cela n'a pas vraiment de sens pour quelqu'un qui n'a jamais travaillé avec eux et qui a grandi à l'ère de la programmation purement procédurale.

Existe-t-il un moyen simple de lui expliquer qui pourra l'aider à comprendre?

Réponse courte: non.

Réponse longue: il n'y a pas de "voie simple" car la POO est loin d'être simple. La programmation procédurale est tout au sujet des "variables" et "si alors allez". Tout le reste est du sucre syntaxique, mais ces quatre choses sont toutes liées à la programmation procédurale. Une fois que vous les obtenez, rien ne peut vous arrêter.

La POO est un moyen d'organiser des variables et des morceaux de code. Combien de modèles existe-t-il pour définir la POO? 25? 30? Même les enseignants qui ont appris la POO dans différentes langues et origines ne sont pas d'accord sur sa propre définition, alors ... comment cela peut-il être simple?

Je ne sais pas comment vous en êtes arrivé là, mais comme votre mère a une expérience similaire à la mienne, je peux vous dire comment j'en suis arrivée là.

Je programmais en C dans un très gros projet. C'était en 1988. De nombreux programmeurs organisaient des modules et des bibliothèques, avec la difficulté d'éviter les interférences dans d'autres emplois et de maintenir une bonne séparation des tâches.

Nous sommes arrivés à une "solution" qui consistait à mettre toutes les données globales interdépendantes dans des structures, en plaçant dans ces structures des pointeurs de fonction où des rappels étaient requis. Nous généralisions ainsi ce que nous appelions io_mask(sorte de boîtes de dialogue en mode textuel) et graphic_manageretc. etc.

En 1996, il a été très facile de découvrir que ces structures étaient nommées "classes" et ces pointeurs de fonction remplacés par des fonctions membres et des fonctions virtuelles, ou avec des liens vers d'autres objets (appelés comportements) par d'autres programmeurs qui ont renouvelé cet ancien projet.

J'ai commencé à comprendre la POO lorsque j'ai commencé à en ressentir le besoin: ségrégation, polymorphisme et comportements définis lors de l'exécution.

Aujourd'hui, je travaille avec la POO, mais je n'y pense pas comme une doctrine à servir: juste un "idiome commun" (ensemble de ...) qui nous permet de parler ensemble sans avoir besoin de fournir de longues explications et descriptions tout le temps . En fait, plus une "convention" qu'autre chose. Après tout, tout ce que la POO fait est -encore- "si ensuite allez": il le fait simplement "multicouche". D'où l'abstraction et les idiomes sur les idiomes.

Ignore les. Tant qu'elle n'en ressentira pas le besoin, n'essayez même pas de l'expliquer: elle les ressentira comme une manière compliquée de faire des choses simples. Et elle a raison ... jusqu'à ce que ce qu'elle fasse soit - en fait - simple.

Personne ne pensera à "organiser un bureau" s'il n'y a que quatre choses en haut. Il est logique que les éléments supérieurs commencent à interférer les uns avec les autres. C'est le moment pour la POO d'entrer.

Vous n'avez pas besoin de POO pour travailler avec C ++. La bibliothèque standard C ++ entière n'est pas conçue en termes de POO (bien qu'elle puisse coopérer avec elle), et C ++ n'est pas Java.

D'après toute mon expérience, les pires enseignants et programmeurs C ++ sont ceux qui viennent de Java, enseigner tous leurs préjugés à propos de tout n'est pas OOP, dénaturant un langage comme C ++ qui n'est pas (juste) pour OOP.

Permettez-moi de suggérer un bon livre pour ceux qui veulent aborder le C ++: C ++ accéléré : il vous amènera dans des idiomes C ++ sans prétendre suivre une doctrine prédéfinie.

Un vieil ami a affirmé que j'avais la définition la plus courte qu'il connaissait de la programmation OO, et j'ai trouvé que cela fonctionne pour certaines personnes (et pas pour d'autres):

La programmation orientée objet est une donnée avec une opinion. Vous ne déplacez pas la chaise, vous demandez à la chaise de se déplacer. Vous ne triez pas la liste, vous lui demandez de se trier (peut-être avec un indice). Etc.

L'idée est d'amener la personne à penser différemment à la façon dont les choses se font dans son programme.

Dites-lui de penser à des objets comme des objets dans le monde réel. Par exemple, le monde entier peut être un mélange de programmation orientée objet (en C ++) avec une sorte de programmation fonctionnelle (probablement réalisée en langage divin, Lisp).

Prenez un objet, par exemple la tondeuse à gazon, il a certains attributs et il peut faire une certaine chose. (objet et classe)

Ensuite, parlez-lui d'une meilleure tondeuse à gazon qui est une extension de la tondeuse à gazon que vous avez déjà. Dites-lui que c'est mieux mais repose toujours sur le même mécanisme (héritage).

Parlez-lui de vous. Dites-lui que vous pouvez parfois devenir un expert en tonte de pelouse, mais vous êtes en fait un programmeur et faites-le pour gagner sa vie. C'est comme si vous agissiez comme deux entités différentes en même temps. C'est du polymorphisme.

Au moment où elle l'obtient, dites-lui comment implémenter ces choses dans le langage qu'elle doit apprendre (C ++).

Dites-lui ensuite que si elle doit écrire une simulation de ce monde dans le monde informatique, elle devra apprendre à le faire.

Quand elle sait comment convertir ses pensées du monde réel en code de programme. elle aurait appris à programmer dans un langage de programmation orienté objet.

Je suis passé d'assembleur et de COBOL à Ruby.

Ce qui m'a aidé au départ était en fait d'ignorer le concept de classes créant des instances.

Commencez simplement par le code. Avoir une classe mais juste des méthodes au niveau de la classe. Dans les méthodes, beaucoup de choses concernent les paramètres, les variables, les conditions, les tableaux, les chaînes, les booléens, etc. Ces choses devraient être familières.

Donc, à ce stade, la classe peut être considérée comme servant simplement le but comme un endroit où mettre toutes vos méthodes connexes. Appelez-le un conteneur ou une bibliothèque lui sera plus familier.

De toute évidence, le code doit être segmenté pour être gérable, vous en aurez donc un dans chaque zone. Par exemple, pour gérer un ensemble de programmes utilitaires sur un PC, vous pourriez avoir une classe de calculatrice où vous pourriez mettre tout le code d'une calculatrice en un seul endroit. Si vous n'avez qu'une seule calculatrice sur votre PC, les méthodes au niveau de la classe suffisent.

Voilà un début.

ok, considérez maintenant le fait que vous souhaitez ouvrir plusieurs calculatrices et modifier leur apparence et leur emplacement à l'écran. Alors maintenant, vous ne pouvez pas simplement avoir une méthode de calculatrice comme 'screen_location' car vous en avez plusieurs et chaque instance a son propre emplacement ... chaque instance ... ok, nous avons donc besoin d'instances.

Remarque: mes termes proviennent de ruby ​​et non de c ++, vous devrez donc peut-être traduire.

Je l'expliquerais en deux étapes, ou peut-être quatre, selon la façon dont vous aimez diviser vos concepts.

Étape 1: Présentez-la aux structures. C'est une étape assez petite des types de données Fortran aux structures. Étape 1a: assurez-vous qu'elle comprend l'allocation de mémoire dynamique et les pointeurs.

Étape 2: ajoutez des procédures associées uniquement à ces structures. Étape 2a: ajouter un héritage basé sur la construction de structures plus grandes qui "enveloppent" des structures plus petites.

Pour un programmeur Fortran, le facteur "wow" sera que le compilateur a beaucoup à garder à l'esprit. Ouaip. C'est à ça que servent les compilateurs ...

Si elle a fait sa thèse il y a une décennie, elle a probablement utilisé Fortan 90 ou 95, auquel cas il s'agit d'en parler en relation avec les types de données dérivés. S'il y a assez longtemps qu'elle a utilisé Fortran 77, introduisez-la aux types de données dérivés dans Fortran 90, puis parlez-en ...

Je n'entrerais dans le polymorphisme et l'héritage qu'après avoir saisi l'encapsulation, car ils peuvent être considérés comme des cas spéciaux et des extensions d'encapsulation. Je voudrais probablement la démarrer sur un langage qui autorise des fonctions libres ou des classes statiques.

Une fois qu'elle comprend les structures, je pense que le prochain point clé sera de reconnaître que la programmation orientée objet sert de moyen de confiner l'ensemble des méthodes auxquelles une chose peut être transmise, à l'ensemble des méthodes qui pourraient réellement être appliquées à cela. chose.

Dans la programmation non orientée objet, si l'on utilise des types de données séparés pour une arborescence et une LinkedList, il faudrait utiliser différentes méthodes pour ajouter un nœud à chacun. Les langues non orientées objet serait généralement couac si on a essayé de nommer les deux méthodes AddItem, car un nom donné ne peut se référer à une méthode, ce qui conduit l' un pour créer des noms de méthodes comme AddTreeItem, AddLinkedListItem, RemoveTreeItem, etc. Un tel travaux d'approche, mais il est un peu laid. Conceptuellement, les méthodes AddTreeItemet RemoveTreeItemsemblent appartenir ensemble, mais les noms ne sont pas triés de cette façon. On pourrait réécrire les noms comme TreeAddItem, TreeRemoveItem,LinkedListAddItem, etc. mais cela mettrait beaucoup de "bruit redondant" au début de chaque invocation de méthode. La grande majorité des appels de méthode dans un programme typique auront trois informations essentielles: (1) quelle section du code source contient la méthode; (2) laquelle des méthodes de la section est utilisée; (3) sur quel élément de données est-il donné suite? Dans de nombreux cas, le type de données faisant l'objet d'une action sera suffisant pour identifier la section de code à laquelle la méthode appartient, de sorte que la partie (1) de ce qui précède est redondante. Il est plus facile d'identifier visuellement le matériel au début d'une déclaration que le matériel ailleurs, donc un style de codage / dénomination comme celui-ci TreeAddItem(myTree, whatever)finit par mettre l'élément d'information le moins utile au premier plan.

En revanche, en utilisant la programmation orientée objet, on pourrait nommer efficacement les méthodes comme Tree.AddItem, etc. et une déclaration comme myTree.AddItem(whatever)provoqueraient un compilateur à dire, essentiellement, « Hmm ... myTreeest de type Tree, de sorte que ce code devrait appeler Tree.AddItem(). Il est nécessaire de ne pas spécifiez le Tree.lors de l'appel AddItemcar le compilateur connaît le type de myTree. Conceptuellement, une instruction comme myTree.AddItem(whatever)est équivalente à Tree.AddItem(myTree, whatever), et certains langages orientés objet peuvent autoriser les deux formes comme équivalentes; en fait, la plupart des langages omettent le premier paramètre de la spécification de fonction et ont à la place méthodes définies dans une classe comme Treeprennent implicitement un paramètre de type Tree, et lui attribuer un nom comme this, selfou Me.

Les langages de programmation orientés objet incluent souvent une variété de fonctionnalités supplémentaires telles que l'héritage, les fonctions virtuelles, etc. qui sont très utiles dans de nombreuses applications, mais même sans ces fonctionnalités, la capacité de regrouper des fonctions en fonction des éléments sur lesquels elles opèrent est très utile.

La programmation orientée objet - au sens orienté classe ici pertinent - consiste à coupler une représentation de données avec le code qui la manipule. Cela a du sens si les choses suivantes ont du sens:

• Couplage: définir une opération à côté de la représentation des données sur laquelle elle travaille

• Liaison tardive: choix d'une combinaison de représentation et de comportement des données lors de l'exécution

• Encapsulation: garantir que les données sont valides par construction et ne seront pas invalidées ultérieurement

C'est tout. Comme toute technologie, en son cœur, c'est simplement une commodité, dont de nombreux développements ont ensuite suivi. Une fois que vous avez compris les bases, le reste suit dans le temps.

Je suggère de télécharger BlueJ, de jouer avec lui pendant 20 minutes puis de la faire jouer avec pendant 20 minutes.

La façon dont il visualise les classes, les interfaces et l'héritage est si évidente et intuitive qu'elle vous donne vraiment une compréhension instantanée lorsque vous implémentez quelque chose - n'importe quoi.

Il vous montre même directement la différence entre une classe et un objet

Cela ne donnera pas un aperçu approfondi des modèles de conception OO, mais cela donnera un aperçu fantastique des concepts.

Je voudrais ajouter ma contribution pour rappeler la distinction entre les paradigmes de programmation et les langages de programmation qui mettent en œuvre ces paradigmes.

Donc, à mon avis, la meilleure façon d'expliquer l'orientation des objets avec C ++ à un utilisateur F77, serait de procéder par étapes:

Tout d'abord, initiez l'utilisateur au concept d'orientation d'objet dans un cadre familier en lui montrant comment développer des structures de type objet dans Fortran 77 - par exemple, jetez un œil à des articles comme B. Patton "Fortran 77 orienté objet" (un praticien view) "SIGPLAN Fortran Forum 12, 2 (1993), pp. 23-24, et les références qui y figurent.

Ensuite, établissez une correspondance entre ces structures et les classes et méthodes C ++.

Enfin, discutez des fonctionnalités supplémentaires que C ++ peut fournir pour faciliter la programmation OO.

Lors de ma première migration vers un langage orienté objet depuis ma formation initiale en Pascal, le '.' Le problème était aussi le plus gros obstacle pour moi. Il m'a fallu des années pour m'en remettre.

En fait, il n'est vraiment pas intuitif qu'une variable appartienne à une autre variable, surtout lorsque vous avez l'habitude de les considérer comme des pointeurs. La pierre d'achoppement pour moi était:

• Qu'est-ce que cela signifie pour quelque chose qui est fondamentalement un pointeur, d'avoir un autre pointeur pointant vers lui, qui se résout en une chose différente du pointeur parent?

Le moment aha pour moi a été quand j'ai réalisé que le pointeur de niveau supérieur était essentiellement juste un espace de noms.

Je suggérerais de lui faire écrire un tas de code qui l'oblige à nommer ses fonctions, idéalement sans utiliser la notation par points pour commencer. Ensuite, demandez-lui d'essayer de le réécrire en utilisant la notation par points.

Faire cet exercice devrait lui permettre de se remettre du "Qu'est-ce que la sorcellerie?" obstacle.

Un aperçu clé qui m'a aidé à expliquer auparavant est le fait que vous pouvez avoir plusieurs instances d'une classe. Essayez d'expliquer cela en termes de «dessins» ou de «moules» et de «copies» et voyez si cela mène quelque part.