Qual è la "caratteristica killer" di OOP? [chiuso]

La funzionalità killer di OOP è il passaggio dei messaggi. Cioè, la capacità di parlare a qualcosa senza sapere o preoccuparsi, che cos'è esattamente o come funziona.

I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"

Alan Kay

Molti usano solo la parola "polimorfismo" per parlare a questo punto ma su cui si concentra la cosa ha molte forme e non la portabilità del messaggio.

Potrebbe sembrare un mucchio di sciocchezze. Il codice non interessa quello su cui ti concentri. Quindi diciamolo un po 'più formalmente.

The mechanism of polymorphism must not create a source code dependency from the caller to the callee.

Uncle Bob

OOP ti consente di ignorare ciò con cui stai parlando e insiste solo sul fatto che, qualunque esso sia, comprende il mini linguaggio che usi per parlarci. Lavorare in questo modo consente di erigere i firewall contro l'impatto del cambiamento. Puoi immergerti e rielaborare questo tipo di codice e non dover guardare un cambiamento nella scelta del design diffuso attraverso il codice base.

OOP non è un tipo di linguaggio. È uno stile di programmazione. Qualsiasi "linguaggio OOP" può essere sconfitto nelle mani di un programmatore procedurale. Molti linguaggi di uso generale, che non hanno mai sentito parlare di OOP, sono abbastanza flessibili da permetterti di usare OOP se ti ostini a farlo.

L'ereditarietà (una forma di polimorfismo) e l'incapsulamento (vero nascondiglio dello stato, non solo stupidi getter) esistono entrambi in "linguaggi non OOP" come C e possono essere trovati nel codice procedurale. Quindi mentre quelli sono strumenti carini, in realtà non sono strumenti unici per OOP.

No, l'unica cosa che è la caratteristica killer di OOP è la capacità di comunicare senza sapere con cosa stai parlando. Se cambia, perché dovrebbe interessarti? Continua a parlare.

Il polimorfismo, l'incapsulamento e l'ereditarietà sono i vantaggi tradizionali di OOP. Ovviamente possono essere eseguiti in lingue non OOP, ma sono facilitati nelle lingue progettate per questo.

Puoi fare "classi" in C , ma è doloroso farlo. Puoi creare funzioni polimorfiche nello schema , ma devi trovare una libreria esterna. È possibile ottenere gli effetti dei campi privati in JavaScript, ma è necessario capire chiusure, costruttori e this .

In un linguaggio più orientato agli oggetti come C # o Ruby, creare una classe è semplice come utilizzare la parola chiave class . L'incapsulamento è facile come usare private . Esistono strutture integrate per l'ereditarietà e puoi sapere che la spedizione dipende sempre e solo dalla prima variabile.

Diventando più soggettivo, trovo più facile organizzare il mio codice quando ho più livelli di raggruppamento. In C #, faccio una lezione per ogni gruppo di funzioni che fanno cose simili o manipolano lo stesso stato. Quindi posso creare uno spazio dei nomi per raggruppare le classi e progetti per raggruppare gli spazi dei nomi. E, posso far lamentare il compilatore se provo ad accedere a qualcosa nel posto sbagliato.

I moduli fanno qualcosa di simile per i linguaggi funzionali, ma spesso sono l'unico livello di raggruppamento. È possibile ricreare spazi dei nomi e classi con chiusure, ma di solito gli IDE non sono costruiti per questo. Rispetto alla scrittura di myObject. e guardando le opzioni di completamento automatico, aprire un file diverso per scavare attorno a chiusure annidate per trovare quello che voglio è un dolore. È anche peggio se non hai la fonte e devi fare affidamento sulla documentazione esterna.

