Nell'insegnare una prima lingua a qualcuno senza un background di programmazione sto avendo difficoltà a definire OOP nonostante il fatto che preferisco OOP, come posso definire OOP a qualcuno con poca (o zero) programmazione Esperienza?Definizione di OOP per un nuovo programmatore
Si potrebbe provare qualcosa di simile al seguente approccio, che ho modificato un po 'qui da un post su un forum ho fatto qualche tempo fa:
Il set di base di vocabolario per programmazione orientata agli oggetti è una classe, un metodo, e un parametro.
Una classe è un insieme di funzioni che collaborano per eseguire un'attività. Un'istanza di una classe è considerata un oggetto.
Un metodo si riferisce semplicemente a una funzione racchiusa in una classe.
Un parametro è una variabile che viene passata in una funzione che indica come agire o le informazioni da elaborare.
Se si fa un po 'di scavo, troverete una vasta gamma di informazioni sui modelli di progettazione. Alcuni di questi potrebbero essere utili da guardare, anche se dovrei fare attenzione a introdurli troppo all'inizio, perché possono essere schiaccianti. Ci sono due acronimi utili (e piuttosto abusati) che potresti tenere a mente quando cerchi di entrare in una mentalità OOP: DRY e KISS.
ASCIUTO è l'acronimo di Non ripetersi e significa solo quello. Se scrivi del codice, non dovresti dover ripetere più volte quel particolare codice. In termini pratici, significa pensare in modo più astratto e pianificare un po 'meglio all'inizio. Darò un esempio a breve.
KISS sta per Keep It Simple, Stupid e significa che dovresti provare a scrivere codice che raggiunge il suo obiettivo nel modo più semplice possibile. Più semplice significa meno possibilità di errori e manutenzione più semplice. Nel contesto di OOP, questo di solito significa assicurarsi che ogni metodo o funzione abbia un solo compito. Se si scopre che un metodo fa più di una cosa, in genere significa che può essere refactored in diversi metodi più piccoli, ciascuno dedicato a un'attività specifica.
Ora per un semplice esempio (qualcuno potrebbe essere in grado di venire con uno migliore, ma con me su di esso per ora):
Diciamo che è necessario programmare due forme diverse, una che i processi informazioni sulle auto e una che fa lo stesso per i camion.
Per le auto, ci vogliono registrare le seguenti informazioni:
Per i camion, abbiamo bisogno :
In programmazione procedurale, si dovrebbe scrivere il codice prima di elaborare la forma macchina e poi il codice per il forma di camion.
Con la programmazione orientata agli oggetti, si dovrebbe scrivere una classe base chiamata veicolo che registrerebbe le caratteristiche comuni di cui abbiamo bisogno sia per i camion che per le automobili. In questo caso, la classe di veicolo registrerà:
Faremo ognuna di queste caratteristiche in un metodo separato. Il metodo del colore, ad esempio, potrebbe assumere il colore del veicolo come parametro e fare qualcosa con esso, come memorizzarlo in un database.
Successivamente, creeremo altre due classi: camion e auto, entrambe erediteranno tutti i metodi della classe del veicolo e la estenderanno con metodi che sono unici per loro.
La classe di auto avrà un metodo chiamato numberOfDoors e la classe di autocarri avrà i metodi cabSize e towingCapacity.
Ok, supponiamo di avere un esempio funzionante sia per la programmazione procedurale che per la programmazione OO. Ora, analizziamo alcuni scenari.
Scenario 1: Supponiamo che abbiamo improvvisamente bisogno di aggiungere un modulo di bus, che registra le seguenti informazioni:
Procedurale: È necessario ricreare l'intero modulo, ripetendo il codice per Colore, Dimensione motore e Tipo di trasmissione.
OOP: estendiamo semplicemente la classe del veicolo con una classe di bus e aggiungiamo il metodo numberOfPassengers.
Scenario 2: invece di memorizzare il colore in un database come in precedenza, per qualche strana ragione il nostro cliente desidera il colore inviato a lui.
Procedurale: Modifichiamo tre diverse forme: automobili, camion e bus per inviare via email il colore al client anziché memorizzarlo nel database.
OOP: cambiamo il metodo di colore nella classe del veicolo e perché le auto, camion, autobus e le classi tutto estendere (o ereditare da, per dirla in altro modo) la classe di veicolo, essi vengono aggiornati automaticamente.
Scenario 3: Vogliamo passare da un'auto generica a marche specifiche, ad esempio: Nissan e Mazda.
Procedurale: Creiamo un nuovo modulo per ogni marca, ripetendo tutto il codice per informazioni generiche sull'auto e aggiungendo il codice specifico per ogni marca.
OOP: estendiamo la classe dell'auto con una classe Nissan e una classe Mazda e aggiungiamo metodi per ciascuna serie di informazioni univoche per quella marca di automobili.
Scenario 4: Abbiamo trovato un bug nell'area del tipo di trasmissione del nostro modulo e abbiamo bisogno di ripararlo.
Procedurale: Apriamo e aggiorniamo ogni modulo.
OOP: Correggiamo il metodo transmissionType nella classe del veicolo e il cambiamento si perpetua in ogni classe che ne eredita.
Come si può vedere dagli scenari precedenti, l'utilizzo di uno stile OOP presenta notevoli vantaggi rispetto alla programmazione procedurale, in particolare all'aumentare della scala. Considera i risparmi che riceveremo da OOP in termini di codice ripetuto, flessibilità e manutenzione se dovessimo aggiungere moduli per imbarcazioni, motocicli, aerei, go-kart, ATV, motoslitte, ecc.
Oggetti e metodi sono anche molto più facile da testare rispetto alla programmazione procedurale utilizzando il test unitario per testare i risultati.
Ciò significa che non si dovrebbe mai usare la programmazione procedurale? Non necessariamente. Se stai facendo un prototipo o un'app di proof-of-concept, potresti non avere il tempo di rendere tutto orientato agli oggetti e quindi penso che sarebbe meglio usare la programmazione procedurale per un prototipo, ma sarebbe meglio per rendere il prodotto di produzione in modalità OO.
A mio parere, è un po 'troppo formale per un principiante ... ma è ben scritto ;-) –
Rileggendo la domanda, penso che tu abbia ragione. Probabilmente sarebbe utile se avessero almeno una * piccola * esperienza di programmazione. La domanda che questo ha risposto sul forum riguardava gli stili procedurali e OOP, quindi potrebbe non essere una misura esatta ... – VirtuosiMedia
Tuttavia posso riempire i prerequisiti necessari per capire questo, prima che dovessi usarlo. – UnkwnTech
Per quanto ne so, la programmazione orientata agli oggetti in origine significa che organizzi tutti i concetti del tuo programma in oggetti e poi definisci tutto il flusso logico come messaggi tra questi oggetti. Penso che per capire l'intento originale, devi imparare Smalltalk.
Ottima risposta. Un piccolo suggerimento: IMO, il Sé in realtà sarebbe anche meglio di Smalltalk per insegnare la programmazione OO, perché Self * realmente * ha solo oggetti e messaggi - nessuna variabile, nessuna costante, nessuna classe. –
Bene, dovresti usare degli esempi. Un esempio che la maggior parte della gente capisce è nei videogiochi di riferimento. Quindi, hai oggetti mostruosi e mostri hanno determinati attributi come colore, dimensione, forma, numero di braccia e così via. Quindi alcuni mostri hanno diverse "abilità" come respirare il respiro, sparare con le pistole, così via e così via. Questi sono esempi stupidi ma facili da capire. Penso che sia più facile spiegare a un novizio che tutto questo business su "quadrati", "cerchi" e così via.
Non sono d'accordo sul fatto che esiste una diffusa percezione errata secondo cui "oggetto" significa "cosa si può vedere sullo schermo" (di solito pulsanti, caselle di testo, ecc.) E utilizzare i mostri dei videogiochi (che sono visibili sullo schermo) in quello –
Sono d'accordo che questo tipo di discussione diventa molto interessante per i giovani. Intendo usarlo per le mie future lezioni. –
Beh, l'ho visto usato molto e non ha davvero avuto il problema di confondere oggetti con cose visibili. Penso che i pro superino gli svantaggi. Non è molto utile passare a oggetti concettuali/astratti/non visibili. Penso che sia più facile da capire che abbia visto il successo in classe. – BobbyShaftoe
Vorrei spiegarlo come un modo per modellare le informazioni del mondo reale. C'è un'analogia comune usando auto e veicoli per mostrare la gerarchia di tipi. Penso che sia abbastanza semplice da capire per la maggior parte delle persone, se lo spieghi correttamente.
Forse dovresti iniziare spiegando i tipi primitivi, quindi parlare di tipi compositi come le strutture, quindi mostrare come tali tipi possono essere correlati come classi usando l'ereditarietà.
Modifica: Dopo aver riflettuto su questo, l'esempio degli animali è molto meglio. Vedi Explaining OOP without Mentioning Classes e this SO thread sullo stesso argomento.
Non perdere tempo a "definire" OOP.
Basta usare un linguaggio OOP per tutti i tuoi esempi.
Gli oggetti sono banali. Il mondo reale è pieno di oggetti.
Non "definire" oggetti. Basta mostrare esempi di programmazione, l''oggettività' sarà ovvia.
Le persone senza un background di programmazione non hanno aspettative sciocche basate sulla programmazione procedurale.
Le persone che hanno imparato COBOL o Basic avranno problemi.
Parti di questo dipendono dalla lingua. Alcune lingue rendono difficile l'OOP.
Ad esempio, in C++, la "classe" è solo di definizione. Non esiste come oggetto discreto in fase di esecuzione.
In Java e C++, alcune cose sono oggetti, ma alcuni tipi "primitivi" non sono oggetti.
Alcune lingue semplificano l'OOP.
Python e Smalltalk tutto è un oggetto. Non ci sono tipi primitivi per infangare le acque. Quando impari OO in una lingua come Python, l'oggettività è chiara ed evidente perché pervade tutto. Proprio come il mondo reale, dove gli oggetti sono ovunque.
Se gli oggetti sono banali; allora perché così tanti sviluppatori sono così cattivi nella scelta di oggetti buoni? In molti casi, non sono nemmeno oggetti. – Dunk
@Dunk: perché molti programmatori hanno imparato prima la programmazione procedurale: VB o C o alcuni di questi. –
Non sono sicuro che gli oggetti siano banali, ma penso che tu abbia l'idea giusta. Non definirlo, fallo e basta. Presentalo come il modo in cui il codice dovrebbe essere scritto. Poi torna più tardi e spiega cosa stavi facendo da sempre (e altri paradigmi disponibili). –
Chiunque tu stia spiegando questo deve sapere cos'è la programmazione di base prima di poter imparare cosa significa OOP, in quanto è una branca dei linguaggi di programmazione. Non può mai capire cosa rende speciale OOP se non conosce le sue controparti. Quindi la tua domanda ha due parti; come spiegare cos'è un linguaggio di programmazione e cosa separa l'OOP da altri linguaggi di programmazione.
Il modo più semplice per spiegargli cos'è la programmazione in generale è confrontarlo con le operazioni matematiche. Puoi spiegarlo definendo la programmazione come un numero di espressioni matematiche che prendono un input che risulta in un output. Quanto tempo desideri elaborare dipende da te.
Con questa spiegazione abbiamo fatto il lavoro di base per fargli capire cosa significa OOP. Ora possiamo definire gli oggetti come insiemi di funzioni e dati matematici. Quindi, invece di trattare la logica come pezzi di codice globali, raccogliamo questi pezzi di codice all'interno di oggetti per raccogliere pezzi di codice rilevanti e ottenere un modo per isolarli. Da questo punto in poi puoi spiegare più vantaggi che derivano dall'astrazione dell'oggetto (ad esempio polimorfismo, accoppiamento libero).
È definito più accuratamente come una raccolta di funzioni e dati. Ogni funzione prende l'oggetto e gli altri parametri. Altrimenti non è una funzione, a causa di potenziali cambiamenti di stato. Mi ricorda di Python. Sfortunatamente, questo non è molto utile per dire come devono essere usati gli oggetti. –
Diciamo che si desidera descrivere una famiglia di oggetti che condividono tutti gli stessi attributi, ma potrebbero avere nomi, colori o altre differenze estetiche.
Ad esempio, si desidera descrivere i veicoli che una famiglia ha nel garage.Vi sono attributi di ciascun veicolo di vostro interesse:
In questo caso, si potrebbe avere un set di due veicoli, in modo tale che il seguente è vera:
Vehicle A's Model is a Toyota.
Vehicle A's Year is 2001.
Vehicle A has four Wheels
Vehicle A is driven by Mom, Dad, and Junior
Vehicle B is a Moto Guzzi
Vehicle B was made in 2004
Vehicle B has two wheels
Vehicle B is driven by Dad
in varie lingue, si potrebbe molto grossolanamente riferimento i due esempi nel seguente modo equivalente :
A = new Vehicle();
A.model = "Toyota";
A.year = 2002;
A.wheelCount = 4;
A.drivers = [ "Mom", "Dad", "Junior" ];
B = new Vehicle();
B.model = "Moto Guzzi";
B.year = 2004;
B.wheelCount = 2;
B.drivers = [ "Dad" ];
In programmazione orientata agli oggetti, si sta incapsulando gli attributi di questi veicoli, in modo che li si può descrivere con le loro caratteristiche. Il tuo compito è scrivere codice per ottenere e impostare i valori di queste funzioni (oltre a fare altre cose interessanti con queste funzionalità).
Inoltre, è possibile "sottoclasse", che è un modo per riutilizzare un oggetto in diversi contesti. Ad esempio, è possibile utilizzare i tipi di oggetto di veicoli più specifici, come ad esempio auto e moto, che ereditano le caratteristiche dalla descrizione di veicolo:
A = new Car();
B = new Motorcycle();
auto e moto oggetti sono descrizioni più specifiche di un veicolo. Queste due sottoclassi possono avere i propri attributi speciali. Una macchina potrebbe avere serrature a prova di bambino, mentre una moto in genere non avrebbe tale bisogno di una cosa.
Invece di impostare l'attributo Childproof Lock di un veicolo, si può dire che solo un'Auto ha un attributo Lock. Ciò rende la tua descrizione del veicolo più pulita e più facile da scrivere e mantenere.
Uso l'esempio di "palle rimbalzanti". Immagina di avere una scatola con una palla rimbalzante al suo interno.
si può programmare in 2 modi:
Un modo è quello di eseguire un ciclo, tenere traccia della posizione corrente della palla, calcolare la posizione successiva, verificare la presenza di collisioni, cancella dalla posizione corrente, disegnare nella nuova posizione. ripetere.
L'altro modo è lasciare che la palla tenga traccia della propria posizione e orientamento e insegnare a calcolare la posizione successiva e come spostarsi lì e come gestire le collisioni. Quindi, esegui il ciclo e informa la palla di continuare a aggiornarsi.
Ora immagina di avere 100 palle. Poi ci sono palle pesanti e palle di luce e palle che esplodono. Queste sono palle base con caratteristiche aggiunte. Useresti ancora il metodo 1?
Questa è una descrizione eccellente. Molto bene. –
Object Oriented Programming in laico parla:
La cosa si occupa di regolare le sue proprietà solo quando si chiede a (chiama un metodo). Non è possibile esaminare o modificare direttamente le proprietà di delle cose delle cose. Puoi solo esaminare o modificare le proprietà cosa ti consente di vedere. Pertanto, cosa può garantire le proprietà vengono visualizzate e modificate correttamente.
Questo impedisce al programmatore di dire cosa sua dimensioni è rosso. Se dici direttamente che la cosa rende rossa la sua dimensione dovrebbe rifiutarla (il rosso non è una taglia valida). Additonalmente, consente alle cose di gestire gli effetti collaterali del cambiamento delle sue proprietà.
Supponiamo di cosaoriginalSize è grande. Se Ho solo cambiare di cosadimensioni a piccolo, ho deve ricordare di dire a cosa che non è più la sua originalSize. Se io chiedo cosa per modificarne la dimensione a piccola cambierà le sue dimensioni per piccole e cambiare l'originalSize false. Ora, quando chiedo se è il suo originale Dimensione, risponderà con un no.
In sostanza, questo consente di impacchettare i dati e le funzioni insieme rendendo le cose più modulari/compartimentati. Ciò consente di organizzare meglio il codice e riutilizzare più facilmente il codice. OOP non è niente di speciale, solo un modo per organizzare al meglio il tuo codice. Non critico a livello di principianti, ma fondamentale per i progetti più grandi. All'interno delle funzioni di un oggetto, le cose generalmente diventano più procedurali come un principiante è abituato.
Qualsiasi spiegazione di OOP dipende fortemente dall'interpretazione dell'idea del concetto. La mia interpretazione del concetto è qualcosa di simile.
Il mondo reale è in gran parte inteso come un insieme di attori. Ogni attore ha una collezione di proprietà e comportamenti. Nella maggior parte dei casi, le proprietà di un attore sono espresse in termini di comportamenti, in relazione alla sua interazione con altri attori.
Un programma per computer è in genere una simulazione di alcuni processi del mondo reale, quindi di solito aiuta il programmatore a creare il programma basato su un modello di proprietà degli attori-comportamenti. Cioè, ogni elemento dell'intero programma può essere suddiviso in programmi più piccoli che rappresentano singoli attori.
Ovviamente si può solo arrivare così lontano. Non tutto quello che vogliamo modellare è un singolo attore. Ad esempio, la valuta è conservata, ma in molti modi infinitamente separabili.
Inoltre, altri modi di modellare il mondo reale possono offrire garanzie di correttezza più rigorose a costo di una maggiore astrazione, come un modello relazionale, che deriva dalla teoria degli insiemi. OOP non ha fondamenti matematici del genere.
È strano. Stai chiedendo di insegnare OOP a persone che non sanno nulla di PROGRAMMAZIONE e tutti stanno rispondendo "Come insegnare OOP?"
La risposta è, non è così. Come insegni la programmazione funzionale a qualcuno che non ha mai programmato? Non lo fai. Hai funzioni, il codice è stipato in loro, vengono riutilizzati, ecc. In Java, tutto il codice deve essere in una classe. Cos'è una classe? È, prima di tutto, un posto dove mettere il tuo codice. I programmi iniziano con il metodo Main. In seguito, puoi istanziarlo e ogni classe ha i suoi metodi e proprietà. E poi parli di metodi e variabili statici. E poi qualche volta dopo parli di polimorfismo ed eredità. A volte iniziano a progettare le proprie API e utilizzano servlet e classi persistenti o qualsiasi altra cosa da implementare (snervlets? IHibernate?)
Ma se non hai mai visto la programmazione prima, non è necessario sedersi e avere la grande chat OOP. Questo è necessario solo se stai salvando qualcuno da una programmazione non OOP. Insegna semplicemente programmazione. Programmazione OOP? C'è qualche altro tipo? Sì, ma oggi non lo stiamo insegnando, quindi non preoccupiamoci.
[Per analogia: quando si va a un corso di arti marziali, di solito non spendono molto tempo a spiegare. Prima ti stiracchi, ti fanno allenare e poi ti insegnano alcune tecniche. Se sei interessato a capire quale arte marziale stai studiando, vai in biblioteca.]
Pensando troppo al problema, ovviamente le basi verranno insegnate per prime. – UnkwnTech
Ok, buona fortuna. –
Una squadra sportiva. I giocatori del campo/campo in qualsiasi momento possono essere specificati in termini di posizioni che giocano. Tuttavia l'intera squadra può avere più membri che possono giocare in una determinata posizione.
Ogni posizione è come una classe in OO; specifica una serie di responsabilità. I membri del team sono esempi di queste classi.
I giochi nel playbook sono schemi. Ognuno specifica come ottenere un risultato specifico attraverso le interazioni di (istanze di) posizioni (classi).
Ecco una semplice definizione.
Gun gun = new Gun(new Bullet);
gun.Aim = Appendage.Foot;
gun.PullTrigger();
;)
gun.AimAt, gente comune! – mannicken
Un oggetto è una solo una cosa con un gruppo di proprietà denominate. I valori di queste proprietà definiscono lo stato di un oggetto. L'interazione tra gli oggetti viene effettuata tramite il messaggio che passa. Un messaggio è composto da un nome e un gruppo di parametri. Quando un oggetto riceve un messaggio, il messaggio viene elaborato dall'oggetto. L'elaborazione di un messaggio può comportare una modifica dello stato dell'oggetto e dei messaggi inviati a ulteriori oggetti.
è facile come la torta scritta all'indietro. i 3 principi fondamentali della oo sono:
incapsulamento eredità polimorfismo
mostrano il newbie il codice per il sorteggio standard di forme esempio che si trova nella maggior parte dei libri di programmazione oo. mostra anche loro il codice non-oo usando molti switch con dati globali.
dovrebbero avere un'idea di oo in base alle differenze organizzative tra i due insiemi di codice.
duplicato: http://stackoverflow.com/questions/355796/how-do-you-explain-oo-to-new-programmers – hasen
@hasen j - Non l'avevo visto, ma questo ha delle buone risposte . – UnkwnTech
** Vedere anche: ** "Confronto Jargon gratuito di OOP vs Procedural": http://stackoverflow.com/questions/1530868 – dreftymac