Come spiegare i concetti di OOP a una persona non tecnica?

Cerco spesso di evitare di dire alla gente che sono un programmatore perché la maggior parte delle volte finisco per spiegare loro cosa significa veramente. Quando dico loro che sto programmando in Java, spesso pongono domande generali sulla lingua e su come differisce da xey. Non sono anche bravo a spiegare le cose perché 1) Non ho molta esperienza nel settore e 2) Odio davvero spiegare le cose a persone non tecniche.

Dicono che capisci veramente le cose una volta che le hai spiegate a qualcun altro, in questo caso come spiegheresti la terminologia e i concetti di OOP a una persona non tecnica?

In genere cerco di descrivere la programmazione orientata agli oggetti usando esempi del mondo reale.

Ad esempio, potrei dire che una classe chiamata Vehicledescrive le cose minime che un veicolo è. Chiederò alla persona di dirmi cosa pensa che sia un veicolo. A volte dicono cose come "Beh, come un'auto o un camion", e annuisco e sono d'accordo con loro. Quindi chiederò quali sono le differenze tra un'auto e un camion. A volte menzionano le dimensioni, a volte lo scopo e altre cose.

Quindi chiederò loro di dimenticare un'auto o un camion e chiederò loro di continuare a descrivere un veicolo:

"Oh, beh si muove"

"Ha un operatore o un driver"

eccetera...

Presto, sappiamo cos'è un Veicolo e ho detto che in OOP avremmo definito un veicolo, e per amor di discussione dire che può muoversi e dargli un tipo di guidatore. Allora chiederò, ok, quindi cosa ha un'auto?

"Porte"

"Finestre"

E poi un camion ....

"Porte" "finestre" "Altre ruote!"

Presto, dopo molte discussioni, l'altra persona ha generalmente identificato:

1) Cosa costituisce un veicolo

2) Cosa costituisce un'auto

3) Cosa costituisce un camion

4) Cosa costituisce un aereo.

Tutto senza alcun tecnicismo. Abbiamo suddiviso le proprietà di ciascuno nelle aree giuste. Comprendono l'eredità ("Sì, un'auto è un veicolo, un camion è un veicolo, ma un'auto non è un camion, è SEMPLICE, duh!").

Capiscono persino il polimorfismo, "Certo, sostanzialmente fanno lo stesso, ma potrebbe farlo in modo leggermente diverso". Possiamo parlare di comportamento e di dove dovrebbe vivere nel nostro albero di oggetti.

A seconda della loro istruzione e del loro background, alcuni lo ottengono più velocemente di altri. Ma quando confronto OOP con oggetti della vita reale, la maggior parte delle persone lo capisce sempre. In effetti, nelle conversazioni con persone non tecniche ho trovato cose a cui non avevo mai pensato. I veicoli non devono essere presidiati, ad esempio (droni), ma un programmatore avrebbe considerato l'operatore del veicolo come una sua proprietà? Non sto dicendo che sia giusto o sbagliato far menzionare un operatore, ma ci induce a pensare a ciò che stiamo modellando e a ciò che stiamo cercando di ottenere quando sviluppiamo software.

Ora, la specializzazione parziale del modello, d'altra parte .... :)

Gli oggetti sono sostantivi, i metodi sono verbi.

Ecco una versione della mia risposta predefinita che do alla persona ultra non tecnica:

La programmazione è un tentativo di creare una rappresentazione della realtà sul computer. Esistono già molti strumenti e dispositivi che lo fanno già: pensate a come un foglio di calcolo ci rende più semplice rappresentare contabilità o statistiche o come una presentazione di Powerpoint ci consente di archiviare e visualizzare le nostre presentazioni.

A volte abbiamo bisogno di costruire rappresentazioni personalizzate della realtà in applicazioni nuove o esistenti che riflettono i nostri processi aziendali. Esistono molti modi per programmare e uno dei modi più comuni per programmare è la programmazione orientata agli oggetti, in cui il codice che costruiamo è specificamente progettato per replicare i concetti di realtà. Le "cose" in realtà hanno attributi e comportamenti. Ad esempio, un essere umano ha spesso braccia e gambe, colore dei capelli, etnia e spesso può parlare e camminare.

