È sempre una buona idea dividere le grandi classi in quelle più piccole? [duplicare]

Mi sembra che il principio fondamentale da applicare qui sia il Principio di responsabilità singola . Ogni classe ha una responsabilità singola, chiaramente articolata e ben delimitata?

Nota che non intendo "ogni classe fa una cosa". Ad esempio, un repository "Media tra il dominio e i livelli di mapping dei dati utilizzando un'interfaccia simile a una raccolta per l'accesso al dominio oggetti. " Ma potrebbe ancora avere diversi metodi che realizzano parti di questa responsabilità generale.

Se trovi che una responsabilità chiaramente articolata e ben delineata che dovrebbe essere contenuta in una singola classe con più metodi viene invece suddivisa su molte classi più piccole, allora le tue classi stanno diventando troppo piccole.

Presumo che tu sia su un progetto legacy in cui non eri colui che ha sviluppato il codice. Sono in una situazione simile.

A mio parere, non toccare il codice a meno che:

1. Ti è stato assegnato un refactoring da un superiore.

2. In effetti sei un ragazzo anziano che conosce il codice dentro e fuori.

Altrimenti dovrei dire che applicherei la legge "se non è rotta, non aggiustarla". Mentre è abbastanza probabile che tu possa ottenere una modulazione e un incapsulamento migliori rompendo classi enormi, potrebbe anche introdurre tonnellate di problemi che non ci sono al momento.

Is it a better idea, for code sanitation, to split our larger objects that do too much work into smaller objects?

Non si tratta della durata della lezione ma della responsabilità.

Potresti potenzialmente avere una lezione un po 'troppo lunga ma che si prende cura di una sola responsabilità. Quindi, sicuramente non andare per lunghezza.

Cerca invece di capire il problema che sta tentando di risolvere.

Se risolve un singolo problema, segue il principio di responsabilità singola e potresti lasciarlo come è o DI alcuni dei suoi metodi privati come classi di aiutanti.

Se noti che si sta prendendo cura di più di una responsabilità, non importa per quanto tempo la classe suggerirei di scomporla in due o comunque di molte responsabilità necessarie per far sì che tutte si occupino di preoccupazioni singolari.

Ci sono un paio di principi che si applicano qui

• Principi di progettazione SOLID per OO Il principale che si applica alla tua descrizione è single responsibility principle . Sebbene il Interface segregation principle per sua natura tenda a mantenere le dimensioni delle classi ragionevoli.

• Domanda di refactoring Quindi, mentre è meglio mantenere le classi più piccole, la decisione di refactoring è più cokiforme.

  Hai buoni casi di test.
  Con buoni casi di test puoi essere più avventuroso con il refactoring. Ma come al solito se gli sviluppatori originali stavano facendo compilare OO con un buon set di classi di test, allora avrebbero già effettuato il refactoring.

  È stato necessario modificare la classe estesa? Se devi cambiare qualcosa, è spesso un punto in cui un refactor può valere l'investimento.

  Refactoring per renderlo più elegante Per quanto sia bello avere un codice pulito e di facile manutenzione, senza problemi di manutenibilità sufficienti è molto difficile giustificare il refactoring per l'eleganza.

Quando refactoring blog, vale la pena dare un'occhiata

Se ti capita di avere un abbonamento pluriennale, c'è un corso eccellente su questo argomento refactoring al plurale - si applica la quota di iscrizione