Database Guy chiede: teoria del design orientata agli oggetti?

StackOverflow https://stackoverflow.com/questions/246499

Domanda

Ho lavorato con la progettazione di database per un periodo molto lungo, e in questi giorni sto lavorando anche in C #. OO ha senso per me, ma non credo di avere una buona base nella profonda teoria della progettazione di OO.

Nella terra dei database, c'è molta teoria su come progettare la struttura di un database, la nozione principale è la normalizzazione. La normalizzazione dirige direttamente la struttura di un database e in una certa misura determina come organizzare le entità in un database.

Ci sono concetti simili dietro come progettare la struttura di un programma orientato agli oggetti?

Quello che sto raggiungendo è uno o più principi teorici sottostanti che guidano naturalmente lo sviluppatore nella "corretta" quotazione progettazione per la soluzione di un determinato problema.

Dove posso cercare per saperne di più?
C'è un lavoro da leggere che dovrei leggere?

Aggiornamento:

Grazie a tutti per le loro risposte. Quello che sto leggendo sembra dire che non esiste "Grand Theory of OO Design", ma ci sono un sacco di principi importanti - che sono in gran parte esemplificati da modelli di design.

Grazie ancora per le risposte :)

È stato utile?

Soluzione

Fai attenzione ad alcune pubblicazioni sui modelli di progettazione.

Esistono diverse specie di definizioni di classe. Classi per oggetti persistenti (che sono come righe nelle tabelle relazionali) e raccolte (che sono come le tabelle stesse) sono una cosa.

Alcuni dei " Gang of Four " i modelli di progettazione sono più applicabili agli oggetti attivi attivi e meno applicabili agli oggetti persistenti. Mentre combatti attraverso qualcosa come Fabbrica astratta , mancherai alcuni punti chiave del design OO in quanto si applica agli oggetti persistenti.

La pagina Object Mentor Cos'è il design orientato agli oggetti? ha davvero molto di te bisogno di sapere per passare dalla progettazione relazionale alla progettazione OO.

La normalizzazione, a proposito, non è un principio di progettazione generale che si applica sempre ai database relazionali. La normalizzazione si applica quando si hanno transazioni di aggiornamento, per prevenire anomalie di aggiornamento. È un hack perché i database relazionali sono cose passive; o devi aggiungere l'elaborazione (come i metodi in una classe) o devi passare un sacco di regole (normalizzazione). Nel mondo del data warehouse, in cui gli aggiornamenti sono rari (o inesistenti), le regole di normalizzazione standard non sono così rilevanti.

Di conseguenza, non esiste una "normalizzazione come questa" per modelli di dati oggetto.

In OO Design, forse la regola più importante per la progettazione di oggetti persistenti è il Principio di responsabilità individuale .

Se progetti le tue classi per avere una buona fedeltà agli oggetti del mondo reale, e assegni le responsabilità a quelle classi in un modo molto mirato, sarai felice con il tuo modello di oggetti. Sarai in grado di mapparlo su un database relazionale con relativamente poche complessità.

Si scopre che quando si guardano le cose da un punto di vista della responsabilità, si scopre che le regole 2NF e 3NF si adattano a una corretta assegnazione di responsabilità. Le chiavi univoche contano ancora. E i dati derivati ??diventano la responsabilità di una funzione del metodo, non di un attributo persistente.

Altri suggerimenti

Il libro " Design Patterns " è il tuo prossimo passo.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley -Professionale / dp / 0201633612

Ma non devi usare un approccio OO a tutto. Non essere religioso a riguardo. Se un approccio più procedurale sembra più stretto, allora segui quello. Le persone nuove a OO tendono a scadere per un po '.

Penso che Sviluppo software agile, principi, schemi e pratiche è abbastanza bene.

Fornisce molta approfondita divulgazione dei principi OO elencati qui :

  • I principi di progettazione orientata agli oggetti e gestione delle dipendenze
  • SRP & # 8212; Il principio di responsabilità unica
  • OCP & # 8212; Il principio aperto chiuso
  • LSP & # 8212; Il principio di sostituzione di Liskov
  • DIP & # 8212; Il principio di inversione di dipendenza
  • ISP & # 8212; Il principio di segregazione dell'interfaccia
  • REP & # 8212; Il principio di equivalenza del rilascio di riutilizzo
  • CCP & # 8212; Il principio di chiusura comune
  • CRP & # 8212; Il principio di riutilizzo comune
  • ADP & # 8212; Il principio delle dipendenze acicliche
  • SDP & # 8212; Il principio delle dipendenze stabili
  • SAP & # 8212; Il principio delle astrazioni stabili

