È la forza di progettazione OO nella semantica o incapsulamento?

Question

progettazione orientata agli oggetti (OOD) combina i dati e dei suoi metodi. Questo, per quanto posso vedere, realizza due grandi cose: fornisce l'incapsulamento (quindi non mi importa quali dati v'è, solo come ottenere i valori che voglio) e la semantica (si riferisce i dati insieme con i nomi, e la sua metodi costantemente utilizzano i dati come previsto inizialmente).

Così dove si trovano la forza di OOD? In constrast, programmazione funzionale attribuisce la ricchezza ai verbi anziché sostantivi, e quindi entrambi incapsulamento e semantica sono trasmessi dai metodi piuttosto che le strutture di dati.

lavoro con un sistema che si trova all'estremità funzionale dello spettro, e continuamente lungo per la semantica e incapsulamento di OO. Ma vedo che l'incapsulamento di OO può essere un ostacolo per prolunga flessibile di un oggetto. Quindi in questo momento, posso vedere la semantica come punto di forza maggiore.

O è l'incapsulamento la chiave di tutto il codice vale la pena?

Edit: mi riferisco in particolare il tipo di incapsulamento OO fornisce qui. changeColor(door,blue) diventa door.changeColor(blue).

Answer 1

Sembra che tu stia utilizzando una definizione piuttosto stretta di “incapsulamento”. Sarei proprio nel presumendo che si definisce l'incapsulamento di essere, “Combinando i dati con i metodi?”

Se mi sbaglio, allora si prega di ignorare il resto di questo post.

L'incapsulamento non è un termine sciolto; in realtà, è definito dalla International Organization for Standardization. Modello di riferimento della ISO Open elaborazione distribuita - definisce i seguenti cinque concetti:

Entità:. Qualsiasi calcestruzzo o cosa astratta di interesse

Oggetto: Un modello di un'entità. Un oggetto è caratterizzato da un comportamento e, dualmente, dal suo stato.

Comportamento (di un oggetto):. Una collezione di azioni con una serie di vincoli su cui possono verificarsi

Interfaccia:. Un'astrazione del comportamento di un oggetto che consiste di un sottoinsieme delle interazioni di quell'oggetto insieme con una serie di vincoli in cui possono verificarsi

Encapsulation:. La proprietà che le informazioni contenute in un oggetto è accessibile solo attraverso le interazioni alle interfacce supportati dall'oggetto

Possiamo fare ulteriormente una proposta per sé evidente: alcuni informazioni sono accessibili tramite queste interfacce, alcune informazioni devono essere nascosta e inaccessibile all'interno dell'oggetto. La proprietà di tali oggetti esposti informazione è chiamata information hiding, che Parnas definito sostenendo che i moduli devono essere progettati per nascondere entrambe le decisioni difficili e decisioni che potrebbero cambiare, vedere uno dei grandi giornali di calcolo:

http://www.cs.umd.edu/ classe / spring2003 / cmsc838p / design / criteria.pdf

E 'importante notare che non è solo i dati che sono informazioni-nascosto:. Si tratta di qualche sottoinsieme di comportamento associato con l'oggetto che è difficile o destinata a cambiare

Nel tuo post, ti sembra voler dire che la differenza tra incapsulamento in OO e nella programmazione funzionale deriva dalla gestione dei dati, ma almeno secondo la norma ISO e Parnas, la gestione dei dati non è la chiave per l'incapsulamento. Quindi non vedo il motivo per cui l'incapsulamento nella programmazione funzionale deve essere diverso da quello in OO.

Si parla, inoltre, nel tuo post che la programmazione funzionale fornisce l'incapsulamento, “... con i metodi piuttosto che le strutture di dati.” Questo, credo, è una differenza di scala piuttosto che di assoluta. Se uso la parola, “Oggetto”, piuttosto che, “struttura dati” (ancora una volta, per favore fatemelo sapere se sto interpretando male), poi ti sembra di trovare significato nella incapsulamento di OO per oggetto e l'incapsulamento della programmazione funzionale con il metodo.

Eppure, la definizione ISO di cui sopra, un oggetto è qualcosa che voglio modellare. Così classi possono essere incapsulati all'interno di un pacchetto, fintanto che alcune di queste classi contribuiscono alla interfaccia del pacchetto (vale a dire, le classi pubbliche del pacchetto) e alcuni sono informazioni-nascoste (le classi private nella confezione).

