TL; DR: depende de lo que estés tratando de resolver.
He tenido una conversación similar con mis Gramps sobre esto, mientras hablábamos sobre cómo Func y Action en C # son increíbles. My Gramps es un programador de temporizador muy antiguo, que ha estado relacionado con los códigos fuente desde que el software se ejecutó en computadoras que ocupaban toda una sala.
Cambió de técnico varias veces en su vida. Escribió código en C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java y finalmente comenzó C # como pasatiempo. Aprendí a programar con él, sentándome en su regazo mientras era más que un demonio, eliminando mis primeras líneas de código en el editor azul del SideKick de IBM. Cuando tenía 20 años, ya había pasado más tiempo programando que jugando afuera.
Esos son algunos de mis recuerdos, así que discúlpeme si no soy exactamente práctico mientras los vuelvo a contar. Me gustan mucho esos momentos.
Eso es lo que me dijo:
"¿Deberíamos buscar la generalización de un problema o resolverlo en el ámbito específico, preguntas? Bueno, esa es una ... pregunta".
Gramps hizo una pausa para pensar en ello por un breve momento, mientras fija la posición de sus lentes en su cara. Estaba jugando un juego de match-3 en su computadora, mientras escuchaba un LP de Deep Purple en su antiguo sistema de sonido.
"Bueno, eso dependería del problema que estés tratando de resolver", me dijo. "Es tentador creer que existe una solución única y sagrada para todas las opciones de diseño, pero no la hay. La Arquitectura de software es como el queso, ya ves".
"... ¿Queso, Gramps?"
"No importa lo que pienses sobre tu favorito, siempre habrá alguien que piense que huele mal".
Parpadeé confundido por un momento, pero antes de que pudiera decir algo, Gramps continuó.
"Cuando estás construyendo un automóvil, ¿cómo seleccionas el material para una pieza?"
"Yo ... supongo que depende de los costos involucrados y de lo que debería hacer la parte, supongo."
"Depende del problema que la parte está tratando de resolver. No fabricará una llanta de acero ni un parabrisas de cuero. Escogerá el material que mejor resuelva el problema que tiene a mano. Ahora, ¿Qué es una solución genérica? ¿O una específica? ¿A qué problema, a qué caso de uso? ¿Debería utilizar un enfoque funcional completo para dar la máxima flexibilidad a un código que se usará solo una vez? ¿Debe escribir un código muy especializado? Código frágil para una parte de su sistema que verá muchos y muchos usos, y posiblemente muchos cambios. Las opciones de diseño son como los materiales que selecciona para una parte en un automóvil o la forma del ladrillo Lego que elige para construir. Una casita. ¿Cuál es el mejor ladrillo de Lego? "
El programador de mayor edad tomó un pequeño modelo de tren Lego que tiene sobre su mesa antes de continuar.
"Solo puede responder eso si sabe para qué necesita ese ladrillo. ¿Cómo diablos sabrá si la solución específica es mejor que la genérica, o viceversa, si ¿Ni siquiera sabe qué problema está tratando de resolver? No puede ver más allá de una opción que no entiende ".
"... ¿Acaba de citar The Matrix? "
"¿Qué?"
"Nada, continúa"
"Bueno, supongamos que estás intentando construir algo para el Sistema Nacional de Facturas. Sabes cómo se ve esa API infernal y sus treinta mil líneas de archivos XML desde dentro. ¿Cómo sería una solución 'genérica' para crear ese archivo? El archivo está lleno de parámetros opcionales, llenos de casos que solo deberían usar sucursales muy específicas del negocio. En la mayoría de los casos, puede ignorarlos de manera segura. No es necesario crear un sistema de facturación genérico si es el único. Lo que alguna vez venderá es zapatos. Simplemente cree un sistema para vender zapatos y conviértalo en el mejor sistema de facturas para vender zapatos. Ahora, si tuviera que crear un sistema de facturas para cualquier tipo de cliente, de una forma más Aplicación general: para revender como un sistema de ventas genérico independiente, por ejemplo, ahora es interesante implementar aquellas opciones que solo se usan para Gas, alimentos o alcohol. Ahora esos son posibles casos de uso. Antes de que fueran solo algunos casos hipotéticos No usar , un d no desea implementar No usar casos. No usar es el hermano pequeño de No necesita . "
Gramps volvió a poner el tren lego en su lugar y regresó a su juego de combinaciones.
"Entonces, para poder elegir una solución genérica o específica para un problema determinado, primero debe comprender qué diablos es ese problema. De lo contrario, solo está adivinando, y adivinar es el trabajo de los gerentes, no de los programadores. . Como casi todo en informática, depende ".
Entonces, ahí lo tienen. "Depende". Esa es probablemente la expresión de dos palabras más poderosa cuando se piensa en el diseño de software.