의존성 주입에 대한 훌륭한 설명 (Inversion of Control)

저는 Dependency Injection 또는 DI (이전의 Inversion of Control) 및 관련 Hollywood Principle ( "전화하지 마십시오. 전화하겠습니다.")에 대한 많은 설명을 읽었습니다. 그들은 매우 상세한 설명을 즉시 조사하거나 특정 기술에 대한 설명을 구체적으로 연결하기 때문에 모두 명확하지 않은 경향이 있습니다. 패턴이 손실되거나 단순성이 있습니다. 다음은 내가 찾은 가장 명확한 설명입니다. 간결성을 위해 약간 편집했습니다 (Craig Walls의 아주 좋은 Spring in Action, 2nd. Ed.에서) :

"사소하지 않은 모든 애플리케이션은 비즈니스 로직을 수행하기 위해 서로 협력하는 두 개 이상의 클래스로 구성됩니다. 전통적으로 각 객체는 자신이 협업하는 객체 (의존성)에 대한 자체 참조를 확보해야합니다. DI를 적용 할 때 개체는 생성시 시스템의 각 개체를 조정하는 외부 개체에 의해 종속성이 부여됩니다. 즉, 종속성이 개체에 주입됩니다. "

나는 그것이 매우 분명하다고 생각합니다.

종속성 주입은 원래 IoC (Inversion of Control)라고 불 렸습니다. 일반적인 제어 시퀀스는 개체가 자체적으로 의존하는 개체를 찾은 다음 호출하기 때문입니다. 여기서는 반대입니다. 종속성은 생성 될 때 개체에 전달됩니다. 이것은 또한 직장에서의 헐리우드 원칙을 보여줍니다. 의존성에 대해 전화하지 마십시오. 필요할 때 제공 할 것입니다.

DI를 사용하지 않는다면 왜 이것이 큰 문제인지 궁금 할 것입니다. 이는 느슨한 결합이라는 주요 이점을 제공합니다. 객체는 전달하는 것 이외의 다른 것에 의존하지 않기 때문에 다른 객체와 독립적으로 추가 및 테스트 할 수 있습니다. 기존 종속성을 사용할 때 개체를 테스트하려면 모든 종속성이 존재하고이를 테스트하기 전에 도달 할 수있는 환경을 만들어야합니다. DI를 사용하면 원하지 않거나 만들 필요가없는 개체에 대한 모의 개체를 전달하여 개체를 격리하여 테스트 할 수 있습니다. 마찬가지로, 클래스가 자체적으로 포함되어 있기 때문에 프로젝트에 클래스를 추가하는 것이 용이합니다. 따라서 대규모 프로젝트가 종종 진화하는 "큰 털 뭉치"를 피할 수 있습니다.

DI의 과제는이를 사용하여 전체 애플리케이션을 작성하는 것입니다. 몇 가지 수업은 큰 문제가 아니지만 전체 앱이 훨씬 더 어렵습니다. 전체 애플리케이션의 경우 종종 프레임 워크가 개체 간의 종속성 및 상호 작용을 관리하기를 원합니다. DI 프레임 워크는 종종 누구에게 언제 무엇을 전달할 것인지 지정하는 데 도움이되는 XML 파일에 의해 구동됩니다. Spring은 풀 서비스 Java DI 프레임 워크입니다. 다른 가벼운 DI 프레임 워크에는 NanoContainer와 훨씬 더 가벼운 PicoContainer가 포함됩니다.

대부분의 프레임 워크에는 초보자가 길을 찾는 데 도움이되는 좋은 자습서가 있습니다.

이 이야기 "Excellent Description of Dependency Injection (Inversion of Control)"은 원래 JavaWorld에 의해 출판되었습니다.