¿Por qué el patrón de inyección de dependencia no se incluyó en la Banda de cuatro?

¿Por qué el patrón de inyección de dependencia no se incluyó en la pandilla de cuatro ? ¿El GOF fue anterior a las pruebas automatizadas generalizadas? ¿La inyección de dependencia ahora se considera un patrón central?

Fui editor de la revista Software Development cuando salió el libro Gang of Four y puedo decir con total confianza que las pruebas unitarias no eran una práctica generalizada en 1994, cuando se publicaron originalmente Design Patterns .

En 1994, C ++ era el lenguaje orientado a objetos más comúnmente utilizado, y la mayoría de las personas que lo programaban provenían de un fondo C. Una de las cosas de "pensar en objetos" que la gente simplemente no tenía es la idea de cientos o miles de puntos de entrada a su programa. Pensaste en el main(). Si trabajó en un proyecto grande, es posible que tenga un archivo MAKE (generalmente bastante elaborado) para crear un programa basado en módulos. ¿Pero "pruebas unitarias"? ¿Comenzar un proceso, construir el contexto de memoria necesario, ejecutarlo y derribarlo, por método ? Eso fue muy radical.

Java hizo que la programación de múltiples puntos de entrada fuera más obvia. En el momento del auge original de Dot-Com, las pruebas unitarias eran una técnica bien conocida, pero realmente era JUnit (¿alrededor de 2001?) Lo que hizo que se incendiara y se convirtiera en una práctica universal.

Aunque la estrategia y el concepto general de programación para una interfaz formaban parte de GoF y el espíritu de mediados de los 90, la idea de la inyección llegó bastante tarde a la fiesta (¿alrededor del '03 -'05?). Honestamente, mis canas todavía tienen dudas sobre ese aspecto de la DI ("¡Fuera de mi césped, malditos archivos de configuración!").

Lo llamaron Estrategia .

Su estrategia parece tener todas las características de la inyección de dependencia sin el nombre de sonido complejo.

Creo que la inyección de dependencia es más relevante cuando se separa la implementación en niveles. Otra área en la que pensamos en la inyección de dependencia es la prueba unitaria. Y su sugerencia previa parece ser correcta. Si la pandilla recolectara y segregara patrones en 2012, definitivamente la inyección de dependencia estaría allí.

La estrategia podría surgir en las discusiones, pero la estrategia no habla sobre la inyección de dependencia. Pero cuando se usa el patrón de estrategia en un solo proyecto o dll (todas las clases e interfaces permanecen en un proyecto) parece que estamos haciendo una inyección de dependencia. De hecho no lo somos.

Ahora, si las clases e interfaces mencionadas en el patrón de estrategia están separadas en diferentes proyectos o niveles, entonces tendremos que usar técnicas de inyección de dependencia. Podríamos usar archivos de configuración de la unidad (sin embargo, no es posible cambiar el tiempo de ejecución). Pero el patrón de estrategia no dice cómo inyectar una dependencia.

Si hay un patrón que se asemeja mucho a la inyección de dependencia, entonces es el patrón del método abstracto de fábrica. Este patrón podría usarse dentro de un patrón de estrategia para inyectar dependencia.

La estrategia de respuesta es 100% correcta. Lo voté pero puedo comentar.

"La estrategia permite que el algoritmo varíe independientemente de los clientes que lo usan. [1] La estrategia es uno de los patrones incluidos en el influyente libro Design Patterns de Gamma et al. Que popularizó el concepto de usar patrones para describir el diseño del software".

Un patrón de diseño no depende de su uso. La inyección de dependencia se implementa utilizando el patrón de estrategia. Si nombramos cada patrón en función del caso de uso, tendríamos que cambiar el nombre de muchos patrones.

El patrón de repositorio no es un patrón nuevo, es el Patrón de plantilla.

"En el método de plantilla de este patrón de diseño, las subclases pueden anular uno o más pasos del algoritmo para permitir diferentes comportamientos y garantizar que se siga el algoritmo general".

A menudo, los patrones son múltiples patrones combinados y nombrados como el patrón MVC.

El GOF no tenía interfaces con las clases Pure Abstract utilizadas, y también aprovechó la capacidad de C ++ para heredar de más de una clase.