Per lo stesso motivo, i metodi sono incapsulati all'interno di una classe - alcuni metodi di essere pubblico e alcuni privati. Si può anche prendere questa una tacca più bassa e dire che McCabian sequenze sequenziali di codice sono incapsulati all'interno dei metodi. Ogni forma un grafo di nodi incapsulati all'interno delle regioni incapsulati; e tutti questi grafici formano una pila grafico. Così programmazione funzionale può ben incapsulata a livello di funzione / file, ma questo non è diverso dal grafico metodo / classe di OO, e sostanzialmente nessuna differenza dal grafico classe / pacchetto di OO sia.

Si noti inoltre che la parola Parnas utilizza sopra: il cambiamento. Informazioni nascondiglio riguarda potenziali eventi, come ad esempio il cambio di decisioni di progettazione difficile in futuro. Si chiede dove la menzogna di forza di OO; bene, l'incapsulamento è certamente un punto di forza di OO, ma la domanda diventa allora: “Da dove viene la forza bugia di incapsulamento?” e la risposta è una sola di chiarezza clamoroso: chagestione ESN. In particolare, l'incapsulamento riduce il carico massimo potenziale di cambiamento.

Il concetto di “attacco potenziale,” è utile qui.

“accoppiamento”, si è definito come “Una misura della forza di associazione costituita da una connessione da un modulo all'altro,” in un altro dei grandi fogli di calcolo:

http://www.research.ibm.com/journal/ sj / 382 / stevens.pdf

E come dice il giornale, in parole mai dal migliorato, “Minimizzare connessioni tra i moduli minimizza anche i percorsi lungo i quali cambiamenti ed errori si propagano in altre parti del sistema, eliminando così disastroso,‘ripple’effetti, dove variazioni uno errori parte causa in un altro, che necessitano di ulteriori modifiche altrove, che danno luogo a nuovi errori, ecc “.

Come definito qui, tuttavia, ci sono due limitazioni che possono essere facilmente sollevati. In primo luogo, l'accoppiamento non misura connessioni intra-moduli, e queste connessioni intra-modulo può dare luogo ad altrettanti “ripple” effetti come connessioni tra i moduli (la carta non definisce, “coesione” relazionarsi intra-modulo elementi, ma questo non è definita in termini di connessioni tra elementi (cioè, i riferimenti alle etichette o indirizzi) con cui è stato definito accoppiamento). In secondo luogo, l'accoppiamento di un qualsiasi programma di computer è un dato, in quanto i moduli sono collegati o; v'è poco spazio nella definizione di accoppiamento per gestire i potenziali variazioni dei quali Parnas parla.

Entrambi questi problemi sono risolti, in una certa misura, con il concetto di accoppiamento potenziale: il numero massimo di connessioni formabili tra tutti gli elementi di un programma. In Java, per esempio, una classe che è pacchetto-privato (la funzione di accesso predefinita) di un pacchetto non possono avere connessioni formata su esso (cioè, non classi esterne possono dipendere da essa, riflessione benché), ma una classe pubblica all'interno di un pacchetto può avere dipendenze su di esso. Questa classe pubblico contribuirebbe al potenziale di accoppiamento, anche se non ci sono altre classi dipendono da esso al momento -. Classi potrebbero dipendere da esso in futuro, quando le modifiche di progettazione

Per vedere la forza di incapsulamento, considerare il principio di Burden. Il principio dell'onere assume due forme.

La forma forte afferma che l'onere di trasformare un insieme di entità è una funzione del numero di enti trasformati. La forma debole afferma che l'onere massimo potenziale di trasformare un insieme di entità è una funzione del numero massimo di enti trasformati.

L'onere di creare o modificare un sistema software è una funzione del numero di classi creati o modificati (qui usiamo, “Classi” presumendo un sistema OO, e occupiamo di incapsulamento a livello di classe / pacchetto; abbiamo si potrebbe anche noi stessi hanno riguardato il livello di funzione / lima di programmazione funzionale). (Si noti che il “Burden”, è lo sviluppo del software moderno è di solito costo, o il tempo, o entrambi.) Le classi che dipendono da una particolare classe, modificato hanno una maggiore probabilità di essere influenzato di classi che non dipendono dalla classe modificata.

L'onere potenziale massimo una classe modificato può imporre è l'impattante di tutte le classi che dipendono da esso.

Ridurre le dipendenze su una classe modificata riduce quindi la probabilità che il suo aggiornamento urterà altre classi e quindi riduce il carico massimo potenziale che tale classe può imporre. (Questo è poco più di una riaffermazione della “progettazione strutturata,” carta).

La riduzione del numero massimo di dipendenze tra tutte le classi in un sistema riduce quindi la probabilità che un impatto ad una particolare classe causerà aggiornamenti altre classi, e riduce così il carico massimo potenziale di tutti gli aggiornamenti.

