Significa che OOP mi permette di avere alberi dati, di profondità e larghezza arbitrarie, con alcune foglie che sono funzioni (e quelle foglie sarebbero chiamate metodi)?
Perché tutto il resto che le persone spesso mettono vicino al marchio "OOP", semplicemente non sembrano avere nulla a che fare con esso. (L'ereditarietà, il polimorfismo del sottotipo e l'incapsulamento sembrano essere ortogonali a OOP).
Ho ragione? O mi manca qualcosa?
Is it fair to reduce OOP to mere hierarchical composition of data structures? Meaning that OOP allows me to have data-trees, of arbitrary depth and breadth, with some leafs being functions (and those leafs would be called methods) ?
Immagino che tu possa scegliere di guardarlo in questo modo, ma non credo che sia un modo particolarmente utile per guardarlo. Nello specifico, l'uso della parola "dati" (anche se specifichi esplicitamente funzioni in esso) sembra ridurre OOP a un modo di modellare i dati (o almeno, a un approccio incentrato sui dati). A mio avviso, manca il punto.
OOP è un modo particolare per strutturare il codice; sia il comportamento che i dati. Le sue idee principali sono la normalizzazione del comportamento (principio SECCO), al contrario, ad esempio, della normalizzazione dei dati (come nel concetto di DB relazionale) e concetti come l'incapsulamento. Nel modo più semplice, l'incapsulamento si ottiene fornendo un'interfaccia esterna alle classi (le tue cose pubbliche) e un'implementazione interna (materiale privato / protetto). Questo è molto diverso dalla programmazione modulare "tradizionale", poiché i confini del "modulo" sono strutturati in modo completamente diverso: nel caso di OO, ogni classe è un mini-modulo.
È anche importante notare che il concetto di incapsulamento, in senso generico, è molto diverso da una specifica implementazione dell'incapsulamento. OOP ha un modo specifico di eseguire l'incapsulamento, intrinsecamente (ovviamente, mi riferisco solo ai casi fondamentali qui, non ai pattern, ecc.). L'ereditarietà e il polimorfismo sono modi molto più specifici OOP per raggiungere altri principi (il riutilizzo del codice è uno di questi). Non sono sicuro che li inserirò nella stessa frase dell'incapsulamento, esistono ad un livello leggermente diverso.
OOP tende anche a mappare abbastanza bene su un dominio problematico, consentendo di modellare un problema in un modo che rimane comprensibile agli utenti semi-tecnici.
Che senso ha passare attraverso la discussione mini OOP di cui sopra? Quanto sopra è il meglio che posso fare per riassumere OOP in poche frasi: mette in evidenza i punti principali di OOP dal punto di vista di qualcuno che ha lavorato con la tecnologia per molto tempo. Non penso che ridurlo a una composizione gerarchica delle strutture dati sia giusto. Possiamo anche ridurlo a una serie di caratteri nei file di testo, ma ciò non significa che catturi l'essenza del paradigma.
Ti manca qualcosa. Probabilmente molti altri, in effetti.
Gli oggetti sono un potente mezzo di astrazione. Non si limitano a organizzare i dati, organizzano il codice. Si potrebbe sostenere che quell'astrazione non è necessaria, che si potrebbe produrre codice equivalente usando tecniche puramente procedurali, ma sarebbe come sostenere che i linguaggi di alto livello non sono necessari - è perfettamente possibile scrivere codice equivalente in linguaggio assembly. Tali argomenti possono essere tecnicamente veri, ma sono completamente falsi dal punto di vista pratico.
Qualsiasi linguaggio formale è riducibile ai grafici, ma il fatto che una lingua sia un grafico o un albero non è sufficiente per definire il tipo di linguaggio che hai.
Se stai provando a stabilire una lingua come OO, allora sì, è un grafico (possibilmente un albero se non c'è davvero alcuna eredità multipla) dove alcuni nodi sono funzioni, alcuni sono tipi di dati, ecc., ma il l'albero aderirà anche a determinate regole, come lo stato incapsulato, il polimorfismo e l'ereditarietà. In caso contrario, non è OOP.
Direi che ti manca che l'OOP sia strettamente collegato a OOA / D che riguarda la modellazione del dominio del problema in modo significativo e sostenibile. Ciò porta a considerazioni di accoppiamento, coesione, responsabilità, separazione delle preoccupazioni e, a sua volta, considerazioni di incapsulamento, composizione, ereditarietà ecc.
Leggi altre domande sui tag object-oriented definition paradigms