Come posso spiegare la programmazione orientata agli oggetti a qualcuno che è solo codificato in Fortran 77?

Mia madre ha fatto la sua tesi universitaria a Fortran e ora (oltre un decennio dopo) ha bisogno di imparare il c ++ per simulazioni di fluidi. È in grado di comprendere tutta la programmazione procedurale, ma non importa quanto io provi a spiegarle gli oggetti, non si attacca. (Lavoro molto con Java, quindi so come funzionano gli oggetti) Penso che potrei spiegarlo in modi troppo di alto livello, quindi non ha davvero senso per qualcuno che non ha mai lavorato con loro e non è cresciuto nell'era della programmazione puramente procedurale.

Esiste un modo semplice per spiegarglielo che possa aiutarla a capire?

Risposta breve: no.

Risposta lunga: non esiste un "modo semplice" perché OOP è tutt'altro che semplice. La programmazione procedurale riguarda "variabili" e "if then goto". Tutto il resto è zucchero sintattico, ma quelle quattro cose sono tutto ciò che riguarda la programmazione procedurale. Una volta ottenuti, nulla può fermarti.

OOP è un modo per organizzare variabili e pezzi di codice. Quanti schemi ci sono per definire OOP? 25? 30? Anche gli insegnanti che hanno imparato OOP da lingue e background diversi non concordano sulla propria definizione, quindi ... come può essere semplice?

Non so come sei arrivato a questo, ma poiché tua madre ha un'esperienza simile alla mia, posso dirti come sono arrivato a quello.

Stavo programmando in C in un progetto molto grande. Era il 1988. Molti programmatori organizzavano moduli e librerie, con la difficoltà di evitare interferenze in altri lavori e di mantenere una buona separazione dei compiti.

Siamo arrivati ​​a una "soluzione" che consisteva nel mettere tutti i dati globali correlati in strutture, mettendo in quelle strutture alcuni puntatori di funzioni in cui erano richiesti callback. In questo modo abbiamo generalizzato ciò che abbiamo chiamato io_mask(una sorta di finestre di dialogo in modalità testuale) graphic_managerecc. Ecc.

Nel 1996 è stato molto facile scoprire che quelle strutture erano chiamate "classi" e quei puntatori di funzione sostituiti da funzioni membro e funzioni virtuali, o con collegamenti ad altri oggetti (chiamati comportamenti) da altri programmatori che rinnovavano quel vecchio progetto.

Ho iniziato a capire OOP quando ho iniziato a sentirne la necessità: segregazione, polimorfismo e comportamenti definiti in fase di esecuzione.

Oggi lavoro con OOP, ma non la considero una dottrina da servire: solo un "linguaggio comune" (set di ...) che ci permette di parlare insieme senza la necessità di fornire spiegazioni e descrizioni lunghe in ogni momento . In effetti, più una "convenzione" che altro. Dopotutto, tutto ciò che OOP fa è -again- "if then goto": lo fa semplicemente "multistrato". Da qui l'astrazione e gli idiomi sugli idiomi.

Ignorali. Fino a quando non sente il bisogno di loro, non prova nemmeno a spiegare: li sentirà come un modo complicato di fare cose semplici. E ha ragione ... fino a quando quello che fa non è, in effetti, semplice.

Nessuno penserà di "organizzare una scrivania" se ci sono solo quattro cose in cima. Ha senso quando le cose in alto iniziano a interferire a vicenda. Questo è il momento per OOP di entrare.

Non è necessario OOP per funzionare con C ++. L'intera libreria standard C ++ non è progettata in termini di OOP (sebbene possa collaborare con essa) e C ++ non è Java.

In tutta la mia esperienza, i peggiori insegnanti di C ++ e programmatori di C ++ sono quelli che provengono da Java, insegnando a tutti i loro pregiudizi su tutto ciò che non è OOP, denaturando un linguaggio come C ++ che non è (solo) per OOP.

Permettetemi di suggerire un buon libro per coloro che vogliono avvicinarsi al C ++: C ++ accelerato : vi porterà nei modi di dire C ++ senza far finta di seguire una dottrina predefinita.

Un vecchio amico ha affermato che avevo la definizione più breve che conosceva della programmazione OO e ho scoperto che funziona per alcune persone (e non per altri):

La programmazione orientata agli oggetti è un dato con un'opinione. Non muovi la sedia, chiedi alla sedia di muoversi da sola. Non si ordina l'elenco, si chiede di ordinare se stesso (forse con un suggerimento). Eccetera.

L'idea è di indurre la persona a pensare in modo diverso a come le cose vengono fatte all'interno del loro programma.

Dille di pensare a oggetti come oggetti nel mondo reale. Ad esempio, il mondo intero può essere un mix di programmazione orientata agli oggetti (in C ++) con una sorta di programmazione funzionale (probabilmente fatta nel linguaggio di dio, Lisp).

Prendi un oggetto, ad esempio il tosaerba, ha alcuni attributi e può fare una certa cosa. (oggetto e classe)