incapsulamento, riducendo il numero massimo di DEPEndencies tra tutte le classi, mitiga quindi la forma debole del principio dell'onere. Questo è tutto coperto da, “teoria Encapsulation”, che tenta di dimostrare matematicamente tali affermazioni, utilizzando accoppiamento potenziale come i mezzi logici di strutturare un programma.

Si noti, tuttavia, che quando si chiede, “? E 'incapsulamento la chiave di tutto il codice utile” la risposta deve sicuramente essere: no. Non c'è una sola chiave per tutto il codice utile. L'incapsulamento è, in determinate circostanze, solo uno strumento per contribuire a migliorare la qualità del codice in modo che possa diventare, “vale la pena.”

È inoltre scrive che, “... l'incapsulamento può essere un ostacolo per prolunga flessibile di un oggetto.” Sì, è certamente possibile: si è infatti stato progettato per essere una barriera contro l'estensione delle decisioni di progettazione di un oggetto che sono difficili o probabile cambiare. Questo non è, tuttavia, pensa che sia una cosa negativa. Un approccio alternativo sarebbe di avere tutte le classi pubblico e hanno un programma di esprimere il suo accoppiamento massimo potenziale; ma poi la forma debole del principio dell'onere afferma che gli aggiornamenti diventeranno sempre più costosa; questi sono i costi contro le quali barriere estensione devono essere misurate.

Infine, a fare la interessante confronto tra l'incapsulamento e la semantica, e che, a suo parere, la semantica di OO sono la sua maggiore forza. Io non sono né semanticist (io non sapevo nemmeno una parola esisteva prima che il buon signor Ramsey allude ad esso nel suo commento), ma presumo si intende, “semantica”, nel senso di “, il significato, o un interpretazione del significato, di una parola,”e molto in sostanza che una classe con un, Woof () metodo deve essere chiamato un cane.

C'è grande forza anzi in questa semantica.

Ciò che è curioso per me è che si buca la semantica contro l'incapsulamento e cercare un vincitore; Dubito troverete uno.

A mio parere, ci sono due forze che motivano l'incapsulamento:. La semantica e la logica

incapsulamento semantico significa semplicemente l'incapsulamento basato sul significato dei nodi (per usare il termine generale) incapsulati. Quindi, se vi dico che ho due pacchetti, uno chiamato, 'animali', e uno chiamato 'minerale', e poi ti do tre classi cane, gatto e Capra e chiedo in quali pacchetti queste classi dovrebbero essere incapsulati, poi, dato nessun altra informazione, si sarebbe perfettamente diritto di chiedere che la semantica del sistema suggerirebbero che le tre classi essere incapsulati all'interno del pacchetto, 'animale,', piuttosto che il, 'minerale'.

L'altra motivazione per l'incapsulamento, tuttavia, è logica, e in particolare lo studio dell'accoppiamento potenziale, di cui sopra. teoria incapsulamento fornisce effettivamente equazioni per il numero di pacchetti che deve essere utilizzato per incapsulare un numero di classi per ridurre al minimo l'accoppiamento potenziale.

Per quanto mi riguarda, l'incapsulamento nel suo complesso è il trade-off tra questo approccio semantico e logico: io concedo il potenziale accoppiamento dei miei programmi a salire al di sopra del minimo se questo rende il programma semanticamente più facile da capire; ma i livelli enormi e dispendiosi di accoppiamento potenziale sarà un avvertimento che il mio programma ha bisogno di essere ri-strutturato non importa quanto semanticamente ovvio che sia.

(E se il buon signor Ramsey è ancora leggendo, mi potreste voi oi vostri amici semanticist dare una parola migliore per i “Semantica,” fase sto usando qui? Sarebbe bene per usare un termine più appropriato. )

Saluti, Ed.

Answer 2

L'incapsulamento e l'astrazione risultante sono chiaramente i principali punti di forza di OO. Il predicato "cose" che cosa "azioni" può essere richiamato su di loro, in modo da sostantivi assumono un'importanza maggiore semantica di verbi.

In definitiva, è difficile immaginare la progettazione di un sistema complesso in una forma coerente e sostenibile, senza un certo livello di incapsulamento.

Answer 3

Come programmatore Lisp, il cui sistema oggetto fornisce probabilmente nessuna di queste, dico:. Nessuna delle precedenti

jwz:. "Il modello oggetto pseudo-Smalltalk perde e che funzioni generiche (opportunamente vincolata dal non-external-override regola) win"

Credo che gli attributi desiderabili che voi e gli altri elencare qui (incapsulamento, modularità, etc.) non sono così inerente OO come si pensa. Sono spesso forniti insieme OO stile Java, ma non esclusivamente la conseguenza di esso.

