Dependency Injection 및 IoC 컨테이너를 사용하면 어떤 이점이 있습니까?

62

Dependency Injection과 IoC Containers에 대해 이야기 할 계획이며 그것을 사용하기위한 좋은 주장을 찾고 있습니다.

이 기술과 이러한 도구를 사용하면 가장 중요한 이점은 무엇입니까?

design-patterns dependency-analysis

— 앤디 로리
소스

1

참조 여기 와 여기 에 StackOverflow에 대한 답변과 여기 IOC의에 좋은 전체 기사. 그리고 비교를 위해 논쟁을 원한다면 여기 로 가십시오.

— Jesse C. Slicer

14

DI / IOC를 사용해야하는 이유를 모르는 이유는 무엇입니까? 내기를 잃어? ;-)

— Steven A. Lowe 1

2

@Steven, 그의 상사가 그에게 부탁했을 수도 있습니다.

1

@Steven, 나는 이미 DI를 항상 사용하고 있습니다 (일부는 너무 자주 말합니다 :-D). 다른 사람들이 그것을 사용할 수 있도록 좋은 주장을 찾고 있습니다.

— Andy Lowry

2

사람들 은 DI 의 남용 에 대해 거의 이야기하지 않습니다 . 모든 단일 결정을 지연 시키면 스파게티 코드에 해당하는 OO를 생성하게됩니다. 일관된 설계를 위해서는 어느 시점에서 실제 결정을 내려야합니다.

— Macneil

47

저에게있어 가장 중요한 것은 단일 책임 원칙을 쉽게 따르는 것 입니다.

DI / IoC를 사용하면 개체 간 종속성을 간단하게 관리 할 수 있습니다. 따라서 일관성있는 기능을 자체 계약 (인터페이스)으로 쉽게 분리 할 수 있습니다. 결과적으로 DI / IoC에 대해 배운 후 코드가 훨씬 모듈화되었습니다.

이것의 또 다른 결과는 Open-Closed Principle 을 지원하는 디자인을 훨씬 쉽게 이해할 수 있다는 것 입니다. 이것은 가장 자신감있는 기술 중 하나입니다 (자동 테스트에 이어 두 번째). 공개 폐쇄 원칙의 미덕을 충분히 옹호 할 수 있을지 의심됩니다.

DI / IoC는 저의 프로그래밍 경력에서 "게임 체인저"가 된 몇 안되는 것들 중 하나입니다. 가 큰 내가 전에 & DI / IOC의 학습 후 작성한 코드 사이에 품질 차이는. 좀 더 강조하겠습니다. 거대한 코드 품질 개선.

— 퀀틴-스타 인
소스

3

공개 원칙이 왜 그렇게 중요한가? API / 인터페이스를 변경해야한다고 생각하는 이유는 무엇입니까?

— Arne Evertsson

@ArneEvertsson 개방형 원칙에 대한 Robert C. Martin의 이야기를 들어보십시오. 당신은 깨달을 것입니다.

— Alternatex

@AmeEvertsson Open-Closed는 코드를 다른 사용자가 사용할 수있는 모듈로 코드 (예 : 상용 제품)로 제공 할 때 매우 중요합니다. 코드를 변경하지 않고 코드를 변경하지 않고도 사용에 적합하도록 만들 수 있습니다.

— James Ellis-Jones

2

DI는 단순히 구체적인 클래스에 대한 종속성을 만드는 것보다 종속성을 훨씬 더 복잡하게 관리하는 것을 간단하게 만들지 않습니다. 그러나 유연성을 제공하지만 '적절한'단위 테스트를 수행하지 않으면 유연성이 필요하지 않은 경우가 많습니다. 설명 된 주요 장점은 Service Locator에도 적용됩니다.

— James Ellis-Jones

1

나는 몇 년 전에이 답변을 하향 투표했다. 1) 실제로, DI의 광범위한 사용이 작동하는 경향이 : 여기에 몇 가지 발언이다 에 대해 프로그래머가 단순히 새로운 클래스 등, 자신의 주입 "컨트롤러", "서비스", "DAO를"에 대한 방법을 추가하는 대신 만들 유지하기 때문에, SRP는 새로운 기능. DI 프레임 워크 또는 컨테이너를 사용하는 Java 및 C # .NET 프로젝트에서 일반적으로 발생하는 것입니다. 2) 공개 폐쇄 원칙은 클래스 (구현) 상속의 유용성에 대한 Bertrand Meyer의 망상 일뿐입니다. 그의 1400+ 페이지 책에서 검색하면 내가 무슨 뜻인지 알 수 있습니다-그것은 정말로 어리 석습니다.

— Rogério

9

