Nonostante molti anni nel settore IT, continuo a lottare con il design OO. Un problema particolare che mi sembra di finire è quello di classi grandi, spesso contenenti molte centinaia di righe di codice.
Il mondo OO parla molto di SRP, e io potrei sostenere che queste grandi classi con cui finisco gestiscono ciascuna una singola responsabilità. La natura complessa dell'app (un sistema di elaborazione dati scientifico) significa che una di queste responsabilità richiede un sacco di codice! Per esempio. una classe potrebbe avere un solo metodo pubblico Calculate() , ma potrebbero esserci 15-20 o più metodi privati per supportare questa operazione.
Dove possibile estrarrò i metodi in classi separate per la riutilizzabilità, ma spesso c'è poco o nessun margine per questo. Una parte di me dice che dovrei dividere queste grandi classi solo per migliorare la leggibilità (ad esempio raggruppando metodi simili nelle loro classi), ma i tempi che ho fatto mi sembrano un esercizio sprecato - tutto quello che ho fatto è diffondere i metodi in giro, ha creato più dipendenze di classe e ha reso le cose un po 'più difficili da trovare per altri sviluppatori.
Ma poi leggo articoli in cui gli sviluppatori parlano di come tutte le loro classi siano abbastanza piccole da adattarsi allo schermo senza scorrere, e temo che sto facendo qualcosa di sbagliato! In un precedente lavoro, ho lavorato su un sistema in cui era stato OO all'estremo, ed era comune vedere classi contenenti un solo metodo, spesso con non più di una o due righe di codice. Personalmente ho trovato questo difficile trovare il modo di aggirare il codice base e di eseguire il debug, e per questo motivo (e il numero assoluto di classi) potrei sostenere che diventa più difficile da mantenere, non l'obiettivo di un buon design OO. Immagino sia dovuto al gusto personale.
Quindi, è accettabile avere grandi classi o puoi suggerire altri modi con cui potrei gestirmi?