Divisione di oggetti nelle parti più fondamentali

Question

Non sono sicuro se il titolo acquisisca ciò che sto cercando di dire qui.

Quando si progetta in OO dovrei suddividere i miei oggetti nelle loro aree più specifiche, quindi se ho un oggetto factory che si occupa della creazione di oggetti, ma in seguito mi imbatto in un modo di creare oggetti per un altro scopo anche se essi potrebbe essere lo stesso oggetto, vale la pena creare una figura separata o semplicemente aggiungere all'exiting.

La mia più grande preoccupazione è di raggruppare le classi con tonnellate di roba, o di dividere oggetti e diluire i miei progetti in un mare di classi.

Qualsiasi aiuto?

EDIT:

Credo che su un/argomento parte nota a margine sub di me vuole scoprire il livello di granularità da usare in un programma. Tipo, quanto in basso dovresti andare?

Answer 1

mia più grande preoccupazione è carica fino classi con tonnellate di roba, o oggetti scissione e diluendo i miei progetti in un mare di classi

Questo è un punto molto valido e in qualsiasi dimensioni ragionevoli anche progetto, estremamente difficile da ottenere in anticipo soprattutto perché, realisticamente, i requisiti stessi si evolvono nel tempo nella maggior parte dei casi. È qui che entra in gioco "Refactoring". Disegni in base a ciò che conosci in qualsiasi momento e non provi a fare troppi salti di fede su ciò a cui pensi che il sistema possa evolversi.

Dato che ora sai cosa stai costruendo, progetti le tue classi cercando di utilizzare al meglio i concetti di OO - ad esempio incapsulamento/polimorfismo. Questo è di per sé, come altri hanno notato, può essere notoriamente difficile da raggiungere e questo è dove l'esperienza, sia nella progettazione di sistemi OO che nella conoscenza del dominio può davvero tornare utile.

design in base a ciò che si sa -> Creazione -> Commenta -> refactoring -> Re-design -> E si va avanti e avanti ..

Answer 2

Trovare il livello corretto di dettaglio e responsabilità è ciò che rende la progettazione OOP così difficile. Possiamo aiutarti con un caso specifico ma non con qualcosa di questo generale. Se esistessero algoritmi o metodologie rigorose su come risolvere questo problema, chiunque potrebbe essere un progettista OOP.

Answer 3

Una regola empirica che mi piace per decidere "questo sta diventando troppo grande ora?" è "posso spiegare lo scopo in modo conciso?" Se inizi a dover introdurre avvertenze e molte parole di donnola per spiegare le funzioni di un componente del tuo disegno (sia esso classe, variabile membro, metodo o qualsiasi altra cosa) potrebbe essere un buon indicatore che sta diventando troppo complesso e dovrebbe essere diviso .

Answer 4

Nel caso specifico, se si dispone già di un oggetto factory, il principio DRY (Do not Repeat Yourself) direbbe che è una cattiva idea creare un'altra fabbrica che faccia la stessa cosa.

Si tratta di un problema reale che si presenta? O semplicemente una paura di come il tuo codice potrebbe crescere in futuro?

Answer 5

Se si utilizza lo stesso tipo di oggetto per risolvere problemi drasticamente diversi, potrebbe essere necessario riprogettare la classe per concentrarsi sulla separazione delle preoccupazioni. Se hai bisogno di una risposta più specifica, dovrai fornire un esempio di un tipo di classe che avrebbe bisogno di questa funzionalità.

---

cose che ho potuto formulate male in Q. Credo che andrei ripeterà me il suo solo più di un caso di dove mettere il codice, potrebbe essere aggiunti a un exsiting fabbrica che crea oggetti di progettazione per esportare i dati in fogli di calcolo Excel. Sull'altra mano ho potuto vedere che potrebbe anche avere il proprio stabilimento per l'importazione di dati excel . Entrambe le fabbriche produrranno gli stessi oggetti con lo ma le lavorazioni interne di sono completamente diverse. -

Se non si sta progettando o si sta facendo alcuna astrazione di classe (sottoclasse o utilizzo di interfacce), potrebbe non essere necessario utilizzare il modello di fabbrica. Il pattern factory è generalmente il più adatto per fornire oggetti di un tipo di classe base o per implementare un'interfaccia specifica.

Answer 6

Entrambi le fabbriche produrranno gli stessi oggetti ma i meccanismi interni sono completamente diversi.

Non so se ho capito bene, ma questo sembra un candidato per il modello AbstractFactory.