Cohesion e Coupling sono i due termini rilevanti, tuttavia, non c'è una possibile risposta fissa a causa della loro natura contraddittoria.

di coesione

La coesione è una misura di quanto siano vicini i metodi di una classe. Se hai un'elevata coesione, la maggior parte dei tuoi metodi sono responsabili di una cosa simile, mentre se hai una bassa coesione, i metodi stanno facendo cose più o meno indipendenti. Questo è leggermente correlato al principio di responsabilità singola (SRP), che ci dice che dovresti mirare ad un'elevata coesione.

Accoppiamento

Al contrario della coesione, l'accoppiamento fa riferimento alle interdipendenze tra moduli / classi. Se hai un accoppiamento elevato, significa che i tuoi moduli interagiscono molto tra di loro, mentre l'accoppiamento basso significa che ci sono solo poche interazioni, cioè piccole interfacce. Di nuovo, è facile vedere che l'accoppiamento basso è migliore.

La contraddizione

Il problema con l'ottenimento dell'accoppiamento basso e di coesione, è che cambiare il codice per migliorarne uno significa ridurre l'altro.

Come semplice esempio, considera tutte le tue funzionalità contenute in una singola classe. Ciò significa che hai un accoppiamento estremamente basso, il che è positivo! Ma ovviamente hai anche una coesione estremamente bassa, perché tutti i metodi della tua classe dovranno fare cose diverse.

D'altra parte, considera la possibilità di suddividere le cose in così tante classi, che ognuna di esse contiene solo un singolo piccolo metodo. Ciò significa che hai una coesione molto alta, che è di nuovo buona, ma per fare il lavoro vero, questi metodi dovrebbero accedere a molte altre classi. Queste dipendenze significano anche un accoppiamento molto elevato, il che non va bene.

Tradeoff

Essenzialmente, finisci con un compromesso: concentrati sulla coesione e perdi l'accoppiamento. Concentrati sull'accoppiamento e perdi la coesione. Per fare una buona scelta su dove dovresti andare su quella scala di tradeoff, l'accoppiamento e la coesione sono criteri insufficienti. Invece si dovrebbe guardare ad altri criteri di qualità del codice, e vedere dove sono sulla scala che ti portano.

Ad esempio, l'SRP ti dà una buona coesione, e ci sono persone che sostengono questa come l'unica verità, ma ovviamente se segui lo SRP molto rigorosamente, finisci con un sacco di classi e un elevato accoppiamento. A volte, potresti scoprire che tutto questo accoppiamento ti dà molti problemi. In tal caso puoi giustificare che vale la pena ridurre l'accoppiamento al costo della coesione violando l'SRP (o diciamo solo reinterpretando ciò che la singola reponsabilità è).

Come approccio di best practice, credo che l'SRP sia una scommessa salva. In generale, l'accoppiamento elevato è più problematico della bassa coesione, semplicemente perché troviamo più facile affrontare un problema localizzato in una classe (coesione). Pertanto, se segui l'SRP, ti condurrà verso la fine dell'accoppiamento basso della scala di tradeoff, che è per lo meno un buon punto di partenza.

In genere ho una classe per ciascuna delle mie tabelle, più il numero di enumerazioni necessarie per i campi enumerati, oltre ai servizi dati e ai controlli utente e tutti i tipi di materiale. Gli unici WTF che ottengo provengono dagli utenti, sebbene la frequenza sia misurata in ore, non in minuti.

Dato che non ci sono discussioni specifiche sul linguaggio, posso solo seguire quello che faccio in C #. Generalmente cerco di creare schemi di disegno altamente ripetibili, in modo che chi guarda una classe trovi praticamente qualcosa di simile negli altri. Non sono sicuro di come avrei potuto "ridurre il numero" date le mie regole di progettazione.