Perché l'incapsulamento è considerato un principio primario in OOP?

Sono d'accordo, quelle descrizioni sono molto simili. Ma l'astrazione è l'idea di consolidare lo stato e la funzionalità in pacchetti significativi. L'incapsulamento riguarda la protezione che raggruppa in modo che un estraneo non possa entrare, infrangere le regole e fare casino con il tuo stato.

• L'astrazione ha un dominio esclusivo sullo stato e l'incapsulamento è il modo in cui lo garantiamo.

Un altro aspetto dell'incapsulamento è che l'implementazione potrebbe essere più complicata dell'astrazione. Quindi potresti avere un metodo (pseudocodice):

List<Thing> getRelatedThings()

ma internamente, la lista delle cose non è affatto rappresentata come una lista. Forse è un complicato pasticcio di strutture dati, da cui si astraggono una lista.

O forse è solo una lista di cose, ma vuoi essere in grado di cambiare idea in seguito. L'astrazione rimane la stessa, ma l'incapsulamento protegge l'implementazione.

• Quindi un'altra differenza potrebbe essere: l'astrazione si sforza di semplificare, ma l'incapsulamento nasconde la complicazione.

EDIT: un'altra cosa ... L'incapsulamento è un aspetto importante del disaccoppiamento. Quindi diciamo che ho due classi che sono veramente simili. Senza incapsulamento, queste astrazioni potrebbero iniziare a sovrapporsi e diventare sempre più intrecciate nel tempo. L'incapsulamento dice, no, questa astrazione è distinta da quella astrazione.

Se c'è un'astrazione comune, scartala e amplifica; astrarre una classe base.

(anche se ora hai due problemi;)) (... mi dispiace, questo è uno scherzo di "composizione di favore sull'ereditarietà". Se ciò non ha senso, ci arriverai.)

L'incapsulamento
• mantiene i confini di un'astrazione distinta

Sono d'accordo, l'incapsulamento è più un meccanismo che un principio. Lo stesso si può dire sull'ereditarietà dell'implementazione, che è un ( probabilmente pericoloso ) meccanismo per ottenere sottotitoli, che a sua volta è solo un tipo di polimorfismo . Onestamente, non considererei affatto l'ereditarietà un principio fondamentale di OOP - gli oggetti riguardano le interfacce, non gli alberi ereditari.

Su quella nota, dici "i quattro principi" come se ci fosse una fonte autorevole per loro; Non credo che ce ne sia uno. OOP significa molte cose per molte persone. Personalmente, trovo che i principi SOLID siano utili, ma comprendiamo che indipendentemente da quali sottoscrivi , sono solo un mezzo per un fine. Direi che nulla ha più importanza della correttezza, della modularità e della chiarezza, in questo ordine.

OOP è stato comunemente definito come incapsulamento, ereditarietà e polimorfismo. Ho visto questa definizione attorno a un lotto e ho visto solo alcune astrazioni, incapsulamenti, eredità e polimorfismo. Il processo di pensiero orientato agli oggetti di Matt Weisfeld riconosce la definizione delle 3 parti e aggiunge la composizione alla fine della lista.

Sebbene nessuno sia d'accordo su quale OO sia , ci sono molti definizioni .

Penso che quello che è successo è che l'incapsulamento / ereditarietà / polimorfismo è stato originariamente impostato come definizione di OO, quindi le persone hanno fatto riferimento ai singoli punti come principi, quindi le persone hanno smesso di riferirsi all'intera cosa come una definizione, e invece li definivano come un insieme di principi, quindi la gente notava che mentre l'ereditarietà è come il principio del polimorfismo è stato implementato in OOP, non c'era nessun principio elencato per corrispondere all'incapsulamento come un'implementazione, quindi lo aggiunsero. Poi hai notato che non tutti questi principi sono allo stesso livello di astrazione. Non ho alcuna prova che sia accaduto in questo ordine, ma sappiamo cosa erano l'inizio e l'endpoint.

Se prendi i 4 "principi" come una definizione, ma poi estrai l'incapsulamento e l'ereditarietà come implementazioni, ottieni l'astrazione + polimorfismo come una definizione di OOP, che è ridicolo, poiché molte lingue che non hanno oggetti in esse a tutti hanno entrambi.

Hai bisogno sia di un livello di astrazione che del principio di incapsulamento per pensare agli oggetti come le unità primarie nel sistema.

Prima di OO l'unità principale era costituita da funzioni che manipolavano i dati. Questo era di per sé un'astrazione al di sopra del codice macchina che era operazioni che agivano sui dati. Il principio dell'astrazione nel contesto di OO in pratica dice di smettere di pensare alle funzioni e iniziare a pensare a unità di comportamento raccolte come abbiamo nel mondo reale (che porta agli oggetti).

L'incapsulamento dice che queste unità di comportamento raccolto devono essere le uniche responsabili del proprio comportamento e devono impedire ad altre unità di comportamento di interferire con quello (che di nuovo porta agli oggetti).

Quindi hai davvero bisogno sia dell'astrazione che dell'incapsulamento per arrivare agli oggetti, dato che gli oggetti sono unità di comportamento distinte che si assumono la responsabilità del loro stesso comportamento.

È possibile immaginare un sistema in cui si hanno unità distinte di comportamento comune, ma che questi proto-oggetti non hanno alcuna restrizione sugli altri proto-oggetti che entrano e fanno confusione nel comportamento. In effetti, questo descrive il software OO mal progettato, pieno di getter e setter e metodi privati esposti.

Senza l'incapsulamento non hai "oggetti" come immaginavano persone come Kay, quindi l'astrazione alle unità di comportamento non è sufficiente.