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

Risposta breve: no.

Risposta lunga: non esiste un "modo semplice" perché OOP è tutt'altro che semplice. La programmazione procedurale riguarda "variabili" e "se poi goto". Tutto il resto è zucchero sintattico, ma queste 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 l'OOP? 25? 30? Anche gli insegnanti che hanno imparato l'OOP da lingue e sfondi diversi non sono d'accordo sulla propria definizione, quindi ... come può essere semplice?

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

Stavo programmando in C in un progetto molto ampio. Era il 1988. Molti programmatori organizzano moduli e biblioteche, con la difficoltà di evitare interferenze in altri lavori e mantenere una buona segregazione dei compiti.

Siamo arrivati a una "soluzione" che consisteva nel mettere tutti i dati globali interconnessi in strutture, inserendo in quelle strutture alcuni puntatori di funzione in cui erano richiesti i callback. Abbiamo generalizzato in questo modo ciò che abbiamo chiamato io_mask (una sorta di finestre di dialogo in modalità testuale) e graphic_manager ecc. Ecc.

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

Ho iniziato a capire OOP quando ho iniziato a sentire la necessità di farlo: segregazione, polimorfismo e comportamenti definiti durante il runtime.

Oggi lavoro con OOP, ma non lo considero una dottrina da utilizzare: solo un "linguaggio comune" (insieme di ...) che ci permette di parlare insieme senza la necessità di fornire lunghe spiegazioni e descrizioni tutto il tempo. In realtà, più una "convenzione" che altro. Dopotutto, tutto ciò che OOP fa è -un nuovo- "se poi goto": lo fa semplicemente "multistrato". Di qui l'astrazione e gli idiomi oltre gli idiomi.

Ignorali. Finché non sente che il bisogno per loro non cerca nemmeno di spiegarlo: li sentirà solo come un modo complicato di fare cose semplici. E ha ragione ... finché quello che fa è -in fatto- semplice.

Nessuno penserà a "organizzare una scrivania" se ci sono solo quattro cose in cima. Ha senso quando le cose in cima iniziano a interferire a vicenda. È ora che OOP entri.

Non hai bisogno di OOP per lavorare con C ++. L'intera libreria standard C ++ non è progettata in termini di OOP (sebbene possa cooperare con esso), e C ++ non è Java.

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

Consentitemi di suggerire un buon libro per coloro che desiderano avvicinarsi al C ++: C ++ accelerato : vi porterà in idiomi C ++ senza fingere di seguire una dottrina predefinita.

Un vecchio amico sosteneva che avessi la definizione più breve che conoscesse della programmazione OO e ho trovato che funziona per alcune persone (e non per altre):

La programmazione orientata agli oggetti è un dato con un'opinione. Non muovi la sedia, chiedi alla sedia di spostarsi. Non si ordina la lista, si chiede di ordinare da sé (magari con un suggerimento). Ecc.

L'idea è di convincere 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 in linguaggio divino, Lisp).

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

Allora parlagli di un tosaerba migliore che è un'estensione del tosaerba che hai già. Diglielo meglio, ma continua a costruire sullo stesso meccanismo (ereditarietà).

Allora parlagli di te. Dille che a volte puoi diventare un esperto di falciatura ma in realtà sei un programmatore e lo fai per vivere. È come se agissi come due entità diverse allo stesso tempo. Questo è polimorfismo.

Quando arriva questo, le dica come implementare queste cose nel linguaggio che deve imparare (C ++).

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

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

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

Passaggio 1: introdurla alle strutture. È un passo abbastanza piccolo dai tipi di dati Fortran alle strutture. Fase 1a: assicurati che abbia un'allocazione di memoria dinamica standard e dei puntatori.

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

Per un programmatore Fortran, il fattore "wow" sarà che è molto per il compilatore per tenere traccia di. Sì. Questo è ciò che i compilatori sono per ...

Se avesse fatto la sua tesi una decina di anni fa, probabilmente ha usato Fortan 90 o 95, nel qual caso la cosa giusta è parlarne in relazione ai tipi di dati derivati. Se è stato abbastanza tempo fa, ha usato Fortran 77, quindi le ha presentato i tipi di dati derivati in Fortran 90 e poi ne ha parlato ...

Non entrerei nel polimorfismo e nell'ereditarietà, finché non avrà afferrato l'incapsulamento, poiché possono essere considerati casi speciali ed estensioni dell'incapsulamento. Probabilmente l'avvio su una lingua che consente o funzioni gratuite o classi statiche.

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

