¿Vale la pena extraer métodos privados para el código que solo se llama una vez en una clase, o dejar el código en el método principal (tal vez) con un comentario que dice lo que hace?¿Debería refactorizar el código en métodos privados si no se llaman más de una vez?
Siempre vale la pena extraer métodos si aclara la intención del código.
Esto es especialmente cierto para métodos muy largos. Si bien los comentarios son correctos, no definen (al menos no de manera muy sólida) dónde termina el proceso que explica y dónde comienza el próximo. A veces, las abstracciones comunes solo serán más obvias después de que ha extraído el método.
Si le gustan las pruebas unitarias automatizadas (no necesariamente TDD), también será mucho, mucho más fácil probar los trozos de métodos más pequeños, aunque podría tener que hacer públicos sus métodos para eso, dependiendo de la marco de prueba que utiliza.
El punto es que no se puede equivocar con métodos más pequeños, especialmente si tienen nombres descriptivos.
Estoy muy de acuerdo. Me refactoro de esta manera todo el tiempo y el grado en que agrega legibilidad al código es tremendo. La abstracción es muy útil incluso hasta el nivel de un método corto (por ejemplo, 1 línea). Refactorizar de esta manera hace que sea tremendamente más fácil ver el flujo de su método original y cambiar el diseño o la implementación del método principal o cualquier componente del mismo. – Wedge
He estado pensando en esta respuesta. Creo que deberías cambiar "no puedes equivocarte con métodos más pequeños, especialmente si tienen nombres descriptivos". a "Solo puede salir mal si los métodos NO TIENEN nombre descriptivo" – mcintyre321
¡Por supuesto! Mientras más pequeños sean sus métodos, más fácil será mantener su software.
¿Qué pasa con 1-liners? Si ese es el nivel de encapsulación que necesitas, entonces eso es todo. Creer que un método de 1 línea no es "lo suficientemente sustancial" como para ser un "método real" es intelectualmente limitante. Comience a buscar métodos de una línea que puedan extraerse que serían útiles, probablemente encontrará más de lo que cree. – Wedge
Sí, tienes toda la razón, no debería haber declarado "(Bueno, los de una sola línea no serían demasiado útiles, por supuesto)" de una manera tan definitiva ... No sé cómo escribirlo mejor entonces ya lo hiciste, así que supongo que eliminaré esa frase. :-) ¡Gracias! – Arjan
Existe una gran ventaja al hacer esto. Se trata de ocultar información y hacer que las intenciones sean muy claras.
En Refactoring to Code llamaron a este método de composición donde se divide un método grande en muchos métodos más pequeños. Esto hace dos cosas.
Primero, reduce la cantidad de información que necesita para preocuparse cuando se trabaja en el método principal.
En segundo lugar, el nombre del método debe indicar su intención, lo que hace que el código sea más legible.
También hace que los problemas de alcance variable sean mucho, mucho más fáciles. Escanear 100 líneas de código para descubrir dónde se usan las variables es una pérdida de tiempo no trivial en comparación con el examen de un método de menos de una docena de líneas. – Wedge
Sí, lo es.
Un punto adicional: para los métodos simples de ayuda, puede querer hacerlos estáticos (de modo que no dependan ni alteren el estado de su instancia), luego puede hacerlos públicos para una reutilización aún más fácil.
Para mí, depende de qué tan grande es el código, y qué tan relacionado está con lo que hace el método padre. Si es una gran cantidad de código (digamos más de 5-10 líneas de código, o más del 50% de la cantidad total de código en el método principal) lo extraería a un método privado, para la estructura del código y la legibilidad. De lo contrario, lo dejaría en el método principal con un comentario descriptivo.
Creo que el mantenimiento y la legibilidad pueden degradarse si hay demasiados métodos, muy pequeños, en el código. Me esfuerzo por un buen equilibrio. Pero cada vez que dudo; Lo extraigo como un método privado.
Simplemente una estimación estúpida, pero diría que la mayoría de los métodos privados solo se llaman en un par de lugares en la clase promedio. Sin embargo, como se mencionó anteriormente, hace que su código sea mucho más legible y más fácil de probar/mantener si divide todas las funcionalidades en bloques lógicos.La refabricación es un buen hábito
Debe refactorizar a privado en función del diseño de sus métodos & de API/propiedades que desee exponer cuando utilice en otro lugar. No debe considerar su uso para decidir si lo hace privado/público o no.
En algún resumen ideal no habría ningún comentario. O eso, o su * comentario * sería el código de la Programación Alfabetizada de Knuth. –