Quindi raccontale di un rasaerba migliore che è un'estensione del tosaerba che hai già. Dille che è meglio, ma si basa ancora sullo stesso meccanismo (eredità).

Allora raccontale di te. Dille che a volte puoi diventare un esperto di tosaerba ma in realtà sei un programmatore e fallo per vivere. È come se tu fossi due entità diverse contemporaneamente. Questo è polimorfismo.

Quando lo capisce, parlale di come implementare queste cose nella lingua che deve imparare (C ++).

Quindi dille che, se deve scrivere una simulazione di questo mondo nel mondo dei computer, dovrà imparare a farlo.

Quando sa come convertire i suoi pensieri sul mondo reale in codice di programma. avrebbe imparato a programmare nel linguaggio di programmazione orientato agli oggetti.

Sono passato dall'assemblatore e COBOL a Ruby.

Ciò che mi ha aiutato inizialmente era in realtà ignorare il concetto di classi che creavano istanze.

Inizia con il codice. Avere una classe ma solo metodi a livello di classe. All'interno dei metodi molte cose riguardano parametri, variabili, condizionali, array, stringhe, booleani, ecc. Questa roba dovrebbe essere familiare.

Quindi a questo punto la classe può essere vista semplicemente come uno scopo in cui collocare tutti i metodi correlati. Chiamarla contenitore o libreria le sarà più familiare.

Ovviamente il codice deve essere segmentato per essere gestibile, quindi ne avrai uno per ogni area. Ad esempio, per la gestione di una serie di programmi di utilità su un PC, è possibile disporre di una classe di calcolatrice in cui è possibile inserire tutto il codice per una calcolatrice in un unico posto. Se hai solo 1 calcolatrice sul tuo PC, sono sufficienti metodi a livello di classe.

Questo è un inizio.

ok ora considera il fatto che vuoi aprire più calcolatrici e cambiare l'aspetto di ognuno e dove si trova sullo schermo. Quindi ora non puoi semplicemente avere un metodo di calcolatrice come 'screen_location' perché ne hai diversi e ogni istanza ha la sua posizione ... ogni istanza ... ok, quindi abbiamo bisogno di istanze.

Nota: i miei termini provengono dal rubino e non dal c ++, quindi potresti dover tradurre.

Lo spiegherei in due passaggi, o forse quattro, a seconda di quanto ti piace dividere i tuoi concetti.

Step 1: Presentala alle strutture. È un passaggio abbastanza piccolo dai tipi di dati Fortran alle strutture. Passaggio 1a: assicurati di capire l'allocazione e i puntatori della memoria dinamica standard.

Passaggio 2: aggiungere procedure associate solo a tali strutture. Passaggio 2a: aggiungere l'eredità basata sulla costruzione di strutture più grandi che "avvolgono" strutture più piccole.

Per un programmatore Fortran, il fattore "wow" sarà che è molto da tenere traccia del compilatore. Sì. Ecco a cosa servono i compilatori ...

Se ha fatto la sua tesi un decennio fa, probabilmente ha usato Fortan 90 o 95, nel qual caso la cosa da fare è parlarne in relazione ai tipi di dati derivati. Se è stato abbastanza tempo fa che ha usato Fortran 77, quindi introdurla a tipi di dati derivati ​​in Fortran 90 e poi parlarne ...

Non andrei nel polimorfismo e nell'eredità, fino a quando non avrà compreso l'incapsulamento, poiché possono essere visti come casi speciali ed estensioni dell'incapsulamento. Probabilmente la inizierei con un linguaggio che consenta funzioni libere o classi statiche.

Una volta che capisce le strutture, penso che il prossimo punto chiave sarà riconoscere che la programmazione orientata agli oggetti serve come mezzo per limitare l'insieme di metodi a cui una cosa può essere passata, all'insieme di metodi che potrebbero effettivamente essere applicati a quello cosa.

Nella programmazione non orientata agli oggetti, se si utilizzano tipi di dati separati per una struttura ad albero e una lista collegata, è necessario utilizzare metodi diversi per aggiungere un nodo a ciascuno. Lingue non orientati agli oggetti sarebbero generalmente squawk se uno ha cercato di nominare entrambi i metodi AddItem, dal momento che un dato nome può riferirsi a un solo metodo, determinando in tal modo uno per creare i nomi dei metodi, come AddTreeItem, AddLinkedListItem, RemoveTreeItem, ecc un tale approccio funziona, ma è un po ' brutto. Concettualmente, i metodi AddTreeIteme RemoveTreeItemsembrano appartenere insieme, ma i nomi non si ordinano in questo modo. Si potrebbe riscrivere i nomi come TreeAddItem, TreeRemoveItem,LinkedListAddItem, ecc. ma ciò comporterebbe un sacco di "rumore ridondante" all'inizio di ogni invocazione del metodo. La stragrande maggioranza delle chiamate di metodo in un tipico programma avrà tre informazioni essenziali: (1) quale sezione del codice sorgente contiene il metodo; (2) quale dei metodi nella sezione viene utilizzato; (3) su quali dati vengono sottoposti? In molti casi, il tipo di dati su cui si agisce sarà sufficiente per identificare a quale sezione di codice appartiene il metodo, quindi la parte (1) di cui sopra è ridondante. È più facile identificare visivamente il materiale all'inizio di un'istruzione che il materiale altrove, quindi uno stile di codifica / denominazione come TreeAddItem(myTree, whatever)finisce per mettere in primo piano l'informazione meno utile.

