it-swarm.it

Come spiegare OOP concetti 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 xe y. Non sono anche bravo a spiegare le cose perché 1) Don ho tanta esperienza nel settore e 2) odio davvero spiegare cose a persone non tecniche.

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

10
John

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

Ad esempio, potrei dire che una classe chiamata Vehicle descrive 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 conducente. chiedo, 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 del 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 agli oggetti della vita reale, la maggior parte delle persone lo capisce sempre. In effetti, ho trovato nelle conversazioni con persone non tecniche cose a cui non avevo mai pensato. deve essere presidiato, ad esempio (droni), ma un programmatore avrebbe pensato all'operatore del veicolo come una sua proprietà? Non sto dicendo che sia giusto o sbagliato avere un operatore menzionato, ma ci fa pensare su ciò che stiamo modellando e ciò che stiamo cercando di ottenere quando sviluppiamo software.

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

27
Moo-Juice

Gli oggetti sono sostantivi, i metodi sono verbi.

14
k rey

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 - pensa 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 hanno bisogno di un modo per essere rappresentati, come le interazioni tra "cose", la categorizzazione delle cose, ecc. Prendi in considerazione 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 penso davvero che la persona non tecnica si preoccupi troppo della 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.

3
Tim Claason

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 da 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, si chiama polimorfismo.

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

1
gbjbaanb

Ho parlato di una conversazione che ho avuto con mia moglie proprio su questa cosa, in questa risposta qui: https://softwareengineering.stackexchange.com/questions/45464/how-to-convince-non-programmer-his- nozioni-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 "Che cosa significa Object Oriented?"

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 di Factory. Qualunque cosa. Illustra l'ereditarietà, l'incapsulamento, l'identità della classe di oggetti ... Roba buona.

1
Dan Ray

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 stato per la prima volta in OOP molti anni fa, ho scoperto che questi solo 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 ritiene che i programmatori siano idioti che non hanno bisogno di parlare in modo semplice (vedi l'ironia qui?) termini.

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, in realtà).

1
Jas

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. Gli oggetti modello dei 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?

0
zourtney

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 esempio: altezza, peso, colore, ecc.
  • Passaggio 2: elenca le funzioni di questo telefono generico ad esempio: effettua una chiamata, ricevi una chiamata, invia 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

0
Darknight

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.

0
jhocking

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 semplifichiamo la realtà in piccoli passi, "logica 2 + 2", categorie grezze, piccoli strumenti riutilizzabili e ragionamento preistorico.

Stiamo ancora cercando di capire come scaricare i nostri pensieri e desideri in un protocollo e 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.

0
Glyn

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 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. OOP Wizard 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, diciamo, un cameriere incazzato dell'unicorno e un troll floor manager) che devono lavorare tutti 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 sistemare 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 che chiamare gli incantesimi giusti non richieda più lavoro da parte della procedura guidata OOP. Ma il lavoro è molto più difficile da capire o duplicare e molto più difficile riutilizzare grandi porzioni perché è tutto legato per uno specifico problema complesso.

0
Erik Reppen

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

Essenzialmente OOD & OOP vuole 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 esattore di rifiuti su OOD & P. Si chiama Bob. Andavi a scuola con lui 15 anni fa, l'hai incontrato in un bar ed entrambi fingi interesse per le vite degli altri.

"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 rifiuti, giusto? Cosa fai, in genere nel tuo lavoro?"

"Beh, seguo il furgone in giro per la città a raccogliere spazzatura e metterla nel furgone", risponde Bob, interrogativamente.

"Eccellente. Beh, immagina di scrivere un programma per simularlo. Nella progettazione orientata agli oggetti il ​​primo passo è determinare quali oggetti ci sono. Nel tuo lavoro sembrano esserci strade, bidoni, tu e il furgone. Questi sono i nostri oggetti. Quindi dobbiamo sapere quali comportamenti compie ogni oggetto. Non sono sicuro di come funzioni nel mondo reale, ma supponiamo che ti venga detto delle strade che necessitano di pulizia. C'è un comportamento: le strade avvisano quando hanno bisogno di essere pulite Ciò significa che qualcosa deve essere in ascolto per le strade che hanno bisogno di essere sgomberate. Immagino che, dato che segui il furgone, il furgone ascolterà le strade che devono essere ripulite: sono due. Un terzo è, ovviamente, segui il furgone. se metti la spazzatura nel furgone. Individui anche se un bidone è pieno. Immagino che il furgone dovrà avvisarti quando è pieno e dovrai ascoltarlo. Questi sono i nostri comportamenti. necessità di progettazione La programmazione orientata agli oggetti è essenzialmente il modo in cui implementate ent il design. Differisce da una lingua all'altra ".

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

0
Matt Ellen