Come si refactoring una classe di Dio?

Question

Qualcuno sa qual è il modo migliore per rifattorizzare un oggetto-Dio?

Non è così semplice come suddividerlo in un numero di classi più piccole, perché esiste un elevato metodo di accoppiamento. Se estraggo un metodo, di solito finisco per tirare fuori ogni altro metodo.

Answer 1

È come Jenga. Avrai bisogno di pazienza e una mano ferma, altrimenti devi ricreare tutto da zero. Che non è male, di per sé - a volte uno ha bisogno di buttare via il codice.

Altro consiglio:

• Pensare prima di tirare fuori metodi: su quali dati questo metodo funziona? Che responsabilità ha?
• Provare a mantenere l'interfaccia della classe dio all'inizio e delegare le chiamate alle nuove classi estratte. Alla fine la classe di Dio dovrebbe essere una pura facciata senza la propria logica. Poi si può tenerlo per convenienza o buttarlo via e iniziare a utilizzare le nuove classi solo
• unit test di aiuto: scrivere dei test per ciascun metodo prima di estrarlo per assicurare non rompere la funzionalità

Answer 2

Presumo "Oggetto divino" significa una grande classe (misurata in linee di codice).

L'idea di base è estrarre parti delle sue funzioni in altre classi.

Al fine di trovare quelli che si possono cercare i

• campi/parametri che spesso vengono usati insieme. Potrebbero spostarsi insieme in una nuova classe

• metodi (o parti di metodi) che utilizzano solo un piccolo sottoinsieme dei campi della classe, il quale potrebbe spostarsi in una classe contenente solo quel campo.

• tipi primitivi (int, String, booleano). Spesso sono oggetti di valore prima della loro uscita. Una volta che sono oggetti di valore, spesso attirano metodi.

• esaminare l'utilizzo dell'oggetto dio. Esistono diversi metodi utilizzati da diversi clienti? Questi potrebbero andare in interfacce separate. Queste interfacce potrebbero a loro volta avere implementazioni separate.

Per effettivamente facendo questi cambiamenti si dovrebbe avere qualche infrastruttura e gli strumenti al tuo comando:

• Test: Avere un (forse generato) insieme esaustivo di test pronti che è possibile eseguire spesso. Sii estremamente attento alle modifiche che fai senza test. Li faccio, ma li limito a cose come il metodo di estrazione, che posso fare completamente con una singola azione IDE.

• Controllo versione: si desidera disporre di un controllo di versione che consente di eseguire il commit ogni 2 minuti, senza rallentare realmente. SVN non funziona davvero. Git fa.

• Metodo Mikado: l'idea del metodo Mikado è provare un cambiamento. Se funziona alla grande.Se non prendi nota di cosa si sta rompendo, aggiungili come dipendenza dal cambiamento che hai iniziato. Rollback si cambia. Nel grafico risultante, ripetere il processo con un nodo che non ha ancora dipendenze. http://mikadomethod.wordpress.com/book/

Answer 3

Prima di iniziare: Come sapevi che una classe Dio è cattivo?

o almeno come si misura la classe di Dio?

Cerca di trovare un limite e le differenze tra classe di buona-grande-classe e cattiva-dio.

Ad esempio: la classe con alcuni helper, proprietà e metodi di utilizzo incorporati aggiuntivi, è un candidato per essere una classe di Dio in futuro, ma può anche essere un ottimo codice.

Credo che la classe di Dio sia solo un corpo di grande classe con un refactoring dimenticato o posticipato, ma una ragione per cui il refactoring cresce nel tempo.

consiglio

Generale: ecco un utilizzo di:

• eredità e mixins,
• delega (es: per utils file, esterno classi, API/facciata),
• splitting classe: sottoclassi aggiunta o classi correlate,
• utilizzando buon modello, come SOLID,
• sviluppare in te stesso l'arte di refactoring,