Parlare e camminare può venire in diverse varietà, come la lingua che si sta parlando o la velocità o il modo in cui si cammina.

Gli Esseri Umani hanno spesso interazioni con altri tipi di "cose", siano essi animali, altri umani, altri organismi viventi o oggetti inanimati. Esistono in realtà temi che spesso necessitano di un modo per essere rappresentati, come le interazioni tra "cose", la categorizzazione delle cose, ecc. Considera i processi aziendali che avvengono nella nostra organizzazione. Esiste una "logica commerciale" molto complicata che deve essere rappresentata nel software utilizzato dalla nostra organizzazione.

La programmazione orientata agli oggetti fornisce un mezzo per rappresentare accuratamente questi "concetti del mondo reale" e la "logica aziendale".

-> Questa affermazione è di solito sufficiente per evitare la loro curiosità (o forse li annoia fino alle lacrime), ma se hanno più domande, l'affermazione di cui sopra (credo) pone una base decente per dove può andare la conversazione. Non credo davvero che la persona non tecnica si interessi troppo alla terminologia tecnica come "Astrazione", "Composizione", "Polimorfismo", ecc., Ma se lo sono, il linguaggio che ho usato nella frase in scatola mi permette per estrarre esempi basati su di esso.

Ho sempre imparato OOP in questo modo:

Hai un orologio, e dice l'ora - beh, nella programmazione hai messo insieme tutto il codice e le cose che devi fare tutte insieme (sembra abbastanza ovvio, ma la gente non era solita fare così all'inizio). Comunque, si chiama incapsulamento .

Ora hai una cosa per l'orologio, potresti desiderare una sveglia - beh, una volta che hai tutte le cose insieme puoi aggiungere cose per farle fare di più - come impostare la sveglia e farla suonare. Questo si chiama eredità .

Inoltre, guardi l'orologio che ho al polso, ma puoi vedere altri orologi che sembrano diversi come un nonno o un orologio digitale. Sembra diverso, ma è ancora un orologio - beh, questo si chiama polimorfismo .

E lì hai i 3 angoli della programmazione orientata agli oggetti. Tutto il resto è solo codifica.

Direi loro di iscriversi a un corso in OOP se vogliono davvero capirlo.

Voglio dire, tutte quelle analogie come Car.startEngine (); siamo, ammettiamolo - puro rap. Quando sono entrato per la prima volta in OOP molti anni fa, ho scoperto che questi astraggono ulteriormente il dominio.

Invece di spiegare semplicemente che OOP riguarda la gestione della complessità dei linguaggi procedurali, quasi l'80% degli autori di libri di programmazione presume che i programmatori siano idioti senza senso che devono essere parlati in termini semplici (vedi l'ironia qui?).

Sì, è perfettamente normale andare alla spiegazione di Elenchi e vettori, perché è quello con cui lavoriamo principalmente, non Car.Engine e PoliceMan.Arrest (a meno che tu non sia uno sviluppatore di giochi, ma poi devi ancora avere la tua parte del ex).

Tornando all'argomento, vorrei solo dire loro, creo oggetti non tangibili che esistono puramente nella mente del programmatore, ai fini dell'elaborazione del libro paga / gioco / navigazione dello space shuttle, ecc.

