Rendere ogni oggetto generico è sciocco.
Rendere ogni oggetto specifico è sciocco.
Ogni oggetto dovrebbe avere un nome che assicuri che ciò che si trova all'interno non sia una sorpresa. Dovrebbe chiarire cosa vi appartiene al suo interno e cosa appartiene all'esterno. Altrimenti qualcuno lo riempirà di confusione. L'interno dovrebbe assomigliare al tuo cassetto di argenteria. Non il tuo cassetto della spazzatura. Può accettare più messaggi (hanno molti metodi) ma il lavoro dovrebbe concentrarsi su una sola idea. Dovrebbe avere una singola responsabilità. Dovrebbe essere l'unico e unico posto in cui è necessario apportare modifiche quando si modifica la decisione relativa al design a cui si rivolge.
Quanto generico o specifico dovrebbe essere dipende da quanto è lontano da input o output. Tutto ciò che è vicino a qualsiasi tipo di I / O (file, DB, interfaccia grafica, web, controlli, ecc.) Dovrà essere specifico e cambierà spesso. Qualunque cosa lontana dall'IO e dalla politica di alto livello sarà più generica e stabile.
Sii disposto a rimanere specifico ignorando i casi che possono essere rinviati a diversi oggetti fratelli che possono sopportare questo, piuttosto che progettare quello attuale per gestire ogni caso.
Siate disposti a rimanere generici spingendo in modo responsabile ad affrontare i casi in cui escludono completamente l'oggetto e i collaboratori che possono gestirli senza fare in modo che questo oggetto abbia a che fare con i loro dettagli.
Quindi come sapere quando è troppo?
Quando i compiti degli oggetti diventano poco chiari. L'uso dell'oggetto dovrebbe essere ovvio. Se metà dell'oggetto è a un livello di astrazione e l'altra metà a un altro, si svilupperà una tendenza a circondare il suo uso con una logica extra, mantenendolo in supporto vitale. Quando l'oggetto è ben progettato, il codice usando sarà semplice e pulito.
Guarda sempre come verrà usato un oggetto. Progetto spesso scrivendo prima il codice usando. Fai questo e controllando quanto è astratto cadrà naturalmente.