"Bastard Injection"과 "Poor Man 's Injection"의 실제 차이점은 무엇입니까?

"Bastard Injection"과 "Poor Man 's Injection"의 실제 차이점은 무엇입니까?

---

".Net의 종속성 주입"책에서 IoC 컨테이너를 사용할 때 나에게 많은 의미가있는 응용 프로그램 의 구성 루트 에서 개체 그래프를 만들어야한다는 것을 알고 있습니다 .

DI를 사용하려고 할 때 본 모든 애플리케이션에는 항상 두 개의 생성자가 있습니다. 하나는 매개 변수로 종속성이있는 하나는 매개 변수가없는 "기본"하나는 다른 하나를 "newing"이라고 부르는 것입니다. 그러나 앞서 언급 한 책에서 이것은 "Bastard Injection anti-pattern"이라고 불리며 이것이 제가 "Poor Man 's Injection"으로 알고 있던 것입니다.

이제이 모든 것을 고려할 때 "Poor Man 's Injection"은 IoC 컨테이너를 사용하지 않고 대신 해당 Composition Root 에서 모든 개체 그래프를 직접 코딩하는 것 입니다.

그래서 내 질문은 다음과 같습니다.

1. 이 개념을 올바르게 이해하고 있습니까? 아니면 완전히 벗어 났습니까?
2. 여전히 IoC 컨테이너의 모든 종속성을 등록해야하는 경우와 똑같은 컴포지션 루트에서 직접 코딩해야하는 경우 IoC 컨테이너를 사용하면 실제로 어떤 이점이 있습니까?
3. "Poor Man 's Injection"이 실제로 무엇인지 오해했다면 누군가 그것을 명확히 해줄 수 있습니까?

감사

---

DI에 관해서는 용어의 상반되는 사용이 많이 있습니다. 가난한 사람의 DI 라는 용어 도 예외는 아닙니다. 어떤 사람들에게는 한 가지를 의미하고 다른 사람들에게는 다른 것을 의미합니다.

제가이 책으로하고 싶었던 것 중 하나는 DI에 일관된 패턴 언어 를 제공하는 것이 었습니다 . 사용이 상충되는 모든 용어에 대해서는 두 가지 옵션이있었습니다. 완전히 새로운 용어를 생각해 보거나 가장 널리 사용되는 사용을 선택하는 것입니다 (주관적인 판단에 따라).

일반적으로 완전히 새로운 (따라서 외계인) 패턴 언어를 만드는 대신 기존 용어를 ​​재사용하는 것을 선호했습니다. 이는 특정 경우 (예 : Poor Man 's DI)에서 책에 주어진 정의와 이름이 무엇인지에 대해 다른 개념을 가질 수 있음을 의미합니다. 패턴 북에서 자주 발생합니다.

적어도 나는 그 책이 Poor Man의 DI와 Bastard Injection을 정확하게 설명하는 역할을 한 것처럼 보인다는 것을 안심시킨다. 왜냐하면 OP에 주어진 해석이 자리 잡았 기 때문이다.

DI 컨테이너의 실제 이점과 관련하여이 답변을 참조하겠습니다. Inversion of Control 컨테이너에 대한 인수

---

PS 2018-04-13 : 저는 몇 년 전에 Poor Man 's DI 라는 용어 가 원칙의 본질을 전달하는 데 좋지 않은 (말 그대로!) 일 을한다는 것을 인정하게되었음을 지적하고 싶습니다 . , 대신 Pure DI라고했습니다 .

---

질문의 2) 부분에 대한 메모.

여전히 IoC 컨테이너의 모든 종속성을 등록해야하는 경우와 똑같은 컴포지션 루트에서 직접 코딩해야하는 경우 IoC 컨테이너를 사용하면 실제로 어떤 이점이 있습니까?

• 의존성 트리가있는 경우 (다른 의존성 등에 의존하는 의존성에 의존하는 clasess) : 각 "개자식 주입"에서 인스턴스를 새로 만들기 때문에 컴포지션 루트에서 모든 "뉴스"를 수행 할 수 없습니다. 각 클래스의 생성자이므로 코드베이스를 따라 분산 된 많은 "구성 루트"가 있습니다.

• 종속성 트리가 있든 없든 IoC 컨테이너를 사용하면 코드를 입력 할 필요가 없습니다. 동일한에 의존하는 20 개의 다른 클래스가 있다고 상상해보십시오 IDependency. 컨테이너를 사용하는 경우 사용할 인스턴스를 알 수 있도록 구성을 제공 할 수 있습니다 IDependency. 이 작업을 한 곳에서 만들면 컨테이너가 모든 종속 클래스에 인스턴스를 제공하도록 처리합니다.

• 컨테이너는 또한 개체 수명을 제어 할 수 있으므로 또 다른 이점이 있습니다.

이 모든 것, DI가 제공하는 다른 명백한 이점 (테스트 가능성, 유지 관리 가능성, 코드 분리, 확장 성 ...)

---

레거시 애플리케이션을 리팩토링하고 종속성을 분리 할 때 2 단계 프로세스를 사용하면 작업이 더 쉬워지는 경향이 있음을 발견했습니다. 이 프로세스에는 "가난한 사람"과 공식 IoC 컨테이너 시스템이 모두 포함됩니다.

첫째 : 인터페이스를 설정하고이를 구현하기위한 "poor mans ioc"를 설정합니다.

• 이는 공식 IoC 설정의 추가 오버 헤드 (및 학습 곡선)없이 종속성을 분리합니다.
• 이것은 또한 기존 레거시 코드와의 간섭을 줄입니다. 디버그 할 또 다른 문제 세트를 도입하는 것과 같은 것은 없습니다.
• 개발 팀 구성원은 동일한 수준의 전문 지식이나 이해를 갖지 않습니다. 따라서 많은 구현 시간이 절약됩니다.
• 이것은 또한 테스트 케이스를위한 기초를 허용합니다.
• 이는 또한 나중에 공식 IoC 컨테이너 시스템에 대한 표준을 설정합니다.
• 이것은 많은 사람들이 시간이 지남에 따라 단계적으로 구현할 수 있습니다.

둘째 : 각 IoC 시스템에는 장단점이 있습니다.

• 이제 애플리케이션 표준이 설정되었으므로 IoC 컨테이너 시스템을 선택할 때 교육적인 결정을 내릴 수 있습니다.
• IoC 시스템 구현은 "가난한 사람"코드를 새로운 IoC 시스템으로 교체하는 작업이됩니다.
• 이것은 시간이 지남에 따라 단계적으로 그리고 "가난한 사람"과 병행하여 구현 될 수 있습니다. 한 사람과 함께하는 것이 좋습니다.

참고 URL : https://stackoverflow.com/questions/7099406/what-is-the-real-difference-between-bastard-injection-and-poor-mans-injectio