Se hanno ancora domande, smetti di discuterne, perché non ne vale la pena. Molte persone non riescono a immaginare nozioni astratte e hanno bisogno di esempi praticamente per tutto (il che significa una maggiore semplificazione / specializzazione dell'argomento reale, davvero).

Ho parlato di una conversazione che ho avuto con mia moglie proprio su questa cosa, in questa risposta qui: /software/45464/how-to-convince-non-programmer-his-notions-about- computer-sono-sbagliato / 45467 # 45467

EDIT: La domanda a cui ho risposto lì è stata moderata, quindi riprenderò la mia risposta qui.

Seduta in un ristorante con mia moglie, mi ha chiesto "Cosa significa orientato agli oggetti?"

Ho iniziato a arrovellarmi per il riutilizzo del codice, l'incapsulamento e il polimorfismo, e ad un certo punto mi sono reso conto che i suoi occhi erano terminati.

Così ho preso un pacchetto Splenda dal contenitore. Dissi: "Ecco un oggetto. Quali sono le sue proprietà?"

Disse: "È rettangolare, è fatta di carta, contiene splenda, è blu, è stampata".

Ho preso un pacchetto di zucchero. "Che cosa ha in comune con questo?"

Ha detto: "La rettangolarità, la carta, che c'è la stampa".

Dissi: "Che ne dici che contengono entrambi qualcosa di dolce?"

Lei disse: "Sicuro".

Dissi: "Quindi questi sono entrambi casi di quello che potremmo definire un pacchetto di dolcificanti astratti. Un pacchetto di dolcificanti platonico ideale, se vuoi".

Lei disse: "Sicuro".

Dissi: "E ognuno ha proprietà ereditate dal pacchetto astratto, e quindi variazioni su ciò che sono specifiche per il suo tipo di cose".

Disse: "Giusto. Oh! E se volessi fare un pacchetto di Saccarina, prenderei quello generico e imposterò i dettagli per il Saccarina, e poi lo farei!"

Ho detto: "Bingo: programmazione orientata agli oggetti".

Tu ed io sappiamo che ha appena intuito la sua strada verso il modello di design Factory. Qualunque cosa. Illustra l'ereditarietà, l'incapsulamento, l'identità della classe di oggetti ... Roba buona.

Questa domanda sembra un candidato per essere chiuso, tuttavia ...

Come la maggior parte delle cose, OOP è in realtà molto semplice da spiegare a livello concettuale. Oggetti modello programmatori; e:

• gli oggetti hanno stato (campi / membri dati)
• gli oggetti hanno azioni (metodi / funzioni)
• oggetti costruiti l'uno sull'altro (eredità)

Queste sono centinaia di dettagli più fini, certo. Ma se stai solo cercando di dare a qualcuno una panoramica di 10 secondi, penso che sia un buon inizio. Ci sono concetti più specifici che hai difficoltà a spiegare?

L'esempio del telefono cellulare:

Immagina di essere il proprietario di una fabbrica, vuoi descrivere un telefono generico

• Passaggio 1: elenca le proprietà di questi telefoni generici , ad es. Altezza, peso, colore, ecc
• Passaggio 2: elencare le funzioni di questi telefoni generici , ad esempio: effettuare chiamate, ricevere chiamate, inviare sms ecc

Ora che hai il tuo "progetto" generico, creami i seguenti telefoni:

Telefono 1:

• Altezza-> 102mm

• Peso-> 85 g

• Colore-> Rosa

Telefono 2:

• Altezza-> 125mm

• Peso-> 96 g

• Colore-> Rosso

Penso che il modo migliore per spiegare a un tipo non tecnico di OOP sia collegarlo a loro.

In sostanza, OOD e OOP vogliono che tu pensi al sistema che stai progettando e implementando come un mondo di cose interattive.

Quindi, per amor di discussione (che non va mai bene su Internet), diciamo che stai spiegando a un raccoglitore di rifiuti su OOD & P. Si chiama Bob. Andavi a scuola con lui 15 anni fa, l'hai incontrato in un bar e fingi entrambi interesse nella vita dell'altro.

"Quindi, John, dici di essere un programmatore. Mio nipote è interessato a tutte queste sciocchezze. Continua a parlare di programmazione orientata agli oggetti o qualcosa del genere. Di che si tratta?" Nota che Bob è britannico dal modo in cui ha sbagliato l'ortografia.

"Bene, Bob," rispondi, facendo una smorfia orientata. "In realtà è abbastanza semplice. Raccogli i rifiuti, giusto? Cosa, in genere fai nel tuo lavoro?"

"Beh, seguo il furgone in giro per la città raccogliendo spazzatura e mettendola nel furgone", risponde Bob, interrogativamente.

e dovrai ascoltarlo. Questi sono i nostri comportamenti. Questo è essenzialmente tutto ciò che serve per il design. La programmazione orientata agli oggetti è essenzialmente il modo in cui implementate il design. Differisce da una lingua all'altra ".

Bob si è addormentato nella sua birra. Te ne vai.

Mi piace l'esempio dell'auto per spiegare l'eredità (tendo a usare animali piuttosto che veicoli ma è la stessa idea) ma per spiegare come funziona un programma orientato agli oggetti mi riferisco a un'analogia che una volta ho letto sul sito Web di Chris Crawford: il programma è come una burocrazia davvero efficiente. Tutti i diversi oggetti nel programma sono come i diversi dipartimenti di una burocrazia; ogni dipartimento ha i suoi compiti designati, ha input ben definiti (con chi parlare e con quali moduli compilare) e altri dipartimenti spesso non sanno molto di ciò che accade all'interno. Le risorse umane sono come una fabbrica astratta, l'IT è un singleton, ecc.

Ottenere un messaggio di errore perché hai digitato la cosa sbagliata in un programma per computer è esattamente come compilare il modulo sbagliato da inviare a un ufficio.

OOP è una grossolana semplificazione, qualsiasi cosa - un'astrazione - del processo di pensiero umano e della comprensione del mondo per proiettare la funzionalità in un "vuoto" digitale per imitare digitalmente i processi e le classificazioni familiari. Per molti aspetti, riguarda più il nostro stato linguistico primitivo di noi "che pensiamo più ai computer".

Se la programmazione imitasse la realtà o il pensiero umano sarebbe di natura molto più organica, caotica e aleatoria, anche laterale. Invece semplificiamo la realtà in piccoli passi, "logica 2 + 2", categorie rozze, piccoli strumenti riutilizzabili e ragionamento preistorico.

Stiamo ancora cercando di capire come scaricare i nostri pensieri e desideri in un protocollo e in un linguaggio comune e io per primo penso che gli storici un giorno saranno affascinati dalla sua sofisticata crudezza - come ora vediamo i geroglifici. Non è affatto "intelligente", evidenzia semplicemente come non possiamo spiegare facilmente come decidiamo o comprendiamo anche le cose più semplici. L'informatica è ancora al livello di evoluzione del pensiero "un cane è un cane perché non è un gatto" - è millenni dietro persino la lingua parlata di base.

Esistono due tipi di maghi. C'è l'uomo che fa accadere cose specifiche con parole magiche. Ha una parola per evocare il fuoco. Ha una parola per far apparire un pollo congelato dal nulla. E un'altra parola per creare una pentola di forza (preferisco la mia forza verde, luminosa e traslucida) piena di briosa bontà. Con la giusta applicazione delle sue parole può produrre un pollo fritto.

E poi c'è la procedura guidata OOP. Chi convoca semplicemente un diavoletto che sa come andare al supermercato, comprare un pollo (o ingredienti per qualsiasi altro cibo che vuoi che lui prepari), cucinarlo e servirti la cena. La procedura guidata OOP non deve dire al suo imp come farlo. Deve solo fargli sapere cosa vuole, che in questo caso è il pollo fritto. Non solo, il mago OOP può chiamare altri servitori per dire al suo imp-chef cosa fare.

Quindi, il ragazzo dell'incantesimo impressiona alle feste, ma il mago OOP è quello che vuoi quando inizierai un ristorante magico con un sacco di personaggi (come dire, un cameriere di unicorno incazzato e un manager del troll floor) che tutti lavorare insieme. Se provi a invocare ogni fase del problema di risoluzione del "ristorante", puoi facilmente aggrovigliarti nei dettagli ed è davvero facile commettere errori. Il mago OOP pre-addestra i suoi servi per risolvere i dettagli per lui in modo che possa concentrarsi sulla risoluzione del problema più grande facendo interagire la sua gente.

Per non parlare del fatto che è più facile riutilizzare il tuo chef-imp per il tuo problema con la mensa della scuola elementare, quindi è per separare tutta la spazzatura che potresti o non riutilizzare quando fai tutto un passo alla volta chiamando le parole e parole che chiamano altri insiemi di parole (che diventeranno più numerose poiché dovrai gestire una maggiore varietà di problemi).

Per essere onesti, con un'applicazione molto, molto attenta, la procedura guidata di incantesimo può fare tutto velocemente come la procedura guidata OOP. Può scomporre le cose nel modo giusto in modo tale che chiamare gli incantesimi giusti non richieda più lavoro da parte sua del mago OOP. Ma il lavoro è molto più difficile da capire o duplicare e molto più difficile da riutilizzare grandi porzioni perché è tutto legato per uno specifico problema complesso.