Come si può insegnare OO senza fare riferimento a oggetti fisici del mondo reale? [chiuso]

Ricordo di aver letto da qualche parte che i concetti originali alla base di OO erano di trovare un'architettura migliore per gestire la messaggistica dei dati tra più sistemi in modo da proteggere lo stato di tali dati. Ora questa è probabilmente una povera parafrasi, ma mi ha fatto domandare se esiste un modo per insegnare OO senza le analogie di oggetti (Bici, Macchina, Persona, ecc.) E che invece si concentra sugli aspetti della messaggistica. Se hai articoli, link, libri, ecc., Sarebbe utile.

Il concetto originale di OO non ha nulla a che fare con ciò che è OO di oggi. (Vedi quindi cosa * Alan Kay * intendeva veramente con il termine "orientato agli oggetti"? ). La programmazione odierna orientata agli oggetti IS sulla creazione di oggetti come le metafore di biciclette, case e persone, ecc. Consiglio vivamente di attenersi a questi perché lo scopo delle metafore è aiutare le persone a capire usando un concetto che già comprendono. Aiutali a vedere la correlazione, poi aiutali a vedere le differenze ALLORA immergiti nelle cose più profonde su OO.

EDIT: OO di oggi riguarda la creazione di oggetti completamente autonomi le cui proprietà e abilità sono completamente / parzialmente descritte usando vari metodi (funzioni) e attributi (riferimenti a variabili e costanti AKA).

Puoi parlare di concetti di accoppiamento e coesione. Gli oggetti dovrebbero essere composti da attributi e metodi con elevata coesione e accoppiamento implicitamente elevato. Dovrebbero essere associati alle operazioni e agli attributi meno granulari necessari per il funzionamento del sistema. Dovrebbero anche soddisfare il desiderio di mantenere il codice il più piccolo e semplice possibile, vale a dire codificare tenendo presente la manutenzione e l'estensibilità.

Ciò impedisce anche "esplosione di oggetti", eccessiva generalizzazione e scelta errata della metafora che sono tutti errori comuni.

Non mi concentrerei sugli oggetti del mondo reale e non mi concentrerei nemmeno sulla messaggistica. Piuttosto un esempio che ho usato è nella grafica, dove vuoi avere oggetti che "sappiano disegnare da soli".

Se stai lavorando in C, ad esempio, che non ha OO incorporato, potresti trovare conveniente memorizzare i puntatori alle funzioni all'interno degli oggetti dati. Se lo fai, allora ti stai facendo strada verso OOP.

Non mi piace fare riferimento ad Alan Kay come se Mosè stesse tramandando le compresse. Piuttosto, è stato addestrato in matematica e bio, credo. Come ragazzo di matematica, probabilmente aveva una certa familiarità con Lambda Calculus, che era piuttosto astratto, non legato all'hardware. In LC, potresti dire che tutto è un "oggetto" - come il numero 0 e il numero 1 sono oggetti che valutano cose diverse quando viene dato un argomento. Questo porta a Smalltalk abbastanza bene. L'idea di "messaggio" è così che possiamo evitare di parlare di hardware. Potresti dire quando chiami una funzione (o un metodo di un oggetto) che gli stai inviando un messaggio, e quando ritorna, ti sta inviando un messaggio (o alla tua continuazione). Ciò è stato considerato come un modo per descrivere i modi di comunicare tra i programmi eseguiti in modo asincrono su hardware separato. Va bene, ma per la normale programmazione viene portato via. Per ottenere il valore dell'idea OOP, non è necessario negare la pertinenza dell'attività concreta che si sta tentando di eseguire o negare la concretezza dell'hardware su cui si esegue. Penso che insegnare OOP in termini di analogie inventate porti le persone a pensare troppo alla progettazione del software in termini di struttura dei dati, portando alla sua sovra-progettazione, portando a gonfiore del codice e enormi problemi di prestazioni, che devo passare il tempo a ripulire quando diventa abbastanza male.

Direi che c'è poca differenza nell'usare un oggetto fisico come esempio e nell'utilizzare un oggetto non fisico come esempio. Nel codice entrambi hanno le stesse parti esatte. Se usiamo l'esempio grafico e lo insegniamo con Sfera, cubo, cilindro, è quasi uguale all'utilizzo di palla, scatola, palo.

Quindi per insegnarlo senza usare esempi fisici suggerirei di non usare alcun esempio, ma non vedo perché non vorresti esempi fisici, quindi la mia posizione sull'argomento è

No, non dovresti insegnarlo senza oggetti fisici del mondo reale

Non vedo come puoi evitare di iniziare nelle metafore del mondo reale, ma non vuoi restare lì. Se stai facendo OOP nel modo giusto, diventa rapidamente astratto, ma a quel livello successivo di comprensione, lo studente dovrebbe capire gli oggetti come oggetti.

È interessante notare che alcuni dei miei esempi preferiti non sono oggetti fisici. Prendi ad esempio un conto bancario. Tutti "capiscono" perché deposit () edraw () dovrebbero addebitare il costo del servizio, piuttosto che fare affidamento sul codice chiamante per modificare il valore del saldo e ricordarsi di togliere il costo del servizio. Le forme su uno schermo sono doppiamente immateriali, e Stroustrup mi ha detto che il classico esempio di "Forme" è uno dei due esempi di OO più antichi che conosce, risalente a 40 anni fa (l'altro è veicoli, ora 44 anni).

L'importante è che le persone capiscano subito i tuoi esempi. Gli ascensori sono un buon esempio solo per le persone che hanno familiarità con gli ascensori. Eccetera.

Se fai parte di un gruppo di programmazione, riunisci alcune persone e inizia a discutere su come ti diresti a vicenda di fare ciò di cui il sistema ha bisogno. Assumi letteralmente ruoli nel sistema (puoi farlo da solo giocando ogni ruolo, ma è più facile con un gruppo di persone. I giocattoli aiutano se sei da solo). Concentrati su ciò che ogni persona sta facendo / farà, piuttosto che su quali dati ha. Farlo con le persone aiuta a focalizzarsi su messaggi e ruoli perché le persone tendono a ricordare cosa stanno facendo ma non i dati che hanno.

Prendi nota di ciò che devi chiederti l'un l'altro e di quali informazioni hai bisogno per farlo. Proteggi i tuoi dati, se un altro programmatore chiede i tuoi dati per qualcosa, dì di no e chiedigli perché ne ha bisogno (aiuta l'incapsulamento dei dati).

Penso che un approccio bottom-up / metal possa essere utile. Spiega innanzitutto le strutture e i puntatori in stile C, per mostrare come i dati possono essere strutturati piuttosto che usare direttamente le primitive. Quindi spiegare i puntatori di associazione e funzione in ritardo. Spiega quindi che puoi usarli per costruire oggetti, che sono sostanzialmente pile ben incapsulate di dati e puntatori alle funzioni necessarie per operare su tali dati.

Questa spiegazione è in contraddizione con il modo convenzionale di matematica / scienze dell'insegnamento del concetto indipendentemente dall'implementazione, ma è la prospettiva che mi ha fatto (certamente qualcuno con un background di ingegneria, non di scienze, di formazione) finalmente ottenere OO.