Esiste un nome per il concetto di una gerarchia di molti metodi brevi in una classe

Question

Esiste un nome per il concetto di una gerarchia di molti metodi brevi in una classe

#1 da (8 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (1 voti)
#5 da (0 voti)

7

Un refactoring che faccio comunemente è dove mi imbatto in un metodo di grandi dimensioni come

public void doSomething() {
    // do First thing
    doPartA1();
    doPartA2();

    //now something else
    doSomethingElse();
    doMoreSomethingElse();
    doEvenMore();

    // finally do this stuff
    someStuff();
    someMoreStuff();
}

e usa il metodo di estrazione che lo refactoring per renderlo simile a questo:

public void doSomething() {
    doFirstThing();
    doSomethingElse();
    doStuff();
}

private void doFirstThing() {
    doPartA1();
    doPartA2();
}
...

So che i vantaggi di questo sono che la duplicazione tende a essere individuata più facilmente, i commenti sono sostituiti da metodi descrittivi e metodi possono essere testati con una granularità più fine. Inoltre, in una classe estesa può essere più facile isolare e raggruppare una selezione di metodi / campi come candidato per l'estrazione in una nuova classe.

Tuttavia, penso che la cosa più importante sia che se guardo a DoSomething () per la prima volta, posso solo leggere 3 righe di codice per sapere cosa fa invece di 7. Se non lo faccio completamente capisci doEvenMore (), posso scegliere di leggere il metodo e così via, elaborando la classe come una gerarchia. In effetti, comincio a leggere un breve metodo di inserimento e ho solo bisogno di leggere i metodi più bassi in qualsiasi classe quando ho bisogno di approfondire più a fondo.

Quindi, la mia domanda - c'è un nome per questo concetto nella programmazione e qual è il modo più semplice e conciso per spiegare o dimostrarlo? A volte ho trovato difficile spiegare i vantaggi ai colleghi perché è bene suddividere metodi di grandi dimensioni, anche quando questi nuovi metodi vengono chiamati da un unico punto.

EDIT: cercherò di essere più chiaro: non sto chiedendo il concetto di metodi di estrazione, sto chiedendo il principio che rende i metodi di estrazione la scelta giusta in questo caso, ad es. Se avessi il codice duplicato nel metodo originale, estraperei un metodo a causa del principio ASCIUTTO . Nel caso sopra non lo faccio, ma è comunque buono estrarre i metodi a causa del principio X. Cos'è X?

code-quality refactoring extreme-programming

posta Alb 22.04.2011 - 01:13

fonte

5 risposte

Leggi altre domande sui tag code-quality refactoring extreme-programming

È possibile utilizzare il codice C ++ in un'app per iPhone obiettivo Miglior algoritmo / pratica quando si crea un meccanismo di ricerca per il proprio database? [chiuso]

score 8 · Answer 1

È un pattern di refactoring comune chiamato "Extract Method".

Martin Fowler e Kent Beck hanno spiegato il concetto in questo modo nel loro grande libro Refactoring: migliorare il design del codice esistente :

Extract Method is one of the most common refactorings I do ...

... I prefer short, well-named methods for several reasons. First, it increases the chances that other methods can use a method when the method is finely grained. Secod, it allows the higher-level methods to read more like a series of comments.

Altri vantaggi: il metodo originale ora è più breve e concepibilmente più facile da comprendere e il corpo della logica rimosso e inserito nel proprio metodo è ora più facile da testare.

Il risultato di questo processo di refactoring si chiama " strong coesione ". La coesione si riferisce a quanto strettamente correlate le operazioni in un metodo. In particolare, questo sarebbe ciò che Steve McConnell definisce coesione funzionale nel suo libro Codice completo .

The goal is to have each routine do one thing well and not do anything else.

Functional cohesion is the strongest and best kind of cohesion, occurring when a routine performs one and only one operation.

score 3 · Answer 2

Penso che tu stia cercando l'espressione "una classe (o metodo) che legge come un articolo di giornale", preso in prestito dal libro di Zio Bob Pulisci codice . Iniziamo in cima con affermazioni importanti e analizziamo i dettagli se ci interessa.

score 1 · Answer 3

1

Questo è un esempio del principio di responsabilità singola . Se hai un metodo ampio e complesso, probabilmente lo stai facendo molto. Rompenderlo in metodi più piccoli e più succinti può rendere il codice riutilizzabile e mantenibile.

risposta data 22.04.2011 - 01:17

fonte

score 1 · Answer 4

Questo è un perfetto esempio del refactoring Extract Method . Ha anche alcune somiglianze con il modello Metodo modello , in cui il codice è suddiviso in un metodo scheletro che descrive la logica e metodi di basso livello che implementano i singoli passaggi (e potrebbero essere sovrascritti in sottoclassi).

score 0 · Answer 5

Ciò che hai fatto è stato spogliato del "punto di ingresso" fino a ciò che in progettazione parlo, definirò un schema di comando a>.

Un modo per visualizzare questo modello è immaginare un telecomando programmabile.

In questo caso i pulsanti sono tutti lì, ma il telecomando non è stato programmato per fare più di una cosa (qualunque sia il punto di ingresso):

EntryPointButtonPush()
{
   Button1()
   Button3()
   Button2()
}

Questo sì, considerando le tue intenzioni. Solo finché metti il pensiero appropriato nei modificatori di accesso. Questo potrebbe diventare un punto importante se si hanno più Punti di Entrata. Potrebbe essere possibile implementare il modello cmd per ridurre la quantità di codice che è necessario mantenere attraverso il progetto.

Sono anche d'accordo che SRP, metodo di estrazione e coesione sono (o dovrebbero essere) le linee guida utilizzate per arrivare a questo punto.