1 modello di classe o 3 modelli di classe? 1 per ciascuna: interfaccia utente, libreria dell'hardware hardware e database

Quindi sembra che i tuoi progetti abbiano in genere tre aree: raccolta, archiviazione e presentazione dei dati. Ci sono dei compromessi tra il singolo modello e diversi approcci di modelli.

Con un singolo modello, è molto semplice garantire la coerenza su tutte le aree del progetto. Con più modelli, a meno che non crei meccanismi per gli aggiornamenti automatici (e faccia fronte ai sottili bug che possono portare a), è possibile che diventino incoerenti l'uno rispetto all'altro.

Con un singolo modello, poiché le esigenze di accesso ai dati aumentano con la crescita del progetto, la sua interfaccia può diventare più grande e i suoi interni possono diventare più complessi e ingombranti. Con più modelli, devi definire e mantenere interfacce per ogni modello e scrivere un sacco di codice per comprimere e decomprimere i dati per il trasferimento dentro e fuori di essi.

Sembra che tu abbia già una buona modularità nel tuo progetto, con moduli di interfaccia, raccolta e archiviazione separati. Un singolo modello di dati diventa un quarto modulo. Non sono convinto che passare a sei moduli (un modello separato per ogni modulo) possa aiutare le cose.

Quello che consiglio è di mantenere il modello singolo, ma dargli tre interfacce, una per ogni modulo che interagisce con esso: interfaccia utente, raccolta e archiviazione. Il modulo UI vedrebbe solo l'interfaccia dell'interfaccia utente per il modello di dati e non saprebbe né si preoccuperebbe di come i dati vengono raccolti o archiviati. Allo stesso modo per i moduli di raccolta e archiviazione. In generale, la programmazione in termini di interfacce è molto buona pratica, in quanto può limitare la complessità e mantiene l'accoppiamento a un livello gestibile.

Sì, questa è una buona pratica generale. Vedi programmazione modulare , separazione di riguarda e principio di responsabilità singola . Questi concetti sono correlati, ma il succo è che dovresti suddividere il tuo codice in pezzi indipendenti e monouso. Ciò consente di apportare modifiche ai pezzi singolarmente senza influire sul resto, scambiarli con pezzi simili e riutilizzarli altrove. Al momento non è possibile riutilizzare, ad esempio, il codice hardware in un altro progetto che utilizza un'interfaccia utente diversa; le parti sono dette strettamente accoppiate .