Schema di classe. Combinare diversi creatori

Question

Schema di classe. Combinare diversi creatori

Naviga le tue risposte

#1 da (2 voti)

3

Quindi vorrei modellare il diagramma delle classi per il seguente scenario:

il client deve gestire tre tipi di account (Pocket, Postbank, DKB). Altri tipi di account possono essere aggiunti in seguito.
il cliente registra i movimenti (spese e entrate). Questi movimenti sono ciò che definisce lo stato di ogni account
Mentre le entrate sono piuttosto elementari (c'è solo bisogno di registrarsi per quale account è stato fatto), le spese devono essere ordinate a seconda della loro natura (tempo libero, cibo, trasporti, generale) Altri tipi di spese possono essere aggiunto in seguito.

Per questi requisiti sono arrivato con questa modellazione:

Istanza Singleton per "movementFactory". Sarà esteso da due tipi di creatori: entrate e uscite.
Il creatore delle spese verrà implementato in classi concrete in base al tipo di spesa che verrà creata.

I miei dubbi arrivano quando cerco di capire se avere due "metodi di produzione" per il "percorso di spesa" è in qualche modo eccessivo e se la classe SingletonMovementProducer è una buona pratica in questo caso o come potrei modellare lo scenario dato.

design-patterns factory-method uml

posta blfuentes 23.07.2017 - 19:13

fonte

1 risposta

Leggi altre domande sui tag design-patterns factory-method uml

Quando utilizzare un repository / servizio vs una variabile di istanza? RESTFultezza di / endpoint di azione

score 2 · Accepted Answer

I modelli di contabilità sono più semplici di quelli presentati e non richiedono così tanta ereditarietà. Martin Fowler ne ha uno dal 2006 all'indirizzo link

Penso che non sia un buon progetto utilizzare le sottoclassi per i tipi di spesa, per un paio di motivi.

i requisiti non specificano differenze reali tra tipi di spesa o tipi di movimento. Hai un design troppo complesso per capire e mantenere.
cosa succede quando hai un utente che vuole classificare una spesa che è sia di svago che di cibo? L'ereditarietà non è flessibile e probabilmente un modello di tag non gerarchico (con composizione) sarebbe migliore?

Ti suggerisco di semplificare le cose finché non hai davvero esempi concreti del perché sono necessarie le sottoclassi. Come puoi vedere, con un design più semplice, la domanda sulle fabbriche scompare.