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 schemi e principi di progettazione OO che sono in qualche modo analoghi alla normalizzazione, almeno nella misura in cui i sistemi OO sono analoghi ai database relazionali. Ad esempio:

• Single Principio di responsabilità
• Separazione delle preoccupazioni
• Once and Only Once , a.k.a. 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ì ho

Sono rimasto zitto su questo argomento da molto tempo; è il momento di parlare.

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

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

• Come hai fatto?

Comprendendo 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 è andata a finire?

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

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

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

Ho chiesto all'università locale di sponsorizzare un dottorando o due se vogliono prendere la causa, ma purtroppo la nostra università locale non insegna una base adeguata nella programmazione della semantica del linguaggio.

Ci sono state alcune ricerche interessanti in questo settore, ma tutto ciò - ne sono a conoscenza - non è stato all'altezza. O assume erroneamente che, poiché la normalizzazione deriva da uno sfondo relazionale, non si applica ai modelli orientati agli oggetti, o presuppone che la normalizzazione si applichi solo ai dati definiti dagli oggetti. Tuttavia, ci sono alcuni progetti near-miss molto interessanti ...

Le cose davvero interessanti accadono quando applichi la normalizzazione al codice - che direi che è il fondamento di tutti i refactoring .

Quindi ora sto pensando che la cosa migliore da fare sia far uscire la voce, forse chiedendo di parlare al DevDays 2011 a Washington, e scoprire se c'è una comunità così eccitata da questa roba come me.

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

Questo è iniziato come un commento su la risposta eccellente di Rein Henrichs , ma troppo lungo ...

La normalizzazione si applica ai dati relazionali. Viene utilizzato per evitare la duplicazione, il che rende più semplice garantire l'integrità dei dati poiché ciascun dato è memorizzato in un'unica posizione. Normalizzi un database trovando le violazioni di un modulo normalizzato e correggendoli.

La programmazione orientata agli oggetti si applica alle operazioni sui dati. È pensato per raggruppare modi di manipolare i dati insieme. È possibile applicare tecniche similari alle classi per eliminare i metodi duplicati, magari osservando i dati che l'operazione manipola o dipende da. Ad esempio, 1NF in una prospettiva OO non avrebbe alcuna operazione duplicata all'interno di una classe. 3NF potrebbe corrispondere a una buona struttura di ereditarietà in cui il codice comunemente usato si trova in una superclasse. Sono sicuro che potresti trovare un posto adatto per l'iniezione di dipendenza anche lì. Raggiungi un design migliore (anche se nulla di simile alle forme normali è stato ancora scoperto) 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 (noti anche come 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 dal test cerca di trovarli presto esercitando il codice in quanto sarà esternamente. Proprio come nello sviluppo di database, la migliore soluzione si trova con esperienza e analisi.

Un ottimo approccio per progettare oggetti del modello di business simile alla normalizzazione è Modellazione UML a colori .

È una strategia di design trovata da Peter Coad che aiuta ad astrarre gli oggetti del modello di business.

Sfortunatamente il libro - Java Modeling In Colour con UML: Enterprise Components and Process - è esaurito e tu puoi comprare solo quelli usati.

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

Se hai familiarità con la progettazione relazionale troverai Modellazione UML a colori utile per guidare l'utente:

• La modellazione a colori di Peter Coad - Note di Stephen R. Palmer

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

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

In realtà penserò più in profondità. Se modellate i vostri oggetti con la duplicazione di dati 0 e potreste "interrogare" i vostri oggetti ed eseguire aggiornamenti basati su set su di essi non ci sarebbe alcuna disconnessione. In effetti, puoi farlo creando una libreria di oggetti. Microsoft ha già pensato a questo, ma è andato nella direzione di fare una sintassi LINQ basata su set di C # su una "libreria di query".