Nella programmazione del database esiste una tecnica chiamata "normalizzazione" che si fa ai dati che si desidera archiviare.

Qualcuno ha provato ad applicare questo concetto alla progettazione di oggetti? Come hai? Come ha funzionato?

Modifica: per espandere / chiarire, la normalizzazione del database è più di un insieme di principi per ridurre la ridondanza. In realtà ci sono passaggi e fasi che attraversi e almeno misure moderatamente oggettive che ti dicono in quale fase ti trovi. Il design degli oggetti ha i suoi principi e c'è il concetto di odore, ma c'è un modo per fare qualcosa di simile che ti direbbe che sei in XX-form0,1,2 ... ecc ... e i metodi per passare al prossimo livello più "normalizzato"?

Mentre alcune delle tensioni sottostanti che guidano la normalizzazione del database non sono presenti in un sistema OO, alcune lo sono. Questi hanno dato origine a modelli e principi di progettazione OO che sono in qualche modo analoghi alla normalizzazione, almeno in quanto i sistemi OO sono analoghi ai database relazionali. Per esempio:

• Principio unico di responsabilità
• Separazione degli interessi
• Once and Only Once , alias DRY

In altre parole, qualcuno ha provato ad applicare le tecniche di normalizzazione del database a OOP? No, perché OOP ha già soluzioni per i problemi condivisi che la normalizzazione risolve per i database relazionali.

Sì Sì Sì

Ho taciuto su questo argomento per molto tempo; è tempo di parlare.

• Qualcuno ha provato ad applicare questo concetto alla progettazione di oggetti?

Sì. Ho lavorato sulla formalizzazione della normalizzazione degli oggetti (e quindi della teoria orientata agli oggetti sottostante) per oltre 20 anni.

• Come hai?

Rendendosi conto che i dati e il codice sono intercambiabili, almeno in teoria. Ciò significa che i principi di normalizzazione e le operazioni relazionali possono essere applicati sia al codice che ai dati.

• Come ha funzionato?

Finora ha funzionato abbastanza bene - credo che le intuizioni acquisite siano state le "armi segrete" delle mie capacità di progettazione, analisi e refactoring.

Non ho detto nulla pubblicamente prima di questo perché ho pensato che alla fine avrei avuto il tempo di finire la ricerca - e produrre gli strumenti impliciti - me stesso.

Ma sono giunto alla conclusione che con tutto quello che succede nella mia vita che è più importante, più divertente e / o più redditizio, non avrò il tempo di finire la ricerca da solo. Mai. C'è anche la significativa possibilità che semplicemente non ho le basi teoriche CS necessarie per completare il lavoro da solo.

Ho chiesto all'università locale di sponsorizzare uno o due dottorandi se vorrebbero occuparsi della causa, ma purtroppo la nostra università locale non insegna una base adeguata nella semantica del linguaggio di programmazione.

C'è stata qualche ricerca interessante in questo settore, ma tutto ciò - di cui sono a conoscenza - non è stato all'altezza. O presuppone erroneamente che, poiché la normalizzazione proviene da uno sfondo relazionale, non si applica ai modelli orientati agli oggetti, oppure presuppone che la normalizzazione si applichi solo ai dati definiti dagli oggetti. Ci sono alcuni progetti quasi-miss molto interessanti comunque ...

Le cose veramente interessanti accadono quando applichi la normalizzazione al codice - che direi sia il fondamento di tutto il refactoring .

Quindi ora sto pensando che la cosa migliore da fare sia spargere la voce, magari chiedendo di parlare al DevDays 2011 a Washington, e scoprire se c'è una comunità entusiasta di questa roba come me.

Ecco un'anteprima: la normalizzazione è il processo per rendere qualcosa di minimo e non ridondante. Il principio di non ripetersi (DRY) della programmazione orientata agli oggetti è quindi una chiara manifestazione degli obiettivi della normalizzazione. Credo di poter dimostrare che tutti i noti principi di progettazione / programmazione / refactoring orientati agli oggetti sono la logica conseguenza della normalizzazione degli oggetti. Penso di poter anche dimostrare che ci sono cose più interessanti che si possono fare con i sistemi in Object Normal Form (ONF) oltre al semplice refactoring.

Questo è iniziato come un commento sulla risposta eccellente di Rein Henrichs , ma ha avuto troppo tempo ...

La normalizzazione si applica ai dati relazionali. Viene utilizzato per evitare la duplicazione, il che rende più semplice garantire l'integrità dei dati poiché ogni dato è archiviato in un solo posto. Si normalizza un database trovando le violazioni di un modulo normalizzato e correggendole.

La programmazione orientata agli oggetti si applica alle operazioni sui dati. Ha lo scopo di raggruppare i modi di manipolare i dati insieme. È possibile applicare tecniche simili alle classi per eliminare metodi duplicati, magari osservando quali dati manipola o da cui dipende l'operazione. Ad esempio, 1NF in una prospettiva OO non avrebbe alcuna operazione duplicata all'interno di una classe. 3NF potrebbe corrispondere a una buona struttura ereditaria in cui il codice comunemente usato si trova in una superclasse. Sono sicuro che potresti trovare un posto per inserire anche l'iniezione di dipendenza. Raggiungi un design migliore (anche se non è stato ancora scoperto nulla di simile alle forme normali) trovando violazioni di buoni principi di progettazione e refactoring.

Non ci sono davvero metodi algoritmici per raggiungere un buon design in entrambi i mondi. Come sottolinea Rein Hendrichs, ci sono molti principi che possono identificare potenziali problemi (alias odori di codice). I modelli di progettazione e le migliori pratiche sono alcuni dei modi in cui le persone hanno cercato di affrontarli. Lo sviluppo guidato dai test tenta di trovarli in anticipo esercitando il codice come sarà esternamente. Proprio come nello sviluppo di database, la migliore soluzione si trova con esperienza e analisi.

Un ottimo approccio alla progettazione di oggetti del modello di business simile alla normalizzazione è la modellazione UML a colori .

È una strategia di progettazione trovata da Peter Coad che aiuta a sottrarre gli oggetti del modello di business.

Sfortunatamente il libro - Java Modeling In Color With UML: Enterprise Components and Process - è esaurito e puoi acquistarne solo quelli usati.

Ci sono un paio di articoli su Internet su questa tecnica.

Se hai familiarità con il design relazionale troverai la modellazione UML in Color utile per guidarti:

• 'Modeling in Color' di Peter Coad - Note di Stephen R. Palmer

Hai studiato per utilizzare le annotazioni Java ORM nel tuo codice durante la creazione del diagramma di classe? Hibernate genererebbe il database una volta terminata la fase di modellazione. Il diagramma in questo esempio è solo un visualizzatore del codice.

I riferimenti o i puntatori agli oggetti sono simili alle chiavi esterne. È profondo quanto sono disposto a pensarci. :)

In realtà ci penserò più in profondità. Se modifichi i tuoi oggetti con 0 duplicazione dei dati e potessi "interrogare" i tuoi oggetti ed eseguire aggiornamenti basati su set su di essi, non ci sarebbe alcuna disconnessione. In effetti, PUOI farlo facendo una libreria di consumatori di oggetti. Microsoft ha già pensato a questo, ma è andato nella direzione di rendere la sintassi LINQ basata su set parte di C # su una "libreria di query".