¿Hay un nombre para el concepto de jerarquía de muchos métodos cortos en una clase?

7

Una refactorización que comúnmente hago es donde me encuentro con un método grande como

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

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

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

y use el método de extracción refactorizándolo para hacerlo así:

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

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

Sé que los beneficios de esto son que la duplicación tiende a detectarse más fácilmente, los comentarios se reemplazan por métodos descriptivos y los métodos se pueden probar con una granularidad más fina. Además, en una clase grande puede ser más fácil aislar y agrupar una selección de métodos / campos como candidato para extraer a una nueva clase.

Pero, lo que es más importante, significa que si veo doSomething () por primera vez, es posible que solo necesite leer 3 líneas de código para saber qué hace en lugar de 7. Si no lo hago completamente Entiendo doEvenMore (), puedo elegir leer el método y así sucesivamente, trabajando a través de la clase como una jerarquía. Efectivamente, comienzo a leer un método de punto de entrada corto y solo necesito leer los métodos inferiores en cualquier clase cuando necesito profundizar más.

Entonces, mi pregunta: ¿existe un nombre para este concepto en la programación y cuál es la forma más fácil y concisa de explicarlo o demostrarlo? A veces me resulta difícil explicar a los colegas los beneficios de por qué es bueno dividir métodos grandes, incluso cuando estos nuevos métodos solo se llaman desde un lugar.

EDITAR: Intentaré ser más claro: no estoy preguntando sobre el concepto de métodos de extracción, sino sobre el principio que hace que los métodos de extracción sean la opción correcta en este caso, por ejemplo. Si tuviera un código duplicado en el método original, extraería un método debido al principio DRY . En el caso anterior no lo hago, pero sigue siendo bueno extraer los métodos debido al principio X. ¿Qué es X?

    
pregunta Alb 22.04.2011 - 01:13

5 respuestas

8

Es un patrón de refactorización común llamado "Método de extracción".

Martin Fowler y Kent Beck explicaron el concepto de esta manera en su gran libro Refactorización: Mejora del diseño del código existente :

  

El método de extracción es uno de los más   refactorizaciones comunes que hago ...

     

... prefiero métodos cortos y bien nombrados para   Muchas rasones. En primer lugar, aumenta   las posibilidades que otros métodos pueden usar   un método cuando el método es finamente   granuloso Secod, permite la   métodos de nivel superior para leer más como   Una serie de comentarios.

Otros beneficios son: el método original ahora es más corto y posiblemente más fácil de comprender, y el cuerpo de lógica eliminado y colocado en su propio método ahora es más fácil de probar.

El resultado de este proceso de refactorización se llama " cohesión fuerte ". La cohesión se refiere a qué tan cerca están relacionadas las operaciones en un método. En particular, esto sería lo que Steve McConnell denomina cohesión funcional en su libro Code Complete .

  

El objetivo es que cada rutina haga   una cosa bien y no hacer nada   otra cosa.

     

La cohesión funcional es la más fuerte   y el mejor tipo de cohesión, ocurriendo.   cuando una rutina realiza uno y solo   una operación.

    
respondido por el Eric King 22.04.2011 - 01:32
3

Creo que estás buscando la expresión "una clase (o método) que se lee como un artículo de un periódico", tomado del libro del tío Bob Clean Code . Comenzamos en la parte superior con declaraciones importantes y profundizamos en detalles si nos importa.

    
respondido por el louisgab 22.04.2011 - 03:30
1

Esto parece un ejemplo de Principio de Responsabilidad Única . Si tienes un método grande y complejo, es probable que sea demasiado. Dividirlo en métodos más pequeños y concisos puede hacer que el código sea reutilizable y mantenible.

    
respondido por el GSto 22.04.2011 - 01:17
1

Este es un ejemplo perfecto del método de extracción Extract Method . También tiene algunas similitudes con el patrón Template Template , donde el código se divide en un método esqueleto que describe la lógica, y métodos de bajo nivel que implementan pasos individuales (y podrían ser anulados en subclases).

    
respondido por el Adam Byrtek 22.04.2011 - 01:27
0

Lo que has hecho es restar el "punto de entrada" a lo que hablamos en diseño. Llamaría un patrón codificado .

Una forma de visualizar este patrón es imaginar un control remoto programable.

En este caso, todos los botones están ahí, pero el control remoto no ha sido programado para hacer más de una cosa (sea cual sea el punto de entrada):

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

Esto está bien, considerando tus intenciones. Solo mientras pones el pensamiento adecuado en los modificadores de acceso. Esto podría convertirse en un punto importante si tiene varios Puntos de entrada. Puede haber potencial para implementar el patrón cmd para reducir la cantidad de código que necesita mantener en todo el proyecto.

También estoy de acuerdo en que SRP, el método de extracción y la cohesión son (o deberían ser) las pautas utilizadas para llegar a este punto.

    
respondido por el P.Brian.Mackey 22.04.2011 - 02:00

Lea otras preguntas en las etiquetas