È un'elevata atomicità in overkill di mvc?

Question

È un'elevata atomicità in overkill di mvc?

#1 da (4 voti)

3

Con il passare del tempo ho appreso che non seguendo strettamente le regole di un modello architettonico come il tipo di mvc contrasta lo scopo reale di avere un software maintable. Di solito finisco con i controller mostri grassi o un modello che fa troppo. Di solito questo accade perché non ho modularizzato abbastanza il mio codice solo per evitare di avere troppe classi.

Nel mio ultimo progetto ho provato un approccio diverso: ho analizzato ciò che volevo programmare e ho cercato di ottenere un'elevata atomicità raggruppando il sistema in componenti più piccoli. Questi componenti avranno quindi un modello, un controller e una vista. Tutto in cima alla rigorosa gerarchia in cui ogni componente dipende solo dai figli e mai dal genitore.

Ad esempio per un'architettura molto atomica:

HumanModel, HumanController, HumanView
BrainModel, BrainController, BrainController
FrontalLobeModel, FrontalLobeController, FrontalLobeView,
NerveModel, NerveController, NerveView,
NerveNucleusModel, NerveNucleusController, NerveNucleusView
GolgiAparatusModel, GolgiAparatusController, GolgiAparatusView
etc

Potrei andare avanti ma probabilmente puoi vedere cosa intendo adesso. Mentre la quantità di file o classi aumenta, credo che renda l'applicazione più "a prova di futuro". Se dovessi estendere la funzionalità dell'umano, sarebbe più semplice e non dovrò riscrivere nulla. Dal momento che utilizzo questo approccio non ho mai avuto problemi. Anche se alcune classi sono molto minimaliste, in futuro potrei dover estendere la funzionalità del cervello.

Perché le persone dicono che è eccessivo?

architecture design-patterns mvc

posta Asperger 11.01.2018 - 12:00

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns mvc

Come gestire una dichiarazione switch di grandi dimensioni con diversi comandi diversi? Con il sourcing di eventi, come ottenere la risposta di una chiamata che è un effetto collaterale?

score 4 · Accepted Answer

Bene, prendi il tuo esempio intellettuale del cervello umano:

HumanModel, HumanController, HumanView
BrainModel, BrainController, BrainController
FrontalLobeModel, FrontalLobeController, FrontalLobeView,
NerveModel, NerveController, NerveView,
NerveNucleusModel, NerveNucleusController, NerveNucleusView
GolgiAparatusModel, GolgiAparatusController, GolgiAparatusView

Il tuo ragionamento è corretto per suddividere i componenti nei loro sottocomponenti e non avere dipendenze cicliche.

Se questo è eccessivo, starebbe nel fatto che forse non hai bisogno di un GolgiAparatusModel, un GolgiAparatusController o un GolgiAparatusView. Potresti aver bisogno di uno o due, ma forse non tutti e tre.

Una grande parte di avere un codice chiaro e conciso è la semplicità, e la semplicità significa che non si creano classi che non sono necessarie. Capisco che vuoi rendere il tuo programma a prova di futuro, quindi aggiungili comunque. Questo potrebbe anche essere ragionevole se sei abbastanza sicuro che implementerai queste lezioni nel prossimo futuro.

Tuttavia, per la maggior parte, determinare come e dove si evolverà il tuo progetto è alquanto imprevedibile. La cosa migliore che puoi sperare è cercare le tendenze nel tuo codice e fornire un mezzo per continuare la tendenza in modo diretto. Ad esempio, se si persistono i modelli in un database, sarebbe opportuno fornire un'interfaccia comune da cui derivano tutti i modelli che includerebbe metodi comuni come save e update .

Anche se non dovrebbe essere usata nemmeno un'interfaccia se non c'è tendenza, mentre crei un'interfaccia con una sola classe che ne deriva. Questo di nuovo non sta rendendo il tuo programma più semplice, anzi al contrario.

Quindi il mio consiglio è di creare sottocomponenti come hai fatto, ma solo per le classi che richiedi. Sembra che tu stia su qualcosa, e certamente non voglio scoraggiarlo, ma dovresti evitare ogni volta che è possibile creare classi esclusivamente per "rendere a prova di futuro" il tuo codice.