Al contrario, usando la programmazione orientata agli oggetti, si chiamerebbero effettivamente metodi come Tree.AddItem, ecc. E un'istruzione come myTree.AddItem(whatever)farebbe dire a un compilatore, in sostanza, "Hmm ... myTreeè di tipo Tree, quindi questo codice dovrebbe invocare Tree.AddItem(). Non è necessario specificare Tree.quando si chiama AddItempoiché il compilatore conosce il tipo di myTree. Concettualmente, un'istruzione like myTree.AddItem(whatever)è equivalente Tree.AddItem(myTree, whatever)e alcuni linguaggi orientati agli oggetti possono consentire entrambi i moduli come equivalenti; in effetti, la maggior parte delle lingue omette il primo parametro dalla specifica della funzione e invece ha metodi definiti in una classe come Treeimplicitamente prendono un parametro di tipo Tree, e assegnare un nome simile this, selfo Me.

I linguaggi di programmazione orientati agli oggetti spesso includono una varietà di funzioni aggiuntive come ereditarietà, funzioni virtuali, ecc. Che sono molto utili in molte applicazioni, ma anche senza quelle caratteristiche la capacità di raggruppare le funzioni in base alle cose su cui operano è molto utile.

La programmazione orientata agli oggetti - nel senso orientato alla classe rilevante qui - riguarda l'accoppiamento di una rappresentazione di dati con il codice che la manipola. Ha senso se le seguenti cose hanno un senso:

• Accoppiamento: definizione di un'operazione accanto alla rappresentazione dei dati su cui lavora

• Associazione tardiva: scelta di una combinazione di rappresentazione e comportamento dei dati in fase di esecuzione

• Incapsulamento: garantire che i dati siano validi per costruzione e non saranno successivamente invalidati

È tutto. Come ogni tecnologia, al suo interno è semplicemente una comodità, da cui in seguito sono seguiti molti sviluppi. Una volta comprese le basi, il resto segue nel tempo.

Suggerirei di scaricare BlueJ, giocarci per 20 minuti e poi farla giocare per 20 minuti.

Il modo in cui visualizza classi, interfacce ed ereditarietà è così ovvio e intuitivo che ti dà davvero una comprensione istantanea mentre implementi qualcosa, qualsiasi cosa.

Ti mostra anche direttamente la differenza tra una classe e un oggetto

Non fornirà alcuna conoscenza approfondita dei modelli di progettazione OO, ma fornirà una fantastica panoramica dei concetti.

Vorrei aggiungere il mio contributo come promemoria della distinzione tra paradigmi di programmazione e linguaggi di programmazione che implementano questi paradigmi.

Quindi, secondo me, il modo migliore per spiegare l'orientamento agli oggetti con C ++ a un utente F77 sarebbe procedere in modo graduale:

Innanzitutto, presenta all'utente il concetto di orientamento dell'oggetto in un ambiente familiare mostrandole come sviluppare strutture simili a oggetti in Fortran 77 - ad esempio, dai un'occhiata a documenti come B. Patton "Object-oriented Fortran 77 (un praticante view) "SIGPLAN Fortran Forum 12, 2 (1993), pagg. 23-24, e relativi riferimenti.

Quindi, stabilire una corrispondenza tra tali strutture e classi e metodi C ++.

Infine, discutere le funzionalità aggiuntive che C ++ può fornire per facilitare la programmazione OO.

Quando stavo migrando per la prima volta in un linguaggio orientato agli oggetti dalla mia formazione iniziale in Pascal, il "." il problema era il più grande ostacolo anche per me. Mi ci sono voluti anni per superarlo.

In realtà non è molto intuitivo che una variabile appartenga a un'altra variabile, specialmente quando sei abituato a considerarle come puntatori. L'ostacolo per me è stato:

• Cosa significa per qualcosa che è fondamentalmente un puntatore, avere un altro puntatore che lo punta, che si risolve in una cosa diversa rispetto al puntatore genitore?

Il momento aha per me è stato quando ho capito che il puntatore di livello superiore era fondamentalmente solo uno spazio dei nomi.

Suggerirei di farle scrivere un mucchio di codice che le richiede di spaziare le sue funzioni, idealmente senza usare la notazione punto per cominciare. Quindi convincila a provare a riscriverlo usando la notazione a punti.

Fare quell'esercizio dovrebbe farla superare l'iniziale "Che stregoneria è questa?" ostacolo.

Un'intuizione chiave che mi ha aiutato a spiegare prima è il fatto che puoi avere più istanze di una classe. Prova a spiegarlo in termini di "disegni" o "stampi" e "copie" e vedi se conduce ovunque.