Answer 4

Isolamento Complessità è IMO l'obiettivo principale di qualsiasi disegno:. Incapsulare funzionalità dietro un'interfaccia che è più semplice da usare che la funzionalità stessa

OO fornisce diversi meccanismi per questo - la menzione di due Oyu:

incapsulamento consente di progettare un piano personalizzato che è indipendente dalla effettiva attuazione. (Parafrasando, "Simpler significa diverso").

Semantica consente di modellare le entità che rappresentano gli elementi del dominio del problema, in modo che siano più facili da capire.

---

Ogni progetto di raggiungere una certa dimensione diventa un esercizio di gestione della complessità. Scommetto una pretesa che nel corso degli anni, la programmazione ha scremato lungo i limiti di complessità abbiamo # VE imparato a gestire.

Non ho sguazzato nella programmazione funzionale per anni, ma nella mia comprensione che può essere meglio descritta dal significato di un matematico delle parole potenti, elgant, amd belle. "Beautiful" e "elegante", in questo contesto, cercare di descrivere una brillante intuizione della vera o la struttura in questione di un sistema complesso, guardando la cosa da un punto di vista in cui è sorprendentemente semplice. accetta la complessità come un dato, e cerca di spostarsi esso.

La flessibilità si parla è nella mia comprensione la capacità di cambiare il POV in base alle proprie esigenze - ma che va contro l'incapsulamento: che cosa è un dettaglio inutile da una posizione può essere l'unico rilevante in un altro

.

OO, OTOH, è l'approccio riduzionisti: cambiamo POV andando ad un livello superiore. Nel "vecchio OO", c'è un una singola gerarchia di POVs, interfacce sono - in questo modello - un modo per modellare diverse POVs.

Se così posso dire, la forza di OO è essere più adatto a "gente normale".

Answer 5

Una qualche forma di modularità è la chiave di ogni design scalabile. I limiti degli esseri umani impedisce alle persone di "Grokking" troppe informazioni in una sola volta, quindi dobbiamo suddividere i problemi in gestibili, pezzi di coesione, sia per fornire una base per la comprensione di un progetto di grandi dimensioni, così come un modo per suddividere gli incarichi di lavoro di un grande progetto tra molte persone.

Come scegliere la "divisione" più efficace / "partizione" di un grande progetto per raggiungere gli obiettivi di cui sopra? L'esperienza ha dimostrato che OO è il grande vincitore qui, e penso che molte persone sarebbe d'accordo che due attributi chiave di OO che lo rendono buono a questo sono:

• incapsulato : ogni classe incapsula un "segreto" - una serie di specifiche di implementazione ipotesi-che-sono-probabilmente-to-have-a-change-over-tempo circa la sua attuazione - e espone un'interfaccia agnostico a queste ipotesi; stratificazione tali astrazioni incapsulato consente all'architetto un design robusto in cui i componenti / le implementazioni possono essere facilmente scambiati a fronte di cambiamenti previsti.
• Noun-centric : nella maggior parte dei settori, gli esseri umani sembrano meglio in un primo momento in decomposizione di un modello di dominio pensando sostantivi / dati di un dominio, seguiti identificando i verbi di supporto che sono associati con ogni sostantivo .

Per quanto riguarda la programmazione funzionale (FP) contro OO, ho bloggato di questo, ma brevemente ritengo che FP è più su tecniche di implementazione che OO è più sulla struttura del programma e di design, e quindi i due sono complementari, con OO essendo più dominante sulla 'grande' estremità della scala e FP essendo più dominante sulla fine 'piccolo'. Cioè, su un grande progetto, la struttura ad alto livello è meglio descritta dal disegno classe OO, ma molti dei dettagli a livello di modulo (implementazioni, e dettagli delle forme delle interfacce dei moduli) sono meglio sagomati da FP influenze.

Answer 6

La forza di progettazione orientata agli oggetti è proporzionale alla quantità di tardiva si verifica nella progettazione. Questa è la nozione di Kay OO, non il concetto Nygaard. Alan Kay ha scritto :

  

OOP per me vuol dire solo la messaggistica, locali   la conservazione e la protezione e nascondersi   di stato di processo e estrema   late-binding di tutte le cose. Può essere   fatto in Smalltalk e in LISP. Là   sono forse altri sistemi in cui   questo è possibile, ma io non sono a conoscenza di   loro.

Gran parte della letteratura ignora tardiva in favore dell'idea C ++ di orientamento agli oggetti.

Answer 7

