Por que o padrão de injeção de dependência não foi incluído na quadrilha dos quatro?

Por que o padrão de injeção de dependência não foi incluído na quadrilha de quatro ? O GOF pré-datou testes automatizados generalizados? A injeção de dependência agora é considerada um padrão central?

Eu era editor da revista Software Development quando o livro Gang of Four foi lançado e posso dizer com total confiança que o teste de unidade não era uma prática generalizada em 1994, quando o Design Patterns foi publicado originalmente.

Em 1994, o C ++ era a linguagem orientada a objetos mais usada, e a maioria das pessoas que a programava vinha de um background em C. Uma das coisas que "as pessoas pensam em objetos" que as pessoas simplesmente não tinham é a ideia de centenas ou milhares de pontos de entrada no seu programa. Você pensou sobre o main(). Se você trabalhou em um projeto grande, pode ter um makefile (geralmente bastante elaborado) para criar um programa baseado em módulo. Mas "teste de unidade"? Iniciando um processo, construindo o contexto de memória necessário, executando-o e destruindo-o, por método ? Isso foi muito radical.

Java tornou a programação com vários pontos de entrada mais óbvia. Na época do boom original da Dot-Com, o teste de unidade era uma técnica bem conhecida, mas foi realmente a JUnit (por volta de 2001?) Que fez com que pegasse fogo e se tornasse uma prática universal.

Embora a estratégia e o conceito geral de programação para uma interface fizessem parte do GoF e do zeitgeist de meados dos anos 90, a idéia de injeção chegou muito tarde para a festa (cerca de '03 -'05?). Honestamente, meus cabelos grisalhos ainda são bastante duvidosos sobre esse aspecto do DI ("Saia do meu gramado, seus malditos arquivos de configuração!").

Eles chamaram de estratégia .

Sua estratégia parece ter todos os recursos da injeção de dependência sem o nome complexo.

Eu acho que a injeção de dependência é mais relevante ao separar a implementação em camadas. Outra área em que pensamos sobre injeção de dependência é o teste de unidade. E sua sugestão pré-data parece estar correta. Se a quadrilha coletar e segregar padrões em 2012, definitivamente a injeção de dependência estará lá.

A estratégia pode surgir nas discussões, mas a estratégia não fala sobre injeção de dependência. Porém, ao usar o padrão de estratégia em um único projeto ou dll (todas as classes e interfaces permanecem em um projeto), parece que estamos fazendo a injeção de dependência. De fato, não somos.

Agora, se as classes e interfaces mencionadas no padrão de estratégia forem separadas em projetos ou camadas diferentes, teremos que usar técnicas de injeção de dependência. Poderíamos usar arquivos de configuração da unidade (nenhuma alteração no tempo de execução é possível). Mas o padrão de estratégia não diz como injetar uma dependência.

Se houver um padrão que se assemelhe muito à injeção de Dependência, será o padrão Abstract Factory Method. Esse padrão pode ser usado dentro de um padrão de estratégia para injetar dependência.

a resposta A estratégia está 100% correta. Eu votei, mas posso comentar.

"A estratégia permite que o algoritmo varie independentemente dos clientes que o utilizam. [1] A estratégia é um dos padrões incluídos no influente livro Design Patterns de Gamma et al. Que popularizou o conceito de uso de padrões para descrever o design de software".

Um padrão de design não depende de seu uso. A injeção de dependência é implementada usando o padrão de estratégia. Se nomearmos cada padrão com base no caso de uso, teremos que renomear muitos padrões.

O padrão do repositório não é um novo padrão, é o Padrão do Modelo.

"No método de modelo deste padrão de design, uma ou mais etapas do algoritmo podem ser substituídas por subclasses para permitir comportamentos diferentes, garantindo que o algoritmo abrangente ainda seja seguido."

Geralmente, os padrões são múltiplos padrões combinados e nomeados, como o padrão MVC.

O GOF não tinha interfaces com as classes Pure Abstract usadas e também aproveitou a capacidade do C ++ de herdar mais de uma classe.