Comment enseigner l'OO sans référencer des objets physiques du monde réel? [fermé]

Je me souviens avoir lu quelque part que les concepts originaux derrière OO étaient de trouver une meilleure architecture pour gérer la messagerie des données entre plusieurs systèmes d'une manière qui protégeait l'état de ces données. Maintenant, c'est probablement une mauvaise paraphrase, mais cela m'a fait me demander s'il existe un moyen d'enseigner OO sans les analogies d'objet (vélo, voiture, personne, etc.), et qui se concentre plutôt sur les aspects de messagerie. Si vous avez des articles, des liens, des livres, etc., ce serait utile.

Le concept original d'OO n'a rien à voir avec ce qu'est l'OO d'aujourd'hui. (Voir Alors qu'est-ce que * Alan Kay voulait vraiment dire par le terme "orienté objet"? ). La programmation orientée objet d'aujourd'hui consiste à créer des objets tels que les métaphores des vélos et des maisons et des personnes, etc. Aidez-les à voir la corrélation puis aidez-les à voir les différences PUIS plonger dans des choses plus profondes sur l'OO.

EDIT: OO d'aujourd'hui consiste à créer des objets entièrement autonomes dont les propriétés et les capacités sont entièrement / partiellement décrites à l'aide de diverses méthodes (fonctions) et attributs (références à des variables et constantes AKA).

Vous pouvez parler des concepts de couplage et de cohésion. Les objets doivent être composés d'attributs et de méthodes à forte cohésion et couplage implicitement élevé. Ils doivent correspondre aux opérations et attributs les moins granulaires nécessaires au fonctionnement du système. Ils devraient également satisfaire le désir de garder le code aussi petit et simple que possible, c'est-à-dire le codage en gardant à l'esprit la maintenance et l'extensibilité.

Cela empêche également «l'explosion d'objet», la généralisation excessive et le mauvais choix de métaphore, qui sont toutes des erreurs courantes.

Je ne me concentrerais pas sur les objets du monde réel, et je ne me concentrerais pas non plus sur la messagerie. Plutôt un exemple que j'ai utilisé est dans les graphiques, où vous voulez avoir des objets qui "savent se dessiner".

Si vous travaillez en C, par exemple, sans OO intégré, vous pouvez trouver pratique de stocker des pointeurs vers des fonctions à l'intérieur d'objets de données. Si vous le faites, alors vous vous frayez un chemin dans la POO.

Je n'aime pas parler d'Alan Kay comme s'il était Moïse en train de remettre les tablettes. Au contraire, il a été formé en mathématiques et en bio, je crois. En tant que mathématicien, il avait probablement une certaine familiarité avec Lambda Calculus, qui était assez abstrait, sans rapport avec le matériel. En LC, vous pourriez dire que tout est un "objet" - comme le nombre 0 et le nombre 1 sont des objets qui évaluent des choses différentes lorsqu'ils reçoivent un argument. Cela mène assez bien à Smalltalk. L'idée de «message» est que nous pouvons éviter de parler de matériel. Vous pourriez dire que lorsque vous appelez une fonction (ou une méthode d'un objet) vous lui envoyez un message, et quand il revient, il vous envoie un message (ou à votre suite). Cela a été retenu comme un moyen de décrire les moyens de communiquer entre les programmes s'exécutant de manière asynchrone sur du matériel distinct. C'est très bien, mais pour la programmation ordinaire, ça s'emballe. Pour obtenir la valeur de l'idée de POO, vous n'avez pas besoin de nier la pertinence de la tâche concrète que vous essayez de faire, ni de la concrétisation du matériel que vous utilisez. Je pense que l'enseignement de la POO en termes d'analogies artificielles amène les gens à trop penser à la conception de logiciels en termes de structure de données, ce qui conduit à sa conception excessive, conduisant à une surcharge de code et à d'énormes problèmes de performances, que je dois passer du temps à nettoyer lorsque ça devient assez mauvais.

Je dirais qu'il y a peu de différence en utilisant un objet physique comme exemple et en utilisant un objet non physique comme exemple. Dans le code, ils ont tous deux exactement les mêmes parties. Si nous utilisons l'exemple graphique et l'enseignons avec Sphère, cube, cylindre, c'est presque la même chose que l'utilisation d'une balle, d'une boîte, d'un poteau.

Donc, pour l'enseigner sans utiliser d'exemples physiques, je suggérerais de ne pas utiliser d'exemples du tout, mais je ne vois pas pourquoi vous ne voudriez pas d'exemples physiques, donc ma position sur le sujet est

Non, vous ne devriez pas l'enseigner sans objets physiques du monde réel

Je ne vois pas comment vous pouvez éviter de commencer dans les métaphores du monde réel, mais vous ne voulez pas y rester . Si vous faites bien la POO, cela devient rapidement abstrait, mais à ce niveau de compréhension suivant, l'apprenant devrait comprendre les objets comme des objets.

Fait intéressant, certains de mes exemples préférés ne sont pas des objets physiques. Prenons l'exemple du compte bancaire. Tout le monde "comprend" pourquoi le dépôt () et le retrait () devraient facturer les frais de service, plutôt que de s'appuyer sur le code d'appel pour modifier la valeur du solde et n'oubliez pas d'enlever les frais de service. Les formes sur un écran sont doublement intangibles, et Stroustrup m'a dit que l'exemple classique "Formes" est l'un des deux plus anciens exemples d'OO qu'il connaisse, datant de 40 ans maintenant (l'autre est des véhicules, maintenant âgé de 44 ans.)

Ce qui est important, c'est que les gens comprennent tout de suite vos exemples. Les ascenseurs ne sont un bon exemple qu'avec des gens qui connaissent tous les ascenseurs. Etc.

Si vous êtes dans un groupe de programmation, réunissez quelques personnes et commencez à discuter de la façon dont vous vous diriez de faire ce que le système doit faire. Jouez littéralement des rôles dans le système (vous pouvez le faire vous-même en jouant simplement chaque rôle, mais c'est plus facile avec un groupe de personnes. Les jouets aident si vous êtes seul). Concentrez-vous sur ce que chaque personne fait / fera, plutôt que sur les données dont elle dispose. Faire cela avec les gens permet de se concentrer sur les messages et les rôles parce que les gens ont tendance à se souvenir de ce qu'ils font mais pas des données dont ils disposent.

Prenez note de ce que vous devez vous demander mutuellement et des informations dont vous avez besoin pour le faire. Protégez vos propres données, si un autre programmeur vous demande quelque chose, dites non et demandez-lui pourquoi il en a besoin (aide à l'encapsulation des données).

Je pense qu'une approche ascendante / métal pourrait être utile. Expliquez d'abord les structures et les pointeurs de style C, pour montrer comment les données peuvent être structurées plutôt que d'utiliser simplement des primitives directement. Expliquez ensuite la liaison tardive et les pointeurs de fonction. Expliquez ensuite que vous pouvez les utiliser pour créer des objets, qui sont essentiellement des piles de données bien encapsulées et des pointeurs vers les fonctions nécessaires pour fonctionner sur lesdites données.

Cette explication contredit la méthode conventionnelle de mathématiques / science-fiction de l'enseignement du concept indépendamment de la mise en œuvre, mais c'est la perspective qui m'a fait (certes, quelqu'un avec une ingénierie, pas une science-fiction, une formation) finalement obtenir OO.