Facciamo un passo indietro e guardare a questo da un livello più alto. I vantaggi di qualsiasi caratteristica del linguaggio risiedono nella capacità di esprimere sinteticamente il problema / soluzione in un modo più naturale rispetto al dominio del problema.

La meccanica dell'OOP sono facilmente implementati in C puro con strutture e puntatori a funzione. È possibile anche ottenere un po 'di programmazione orientata agli oggetti si sentono facendo in questo modo. Tuttavia, idiomi OOP non sono quasi come di prossima pubblicazione in un ambiente del genere. Quando c'è il supporto della lingua attuale per OOP quindi l'espressività del paradigma viene fuori, e il modo in cui un linguaggio implementa l'idea ha un impatto reale su ciò che è "ha detto" e in che modo. Ad esempio, vedere le differenze nel codice utilizzando le chiusure / lambda in Lisp, Python, Ruby, etc.

Così, alla fine non si tratta di componenti e concetti di base, ma piuttosto come vengono messi insieme e utilizzati che rendono OO in C ++ che cosa sia.

Answer 8

L'incapsulamento in collaborazione con il polimorfismo. La capacità delle classi nella maggior parte delle lingue OOP per implementare una o più interfacce ha avuto il maggiore impatto sullo sviluppo del mio software. Questa caratteristica mi permette di definire con precisione l'interazione tra due oggetti.

Non solo definire le interazioni ma documentarlo in modo che anni dopo posso tornare a quella sezione di codice e vedere cosa sta succedendo in modo chiaro.

Questa funzione è la ragione principale per cui io preferisco usare linguaggi OOP sopra linguaggi funzionali. Mentre molto potente che ho trovato software scritto in linguaggi funzionali per essere un dolore per mantenere quando il ciclo di manutenzione si misura in decenni. (Software AutoLisp trovano in AutoCAD)

Answer 9

IMHO, OO significa semplicemente oggetti che interagiscono con altri oggetti. Incapsulamento significa semplicemente astrazione concetto. Così, si crea un socket e .Connect () per qualcosa. Come si collega, non si ha realmente a cuore (che è fondamentalmente la mia definizione della incapsulamento).

E, programmazione funzionale puro può utilizzare l'oggetto per comunicare .. ma questi oggetti devono essere immutabili. Quindi, sempre secondo me, FP può facilmente utilizzare OO concetto; linguaggio imperativo come C può ancora utilizzare il concetto di OO .. per esempio, un file per ogni "classe" con una sezione privata che non dovrebbe essere usato.

Answer 10

La sua domanda si legge come si desidera derivare i benefici di un casa analizzando un mattone.

Avere la capacità di fornire contesto semantico e l'incapsulamento sono solo le funzionalità di base di una classe in OO. (Come un mattone può sopportare una certa forza e rivendicare un certo spazio.)

Per continuare l'analogia: Per ottenere il massimo da mattoni, basta metterli insieme. Il stesso vale per le classi e gli oggetti.

sono un sacco di modelli di progettazione che può essere utilizzato per OO programmazione. La maggior parte di loro si basano sulla capacità di "incapsulamento" e "Semantica", che lei ha citato.

Alcuni di questi modelli sono anche una risposta al terzo comma della tua domanda:

• Se si desidera estendere il comportamento di una classe esistente, è possibile creare una classe derivata.
• Se si desidera estendere o modificare il comportamento di un oggetto esistente, si potrebbe considerare la modello decorator .

Answer 11

Il vero potere di OO sta nel polimorfismo, piuttosto che l'incapsulamento. Incapsulamento, in qualche misura, è realizzabile ed è usato in linguaggi funzionali, ma il polimorfismo sarebbe molto imbarazzante se implementato in linguaggio funzionale.

(Leggi "design pattern" di banda dei quattro per capire il potere della OO.)

@Phil, la differenza che lei ha citato, se ho capito bene, si trova tra il modo in cui il programma invoca dati / Metodo: oo, c'è in primo luogo è un oggetto / istanza, e quindi i dati / metodo dell'oggetto viene richiamato attraverso l'oggetto; in funzionale, metodo viene richiamato direttamente.

Tuttavia, guardando l'attuazione di un programma funzionale, vediamo che i dati e il metodo sono avvolti (in un file, ma non in una classe). Ad esempio, un programma di C ha il file di intestazione che dichiara le funzioni accessibili da altri file, i dati è un dato privato se è accessibile solo attraverso queste funzioni dichiarate. Fino a quando un programmatore è abbastanza attento, la maggior parte del incapsulamento in OO può essere implementato nei programmi funzionali. (Anche l'ereditarietà è disponibile utilizzando alcuni trucchi del puntatore.)