실제로 내 눈을 뜨게 한 예는 그러한 방식으로 만들어진 객체를 쉽게 단위 테스트 할 수있는 방법을 보았습니다. 그 전에 단위 테스트를 위해 객체를 분리하는 데 문제가있었습니다. 나는 종종 더 큰 시스템과 상호 작용하기 위해 테스트를 작성합니다. 전체 시스템이 예측하기가 훨씬 어려우며 개별 구성 요소를 변경하기가 훨씬 쉽기 때문에 이것은 실제로 어려웠습니다.

— 윈스턴 에워 트
소스

3

의존성 주입의 장점은 다음과 같습니다.

코드가 깨끗하고 읽기 쉽습니다.
코드가 느슨하게 결합되어 있습니다.
구현이 XML 파일로 구성 될 때 더 재사용 가능하며 다른 컨텍스트에서 사용될 수 있습니다.
다른 모의 구현으로 코드를 쉽게 테스트 할 수 있습니다.

— 솔라 이마니 SA
소스

1

실제 혜택은 기술적 인 것보다 정치적이라고 생각합니다. DI는 단순히 서비스 로케이터 패턴 의 대안 일뿐 입니다. 그 자체로는 SRP 또는 OCP와 같은 원칙을 따르거나 계층을 분리하기가 쉽지 않습니다. 다른 응답자들은 다른 개념과 기술, IMO를 혼동하고 있습니다.

Service Locator를 사용하거나 적용 가능할 때마다 (대부분의 경우) 직접 종속성을 인스턴스화하여 높은 응집력 및 낮은 결합과 동일한 목표를 달성 할 수 있습니다.

이제 저는 많은 사람들이이 의견에 동의하지 않을 것임을 알고 있습니다. 구체적인 예를 논의하게되어 기쁩니다.

— 로제 리오
소스

2

그러나 서비스 로케이터를 직접 호출하거나 구체적인 종속성을 인스턴스화하면 일반적으로 종속성이 달라 지거나 최소한 종속성의 출처를 결정합니다. DI의 목적을 어기는 것 같습니다. 여전히 서비스 로케이터도 주입해야합니다.

— Matt H

Service Locator를 사용한다고해서 일반적으로 "주입되지 않은"Service Locator 클래스 자체의 사용을 제외하고는 아무것도 배선하지 않습니다. 외부 구현이 필요하지 않은 경우에는 구체적인 구현 클래스를 인스턴스화하는 것이 좋습니다. 예를 들어 프로그래머는 일반적으로 DI를 사용하는 대신 ArrayList 클래스를 직접 인스턴스화합니다.

— Rogério

1

"낮은 커플 링"을 언급하고 나중에 서비스 로케이터가 애플리케이션의 커플 링 레벨에 영향을 미치지 않는다고 말합니다. 코드에서 직접 공동 작업자를 인스턴스화하는 것과 마찬가지로 객체를 종속성과 결합하는 더 완벽한 방법은 생각할 수 없습니다. 두 시나리오를 어떻게 단위 테스트합니까? 나는 당신이 말한 모든 것에 전적으로 동의하지 않습니다.

— 클린트 이스트우드

@Jonathan DI 를 소개 한 기사를 읽어야합니다 . 저자는 DI와 ServiceLocator가 "거의 가장자리"와 함께 "대략 동등하다"고 결론 지었다. 중요한 결합은 컴포넌트와 여러 구현을 가질 수있는 다른 컴포넌트 사이에 있습니다. ServiceLocator는 구현이 하나 뿐인 인프라 서비스이므로 괜찮습니다. " 필요할 때마다 의존성을 나타내는"글을 썼습니다 . 물론 구성과 사용을 분리 해야하는 경우에는 구성하지 않아도됩니다.

— Rogério

1

@Jonathan 단위 테스트와 관련하여 공동 작업자를 인스턴스화하면 이러한 테스트가 생성되지 않는다는 것은 신화입니다. 의존성 구현에서 클래스를 분리하는 작업을 주입 여부에 관계없이 수행하는 잘 알려진 조롱 도구가 있습니다.

— Rogério

-1

DI가 테스트 목적으로 내부 물체를 노출시키는 데 사용될 때 패턴이 남용되었습니다.

— 토마스 피터
소스

1

"내부 객체"는 무엇을 의미합니까?. 에서 실제 (프로그래머의 아마 1 %가 실제로 무엇을 의미하는지 알 주) OOP, 메시지 (즉, 메소드 호출을) 전송을 통해 서로 통신하는 객체가있다. 그런 의미에서 각 객체는 단일 책임을 가져야하며, 다른 객체보다 "더 중요한"객체는 없습니다. 모든 단일 객체는 단일 의무를 가지며 전체 시스템에서 제공하는 기능을 달성하기 위해 협력합니다. 모든 개체를 격리 된 방식으로 테스트하는 것이 중요하므로 우리는 어떤 사례도 놓치지 않았다는 것을 알았습니다. 이것이 DI가 실제로 잘하는 것입니다.

— 클린트 이스트우드

깜빡했습니다.

— 토마스 피터