Decomposizione in java, quando è abbastanza sufficiente?

Question

Sono uno studente di informatica del primo anno. Attualmente stiamo programmando in java e spesso provo a scomporre il mio programma in metodi ben denominati in modo che la mia logica del metodo principale possa leggere il più vicino possibile allo pseudo-codice.

Il problema che trovo è che spesso sto finendo di scrivere così tanti piccoli metodi privati ​​che sento che potrei esagerare. Esistono buone regole empiriche o considerazioni stilistiche da prendere in considerazione quando si decide di scomporre ulteriormente un problema?

Answer 1

La maggior parte dei nuovi sviluppatori va dall'altra parte: enormi funzioni che hanno molte responsabilità. La tua situazione è infinitamente preferibile a questo!

C'è davvero un piccolo svantaggio nella creazione di molti piccoli metodi e un sacco di vantaggi!

metodi brevi sono:

• Più facile da riutilizzare
• Più facile per testare
• Più facile da leggere e comprendere
• facile eseguire il debug

Considerando questo, vorrei suggerire che Rimpiazzate senza pietà la duplicazione in piccoli metodi. Il tuo IDE ti fornirà un metodo di refactoring di estrazione per renderlo più veloce.

Penso anche che il tuo obiettivo di generare una sorta di pseudo codice leggibile sia, in generale, buono. Gran parte del codice che vedi non sarà scritto in questo modo, ma può davvero aiutare la leggibilità e la nozione che "il codice è documentazione".

Alcune persone parleranno di un sovraccarico delle prestazioni delle chiamate al metodo, ma solo in casi molto rari sarebbe una preoccupazione per voi.

Modifica - Altri poster hanno menzionato il principio di responsabilità singola. Sebbene questa sia una buona linea guida, personalmente penso che vada oltre questo. Anche un frammento di codice che ha una responsabilità ben definita potrebbe potenzialmente essere scomposto per il riutilizzo e la leggibilità.

Answer 2

La mia filosofia è quella di suddividere il codice in singole unità logiche di lavoro atomiche. Qualcosa a cui di solito posso dare un nome - e poi metto quel lavoro in un metodo e gli diedi quel nome.

Answer 3

Penso che la parte più importante della rottura del codice sia Single Responsibility Principle (SRP). Ogni oggetto dovrebbe avere una singola responsabilità e tale responsabilità dovrebbe essere interamente incapsulata dalla classe

Answer 4

La regola empirica è la Single Responsibility Principle. Ogni unità di codice dovrebbe essere responsabile per esattamente una cosa. Questo vale sia per i metodi che per le classi. Se puoi mettere un nome semplice e conciso a ciascuno dei tuoi numerosi metodi privati, per, allora va bene. Se puoi solo descriverlo come "parte di" un'operazione più ampia, probabilmente non dovrebbe essere un metodo separato.

Ma dalla tua domanda, sembra che lo stai già facendo bene.

Answer 5

La mia regola generale è che se una funzione non si adatta su una singola schermata (si pensi a una vecchia linea da 80 terminali a 80 colonne), è meglio che ci sia una buona ragione. A volte c'è.Devi tenere a mente che in generale, chiunque legge la tua funzione deve capire l'intera cosa. Quando è lungo, è più difficile da fare.

Ciò detto, due o tre funzioni di linea non aggiungono molto. Spesso sono TROPPO facili da capire da soli e il nome che gli dai non fornirà tante informazioni quante il codice stesso quando incorporato in una funzione più lunga.

Ci sono sempre delle eccezioni. Non c'è alcun modo giusto. Il tuo lavoro migliorerà con l'esperienza.