In quasi tutti i linguaggi di programmazione moderni puoi realizzare le stesse cose. Posso emulare oggetti con chiusure ed emulare chiusure con oggetti. Ma trovo molto più bello leggere x => x + 1 e class File { read() { ... } write(value) { ... } rispetto a class AddOne { execute(x) { x + 1 } } o file = (method, arguments) => (if (method == 'read') ... else if (method == write) ...) .

Hai ragione sul fatto che il polimorfismo - è la caratteristica killer di OOP. Ma sebbene ci siano molti altri modi per ottenere il polimorfismo (ad esempio modelli, macro, passaggio di messaggi, ecc.), La programmazione orientata agli oggetti fornisce il polimorfismo in una forma accessibile dall'uomo.

Ricorda: la maggior parte dei programmatori sono umani e la loro capacità di ragionare è molto legata alla loro genealogia genetica e al modo in cui ci siamo evoluti. Pensare agli oggetti fisici è la base dell'astrazione (pensa a come i bambini imparano la matematica, contando sulle loro dita, contando le mele).

La programmazione centrata sull'oggetto (o la modellazione) sta modellando i dati come oggetti. Questo di per sé è estremamente utile (ed è alla base dei dati che nascondono le astrazioni e così via).

Ma il polimorfismo è la base di concetti come le interfacce ed è fondamentale per il modo in cui le persone ragionano sulla modularità (e così fondamentale per come costruiscono sistemi più grandi).

Ciò che rende OOP tick è la combinazione di modellazione centrata sull'oggetto (umana intuitiva), con polimorfismo: presentare il polimorfismo in un modo intuitivo già umano. Le persone hanno appena iniziato con le macchine mentali per trattare le classi di oggetti in modo uniforme (ad esempio evitando i grandi animali spaventosi).

My $ 0.02 ...

La funzionalità killer di OOP sta controllando l'accesso ai dati.

Il legame tra i dati e il codice utilizzato per manipolare tali dati fornisce la capacità di controllare il modo in cui tali dati vengono utilizzati e mutati in modo sicuro.

Lo stesso confronto può essere fatto con IRL:

• costruzione diretta di un edificio senza piano VS
• che consente a un architetto di redigere un "progetto" (= classe) e di far sì che i lavoratori edili lo costruiscano (= istanziazione e utilizzo, tutte le volte che è necessario)

OOP offre di più. Fondamentalmente, si raggruppano insieme i dati del dominio e si limita l'accesso (incapsulamento), lo si offre come una cianografia (classe) e si definisce il suo comportamento attraverso i metodi in modo da poter creare (istanziare) altrettanti "oggetti".

Se vuoi la scalabilità, hai bisogno di OOP. Non puoi costruire una città o un paese semplicemente andando avanti senza alcuna pianificazione. Devi mappare tutto, pianificarlo correttamente, inventare i progetti delle case che vuoi usare, forse anche riutilizzare alcuni buoni progetti di altri ingegneri, ...

Inoltre, puoi automatizzare il processo di costruzione in vari gradi attraverso l'astrazione: ci sono fabbriche che prendono progetti e sputano oggetti. Se vuoi creare un oggetto modell 3d, puoi farlo con le stampanti 3d. Questo è solo un piccolo esempio. Fornisci il progetto (dati 3d, la tua "classe") e la stampante lo porta all'esistenza. Puoi ristamparlo tutte le volte che desideri. Le persone possono prendere il tuo oggetto 3d (modello, classe) ed estenderlo (ereditarietà, polimorfismo) ... Tutte le estensioni sono dello stesso tipo, è del tuo modello 3d originale. Quindi, in una certa misura, possono essere trattati così.

Forse è un po 'troppo astratto ma immagina un altro caso: Progetta il "veicolo" più generico. Poi arriva Joe, prende il tuo progetto / progetto / classe, lo estende e lo chiama "macchina". Michelle fa qualcosa di simile e la chiama "bike".

Entrambi sono veicoli. Entrambi forniscono la funzionalità generale di un "veicolo" perché entrambi lo sono, lo estendono. Quindi puoi essere agnostico su che tipo di oggetto reale hai a che fare, trattarli semplicemente come "veicoli" e applicare la logica a loro che funziona con "veicoli". Non è necessario differenziare tra Car & Bike perché la logica di business che applichi non ti obbliga a farlo!

Una fabbrica di vernici per veicoli non si preoccupa se è un'auto o una bicicletta. Possono dipingere entrambi ... Tanti esempi!

Modifica Ci scusiamo per le escursioni, spero che tu abbia capito il punto!