Se sei abituato a costruire database normalizzati, la progettazione orientata agli oggetti dovrebbe essere naturale. Le strutture delle classi finiranno per assomigliare molto alla struttura dei dati, con l'ovvia eccezione che le tabelle di associazione si trasformano in elenchi e le tabelle di ricerca si trasformano in enumerazioni all'interno delle classi.

Tutti insieme, direi che è molto meglio entrare nella progettazione di OO con uno sfondo nei database relazionali di quanto andresti nella direzione opposta.

Se vuoi davvero fare i conti con O-O, vai a giocare con Smalltalk . ST è un linguaggio Oem puro , e abbastanza in faccia a riguardo. Una volta superato il paradigma gobba hai imparato OO in quanto non puoi davvero fare Smalltalk senza di essa. È così che ho imparato OO per la prima volta.

Controlla i risultati di questo . Impara da ogni domanda.

Mi è piaciuto molto Head First Design Patterns , che è molto accessibile, e l'eccellente Euristica del design orientata agli oggetti di Arthur J. Riel

Questo sito elenca 101 titoli ... modelli di progettazione, refactoring e altro. .. Dai un'occhiata .. Sarà un buon punto di partenza ...

Scegli Object Thinking di David West. Una lettura interessante ..
Sei del lato oscuro però ... come da libro;) Il pensiero del database è stato la maledizione dei programmatori OO dappertutto. Sono estremità opposte di uno spettro. Ad esempio

  • Il pensiero del database valorizza gli attributi dei dati su tutto il resto .. normalizzazione e creazione di tipi in base al modo in cui si adattano allo schema DB o al diagramma ER .. Il pensiero OO crea tipi basati su comportamento e collaborazione e non riconosce gli attributi dei dati come tutto importante.
  • I database provengono da persone scientifiche che apprezzano la formalizzazione e il metodo su tutto il resto. OO proviene da persone che usano l'euristica e le regole empiriche e valorizzano l'individualità e l'interazione sociale attraverso un processo duro e veloce.

Il punto in cui un programmatore COBOL può scrivere programmi COBOL anche dopo essersi spostato su una lingua OO. Dai un'occhiata a qualsiasi libro come Thinking in Java per la prima sezione che dettaglia invariabilmente i principi di OO (apprendista). Seguilo con Object Thinking (giornalista) e, a tempo debito, un maestro.

Modella i tuoi oggetti tenendo a mente gli oggetti del mondo reale.

Attualmente stiamo sviluppando software di automazione per macchine. Una di queste macchine ha due porte di carico per l'alimentazione della materia prima, mentre tutte le altre ne hanno solo una. Finora in tutti i moduli avevamo le informazioni delle porte (impostazioni correnti, numero di lotto attualmente assegnato ad esso, ecc.) Come membri della classe che rappresentano la macchina.

Abbiamo deciso di creare una nuova classe che contiene le informazioni sulle porte e di aggiungere due membri LoadPort a questa classe MachineXY. Se ci avessimo pensato prima, avremmo fatto lo stesso per tutte quelle macchine a porta singola ...

Dovresti guardare UML, che è un intero processo dato a OOD.

Consiglio di prendere un libro (o una coppia), poiché la teoria è piuttosto ampia, la maggior parte delle persone sceglie e sceglie le tecniche più appropriate per il progetto in questione.

Inizia a leggere sui modelli di design, ad esempio Martin Fowler. :)

Sono l'uso più pratico di OOP.

Suppongo che intendi OO nel mondo del database.

I database orientati agli oggetti che archiviano oggetti non ne hanno mai catturato uno, quindi al momento stai cercando di mappare gli oggetti sul database relazionale. ORM o Mappatura relazionale oggetto è il termine usato per descrivere il software che esegue questa mappatura. Idealmente, questo ti offre il meglio dei due mondi in cui gli sviluppatori possono interagire con gli oggetti e nel database tutto è archiviato in tabelle relazionali in cui può avvenire la messa a punto standard.

nel gergo DBA: il design orientato agli oggetti non è altro che dati correttamente normalizzati dietro interfacce operative sicure, significato sicuro, guardare le operazioni, non i dati direttamente

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top