design-patterns - reusable - factory design pattern c++

¿Cuándo deberíamos crear un nuevo método? (19)

Estoy tratando de averiguar si existe un consenso sobre cuándo deberíamos crear un nuevo método en nuestro código. Por ejemplo, si solo vamos a usar el código nuevamente, crearemos un nuevo método / función (por lo tanto, obviamente reduciremos las líneas utilizadas) o también es común hacerlo para evitar el desorden del código. He estado programando durante mucho tiempo, pero en realidad acabo de entrar y decidí de manera bastante aleatoria.

¿Hay algún patrón de diseño o libros que se ocupen de esto? Una pregunta relacionada sería si solo debemos establecer parámetros en un objeto utilizando los métodos getter y setter. Esto crearía mucho más código obviamente, pero ¿haría las cosas más manejables? ¿Algún consenso sobre eso?

Introduce métodos nuevos incluso si solo se llama una vez para limitar la máxima complejidad ciclomática

En la parte superior de mi cabeza puedo enumerar muchas razones para extraer métodos y pocos o ninguno para combinarlos.

El más obvio, DRY, aka DIE . Seguí esta filosofía antes de que creciera acrónimos fríos. No creo que uno deba, por alguna razón, duplicar o copiar y pegar código, sin importar cuán corto sea. Si lo haces, estás incubando una pesadilla.
Para limitar la complejidad ciclomática . Es mucho mejor tener 3 métodos comprensibles que un método confuso. Esta regla y otras se aplican incluso si el nuevo método extraído solo se llama una vez
Para sacar una unidad de funcionalidad para pruebas unitarias
Para mantener todos los métodos visibles en los editores sin desplazarse

Por cierto, podría sugerir un cambio en el lenguaje. " Crear un nuevo método " suena como agregar algo al código y hacerlo más grande y más complejo. Pero " extraer un método " es lo que realmente sucede cuando se refactoriza a un diseño con suerte superior. Asumiendo que tienes que tener esa funcionalidad de todos modos, ese método siempre estaba ahí, simplemente estaba enterrado dentro de otro ...

Además de la excelente respuesta de Graviton , recomiendo otra regla práctica para decidir cuándo crear un nuevo método:

Cada vez que sienta la inclinación de escribir un comentario para un fragmento de código, mueva ese código a una función dedicada en su lugar. Proporcione un nombre descriptivo para la función.

Considero la programación como un arte. Como tal, divido los métodos cuando me parece correcto dividirlos o escribir uno nuevo.

Dicho esto, hay algunas reglas de pulgar (que no anulan mis instintos).

Si necesita desplazarse por la pantalla para leer un método, debe dividirlo
SI tiene deja vue (el código que escribe le parece familiar) probablemente se esté repitiendo a sí mismo, lo que significa que debe usar una función / método existente y no escribir uno nuevo.
No más de dos constructos de profundidad
para (...) para (...) para (...) MALO
No más de un ciclo en una fila (uno después del otro).
Si necesita devolver más de un tipo de datos (una versión nula / falsa no lo es), entonces necesita dividir algo.
Si te confundes al leer tu método, divídelo
Un método / función debería ser responsable de una tarea.
El más obvio: al escribir nuevas funcionalidades :-)

Crea un método para realizar una tarea específica. Si el método crece en tamaño, eso significa que tiene algunas subtareas, por lo que debe separar (refactorizar) las subtareas en un nuevo método.

Creo que esta es una pregunta muy subjetiva sin una respuesta real. Las diferentes situaciones exigen soluciones diferentes, y no habrá una sola receta de "cuándo crear un nuevo método". Depende.

Creo que no hay pautas de diseño específicas para esto. Pero algunos de los principios de diseño sí hablan sobre la creación de métodos.

DRY (no te repitas) es un principio rector cuando se trata de la creación de métodos. Agrupe una lógica similar en un solo método para que no los duplique en todo su código y, por lo tanto, haga que el mantenimiento sea una pesadilla.

El Principio de Responsabilidad Individual es otro. Dice que tu clase o método solo debe hacer una cosa. Esto es para hacer que el tamaño del método sea pequeño.

Cuando comienzas a poner espacios dobles entre bloques de código para representar diferentes responsabilidades.

Echa un vistazo a Clean Code by Robert Martin que cubre esto (entre otras cosas)

En última instancia, no desea repetirse, de acuerdo con el principio DRY (que usted y algunas otras personas ya mencionaron). También depende del idioma que estés usando. Una gran cantidad de lenguajes orientados a objetos hacen que todos sus métodos sean públicos (por ejemplo, Objective-C) y, por lo tanto, solo querría crear funciones destinadas a ser llamadas por otros objetos. Por otro lado, muchos lenguajes, como Java, proporcionan funciones privadas que respaldan el concepto de agrupar bloques de código en funciones privadas que en realidad no están destinadas a ser utilizadas fuera de la clase misma.

Es posible que desee extraer un método si:

