4 가지 집단에 의존성 주입 패턴이 포함되지 않은 이유는 무엇입니까?

왜 의존성 주입 패턴 이 4 명의 갱에 포함 되지 않았 습니까? GOF는 광범위한 자동 테스트를 시작 했습니까? 의존성 주입은 이제 핵심 패턴으로 간주됩니까?

저는 Gang of Four 책이 나왔을 때 Software Development 잡지의 편집자였으며 , 1994 년에 Design Patterns 가 처음 출판 되었을 때 단위 테스팅이 널리 퍼져 있지 않다는 확신을 가질 수 있습니다 .

1994 년에 C ++은 가장 일반적으로 사용되는 객체 지향 언어였으며 대부분의 사람들은 C 배경에서 프로그래밍했습니다. 사람들이 가지고 있지 않은 "사물에 대한 생각"중 하나는 프로그램에 수백 또는 수천 개의 진입 점이 있다는 것입니다. 에 대해 생각했습니다 main(). 대규모 프로젝트에서 작업 한 경우 모듈 기반 프로그램을 작성하는 (보통 상당히 정교한) make 파일이있을 수 있습니다. 그러나 "단위 테스트"? , 프로세스 시작을 실행하여 필요한 메모리 컨텍스트를 구축하고, 상, 아래로 찢어 있어서 당 기준? 그것은 매우 급진적이었습니다.

Java는 다중 입력 포인트 프로그래밍을보다 명확하게 만들었습니다. 최초의 Dot-Com 붐 시대에 단위 테스트는 잘 알려진 기술 이었지만 실제로는 JUnit (2001 년경?)으로 인해 화재가 발생하여 보편적 인 관행이되었습니다.

하지만 전략 및 인터페이스에 프로그래밍의 일반적인 개념의 GoF의 일부와 90 년대 중반은 시대 정신의 아이디어 주입 파티에 아주 늦게 온 ('03 -'05 년경?). 솔직히, 내 회색 머리카락은 여전히 ​​DI의 그 측면에 대해 매우 모호합니다 ( "잔디를 벗으십시오, 구성 파일을 감히하십시오!").

그들은 그것을 전략 이라고 불렀습니다 .

그들의 전략에는 복잡한 이름이없는 의존성 주입의 모든 기능이있는 것 같습니다.

계층에서 구현을 분리 할 때 Dependency Injection이 더 관련이 있다고 생각합니다. 의존성 주입에 대해 생각하는 또 다른 영역은 단위 테스트입니다. 그리고 당신의 이전 제안은 올바른 것 같습니다. 갱단이 2012 년에 패턴을 수집하고 분리하는 경우, 의존성 주입이 분명히있을 것입니다.

전략은 토론에서 나올 수 있지만 전략은 의존성 주입에 대해 이야기하지 않습니다. 그러나 단일 프로젝트 또는 dll (모든 클래스와 인터페이스가 하나의 프로젝트에 남아 있음)에서 전략 패턴을 사용할 때 종속성 주입을 수행하는 것으로 보입니다. 사실 우리는 그렇지 않습니다.

이제 전략 패턴에서 언급 된 클래스와 인터페이스가 다른 프로젝트 또는 계층으로 분리 된 경우 의존성 주입 기술을 사용해야합니다. 단일 구성 파일을 사용할 수 있습니다 (런타임 변경은 불가능합니다). 그러나 전략 패턴은 의존성을 주입하는 방법을 말하지 않습니다.

의존성 주입과 매우 유사한 패턴이 있으면 추상 팩토리 메소드 패턴입니다. 이 패턴은 전략 패턴 내부에서 사용되어 종속성을 주입 할 수 있습니다.

답변 전략은 100 % 정확합니다. 나는 그것을 투표했지만 의견을 말할 수 있습니다.

"전략은 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변화시킬 수 있습니다. [1] 전략은 Gamma 등의 영향력있는 책 Design Patterns에 포함 된 패턴 중 하나로서, 소프트웨어 디자인을 설명하기 위해 패턴을 사용하는 개념을 대중화했습니다."

디자인 패턴은 그 사용에 의존하지 않습니다. 종속성 주입은 전략 패턴을 사용하여 구현됩니다. 유스 케이스를 기준으로 각 패턴의 이름을 지정하면 많은 패턴의 이름을 바꿔야합니다.

리포지토리 패턴은 새로운 패턴이 아니라 템플릿 패턴입니다.

"이 디자인 패턴의 템플릿 방법에서 하나 이상의 알고리즘 단계를 서브 클래스로 대체하여 다른 동작을 허용하면서도 중요한 알고리즘을 계속 준수 할 수 있습니다."

종종 패턴은 MVC 패턴과 같이 여러 패턴이 결합되어 명명됩니다.

GOF에는 사용 된 Pure Abstract 클래스 인터페이스가 없었으며 C ++의 여러 클래스에서 상속 할 수있는 기능도 활용했습니다.