Nella programmazione non orientata agli oggetti, se si utilizzano tipi di dati separati per una Tree e una LinkedList, si dovrebbero usare metodi diversi per aggiungere un nodo a ciascuno. I linguaggi non orientati agli oggetti sarebbero generalmente squawk se si tentasse di denominare entrambi i metodi AddItem , poiché ogni nome dato può riferirsi solo a un metodo, portando quindi a creare nomi di metodi come AddTreeItem , AddLinkedListItem , RemoveTreeItem , ecc. Un simile approccio funziona, ma è un po 'brutto. Concettualmente, i metodi AddTreeItem e RemoveTreeItem sembrano appartenere insieme, ma i nomi non si ordinano in questo modo. Si potrebbero riscrivere i nomi come TreeAddItem , TreeRemoveItem , LinkedListAddItem , ecc. Ma ciò comporterebbe un sacco di "rumore ridondante" all'inizio di ogni chiamata di metodo. La stragrande maggioranza delle chiamate di metodo in un programma tipico avrà tre informazioni essenziali: (1) quale sezione del codice sorgente contiene il metodo; (2) quale dei metodi in sezione è in uso; (3) su quale pezzo di dati viene messo in atto? In molti casi, il tipo di dati su cui si baserà sarà sufficiente per identificare la sezione di codice a cui appartiene il metodo, quindi la parte (1) di cui sopra è ridondante. È più facile identificare visivamente il materiale all'inizio di un'affermazione che il materiale altrove, quindi uno stile di codifica / denominazione come TreeAddItem(myTree, whatever) finisce per mettere la parte meno utile dell'informazione al primo posto.

Al contrario, usando la programmazione orientata agli oggetti, si darebbe un nome ai metodi come Tree.AddItem , ecc. e un'istruzione come myTree.AddItem(whatever) farebbe dire un compilatore, in sostanza, "Hmm ... myTree è di digita Tree , quindi questo codice deve invocare Tree.AddItem() . Non è necessario specificare Tree. quando si chiama AddItem poiché il compilatore conosce il tipo di myTree . Concettualmente, un'istruzione come myTree.AddItem(whatever) equivale a Tree.AddItem(myTree, whatever) , e alcuni linguaggi orientati agli oggetti possono consentire entrambi i moduli come equivalenti, infatti la maggior parte delle lingue omette il primo parametro dalla specifica della funzione e invece ha metodi definiti in una classe come Tree implicitamente con un parametro di tipo Tree , e assegnagli un nome come this , self o Me .

I linguaggi di programmazione orientati agli oggetti spesso includono una varietà di funzionalità aggiuntive come ereditarietà, funzioni virtuali, ecc. che sono molto utili in molte applicazioni, ma anche senza quelle funzionalità la possibilità 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: definendo un'operazione insieme alla rappresentazione dei dati su cui lavora

• Rilegatura tardiva: scelta di una combinazione di rappresentazione e comportamento dei dati in fase di runtime

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

Questo è tutto. Come la qualsiasi tecnologia, nel suo cuore è semplicemente una comodità, dalla quale molti sviluppi hanno seguito in seguito. Una volta comprese le nozioni di base, il resto segue nel tempo.

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

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

Ti mostra persino la differenza tra una classe e un oggetto

Non fornirà approfondimenti sui 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, a mio parere, il modo migliore per spiegare l'orientamento degli oggetti con C ++ a un utente F77, sarebbe di procedere in modo graduale:

Per prima cosa, introduce l'utente al concetto di orientamento all'oggetto in un ambiente familiare mostrandole come sviluppare strutture simili a oggetti in Fortran 77 - per esempio, dai un'occhiata a documenti come B. Patton "Fortran orientato agli oggetti 77 (vista di un praticante) "SIGPLAN Fortran Forum 12, 2 (1993), pp. 23-24, e riferimenti in esso.

Quindi, stabilisci una corrispondenza tra queste strutture e le classi e i metodi C ++.

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

Quando ho iniziato a migrare a un linguaggio orientato agli oggetti dal mio addestramento iniziale in Pascal, il "." il problema è stato il più grande ostacolo anche per me. Mi ci sono voluti anni per superarlo.

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

• Che cosa significa per qualcosa che è fondamentalmente un puntatore, per avere un altro puntatore che punta ad esso, che si risolve in una cosa diversa del puntatore genitore?

Il momento aha per me è stato quando ho capito che il puntatore di livello superiore era fondamentalmente solo un namespace.

Suggerirei di farle scrivere una serie di codice che le richiede di assegnare un nome alle sue funzioni, idealmente senza usare la notazione a punti per iniziare. Poi falla provare a riscriverla usando la notazione a punti.

Facendo questo esercizio bisognerebbe scavalcare l'iniziale "Che stregoneria è questa?" ostacolare.

Sono passato dall'assembler e COBOL a Ruby.

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

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

Quindi, a questo punto, la classe può essere vista come un semplice punto di riferimento in cui inserire tutti i metodi correlati. Chiamala un contenitore o una libreria le sarà più familiare.

Ovviamente il codice deve essere segmentato per essere gestibile in modo da avere una di queste aree. Ad esempio, per gestire un insieme di programmi di utilità su un PC, potresti avere una classe di calcolatori in cui potresti inserire tutto il codice per una calcolatrice in un unico posto. Se hai solo 1 calcolatrice sul tuo PC, i metodi di livello di classe sono sufficienti.

Questo è un inizio.

ok ora considera il fatto che vuoi aprire più calcolatori e cambiare il modo in cui ognuno guarda e dove si trova sullo schermo. Quindi ora non puoi avere solo un metodo di calcolo 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 da ruby non c ++ quindi potrebbe essere necessario tradurre.

Un approfondimento chiave che mi ha aiutato a spiegare in precedenza è il fatto che è possibile avere più istanze di una classe. Cerca di spiegarlo in termini di "disegni" o "stampi" e "copie" e guarda se porta ovunque.