Quante classi sono troppe?

La tua domanda è triplice:

1. Quante classi sono troppe?

Anche se ci sono alcune guide su alcune metriche come per quanto tempo dovrebbe essere un metodo o quanti parametri può avere un metodo, non ci sono metriche su quante classi dovrebbe avere un sistema come massimo.

IMHO non è tanto la quantità di classi che creano complessità quanto il fatto di non essere coesi e il loro essere strongmente accoppiati l'uno con l'altro. Se le classi sono troppo grandi, c'è un problema e ci sono metriche per questo. Se le classi sono strettamente accoppiate, c'è un altro problema.

D'altra parte, quante classi o interfacce astratte, pur non essendo un indicatore diretto della complessità, può darti un suggerimento. Dovrebbe esserci un rapporto relativamente alto di implementazione delle classi nelle interfacce. Ciò significa che le tue astrazioni sono buone e servono uno scopo buono. Se si dispone di un'interfaccia relativamente 50/50 al rapporto degli implementatori, allora si hanno cattive astrazioni o non si progetta abbastanza bene. Quest'ultimo non si applica nelle prime fasi di sviluppo poiché ci sarà ovviamente più o meno la stessa quantità di interfacce di quella degli implementatori.

2. Tutto questo (tutte le mie classi) è un po 'esagerato?

Vedi la domanda precedente. Ma chiediti anche a te (il tuo team) di sentirti oberato di cose sopraffatte dalla quantità di cose di cui occuparti. In tal caso, è necessario chiedere aiuto. La divisione del lavoro tra programmatori a livello di presentazione e programmatori di regole aziendali potrebbe aiutare.

3. È meglio avere tutto concentrato nella classe principale o è meglio avere un sacco di classi?

Stai rispondendo qui usando la parola "stipato". Questo è un noto anti-modello chiamato God-class. Dovresti evitarlo.

Bottomline: non è la quantità di componenti ma le relazioni tra loro che rendono un sistema troppo complesso da mantenere.

Non guardare la quantità di classi. Crea un diagramma UML lasciando fuori tutte le classi foglia. Sembra pulito, semplice o almeno gestibile? Se lo fa, allora sei OK.

Stai facendo la domanda sbagliata. Non è "meglio avere tutto concentrato nella classe principale", né "è meglio avere un sacco di classi".

Quando prendiamo le distanze da questi tentativi di generare regole rigide per coprire tutti i casi, arriviamo ad un approccio molto migliore: attenersi a principi di progettazione ampiamente accettati, come quelli incorporati da SOLID , e ci ritroveremo con un numero appropriato di classi per il tuo codebase.

Qualunque sia quel numero.

In particolare, per le GUI tenderete a finire con un sacco di classi mentre aggiungete più widget; E 'normale. Lo scenario che descrivi non mi sembra spaventoso.

La ragione principale per avere classi in qualsiasi codice è rendere quel codice più facile da seguire . Se ritieni che aggiungendo classi, il codice diventa più chiaro e più descrittivo e concettualmente significativo ... allora sei sulla strada giusta. Ma se ritieni che aggiungendo classi, il codice diventa più confuso, tentacolare o ottuso ... quindi non farlo.

Non esiste una formula semplice; ogni applicazione è diversa. Solo un umano può fare chiamate di giudizio come queste. In caso contrario, i programmi per computer potrebbero scrivere da soli. :)