hay un bloque de comentarios para un fragmento
puedes nombrar el intento de un pedazo

La mayoría de los métodos deben realizar una tarea.

Practique la prueba unitaria de su código y divida los métodos para que pueda realizar una prueba unitaria por tarea. Esta es una gran manera de hacer que todo el asunto sea menos subjetivo, al tener una restricción externa real de poder probar cada tarea por separado.

SLAP y DRY son los buenos principios. Consulte este enlace http://tv.devexpress.com/SLAPrule.movie muy buena charla del Sr.Julian. [Parece que el sitio de videos no funciona por un tiempo. Por favor, ver más tarde]

Un método debería hacer una cosa, y hacerlo bien. No debería hacer nada más ni menos de lo que su nombre implica. Un método CustomerSave no debería normalizar también la dirección del cliente.

Un método debe estar relacionado con un solo "nivel" de funcionalidad. Si aparece más de una línea de código en un método CustomerSave para cada uno de los siguientes: abrir la base de datos, registrar cambios, verificar la seguridad, etc., entonces el código está funcionando en el nivel incorrecto, y se deben crear nuevos métodos para tratar con estas cosas en la granularidad adecuada.

Un método generalmente debe ser muy corto. Solo en circunstancias especiales, un método debe pasar por más de una pantalla. Si un método tiene cien líneas, entonces algo está muy, muy mal.

El código no debe ser repetitivo. La funcionalidad duplicada debe colocarse en un método.

Los métodos deben diseñarse de manera que los tipos típicos de cambios se puedan realizar fácilmente. Si se necesita hacer un pequeño cambio en docenas de lugares, eso indica un código repetitivo que debería haberse colocado en un único método.

Un punto interesante, aunque no relacionado con la programación orientada a objetos, está hecho en la guide estilo de codificación de Linux:

Capítulo 4: Funciones
Las funciones deben ser cortas y dulces, y hacer solo una cosa. Deben caber en una o dos pantallas de texto (el tamaño de la pantalla ISO / ANSI es 80x24, como todos sabemos), y hacer una cosa y hacerlo bien.
La longitud máxima de una función es inversamente proporcional a la complejidad y al nivel de indentación de esa función. Por lo tanto, si tiene una función conceptualmente simple que es solo una declaración de caso larga (pero simple), donde tiene que hacer muchas cosas pequeñas para muchos casos diferentes, está bien tener una función más larga.
Sin embargo, si tiene una función compleja y sospecha que un estudiante de primer año de secundaria que no sea tan talentoso ni siquiera podría entender de qué se trata la función, debe adherirse a los límites máximos más de cerca. Use funciones auxiliares con nombres descriptivos (puede pedirle al compilador que los incluya en línea si cree que es crítico para el rendimiento, y probablemente lo haga mejor que lo hubiera hecho).
Otra medida de la función es el número de variables locales. No deben exceder 5-10, o estás haciendo algo mal. Vuelva a pensar la función y divídala en pedazos más pequeños. Un cerebro humano generalmente puede realizar un seguimiento de aproximadamente 7 cosas diferentes, cualquier cosa más y se confunde. Sabes que eres brillante, pero tal vez te gustaría entender lo que hiciste dentro de 2 semanas.

Una vez escuché a alguien decir que si un método / función llega a ser demasiado grande para caber en una sola pantalla sin desplazarse, entonces debería refactorizarse en métodos separados.

No siempre es cierto y no hay ningún valor en la refracción para refactorizaciones, pero a menudo ayuda a mantener las cosas en perspectiva.

geters y setters OOP no lo son, y la mayoría de las veces solo duplican el tamaño del código para nada bueno.

en cuanto a los libros: Patrones de diseño (Gamma, Vlissides, Johnson, Helm), libros de Fowler (refactorización, patrones de arquitectura de aplicaciones empresariales), libros de Beck (Desarrollo basado en pruebas mediante ejemplos, patrones de implementación), etc.

Casi siempre deberías crear un nuevo método cuando estás repitiendo el código.

Elimina el código repetido, y es autodocumentado si elige un buen nombre.

La misma línea de código que aparece en dos lugares no es demasiado corta para hacer un método, a menos que la línea sea trivial y su intención sea extremadamente obvia.

Si sus métodos son muy largos, tiene sentido volver a factorizarlos en trozos más pequeños, incluso si estos trozos no se utilizan en ningún otro lado. Esto aumentará la facilidad de mantenimiento y la capacidad de prueba. Además, con este enfoque, permite que otros desarrolladores amplíen su código más fácilmente en caso de que deseen cambiar ciertas responsabilidades de un método, por ejemplo, al sobrecargarlo.

En cuanto a getters y setters, de alguna manera depende del idioma que use. En algunos idiomas esto puede ser bastante detallado. Personalmente, solo proporciono getters y setters para propiedades públicas y / o si cambiar una propiedad involucra lógica más allá de simplemente establecer / obtener la propiedad.