의존성 주입과 반대되는 기술 용어?

이것은 순수한 기술적 질문이 아닌 명명법 (기술적 글쓰기)에 가깝습니다. 응용 프로그램에서 종속성 주입을 확장하는 데 중점을 둔 리팩토링 제안서를 작성하고 나 자신에게 할당하려고합니다. 우리는 자동 배선 Bean에 Spring 을 사용하지만 MyClass obj = new MyClass(...)완전히 주입 될 수있는 Bean을 사용하여 인스턴스를 생성하는 인스턴스가 여전히 있습니다. 제안서에 우아한 명명법을 사용하고 적절한 용어로 DI와 반대되는 디자인 패턴을 참조하고 싶습니다.

"견고한 결합"은 DI에 반의어로 적합한 용어입니까?

아니요. 긴밀한 결합은 의존성 주입이 다루는 것보다 훨씬 많습니다.

의존성 주입은 구현 결정을 외부화합니다. 이것은 분리하는 데 먼 길을 가지만 결합은이 이상입니다.

의존성 주입에 대한 좋은 반의어는 의존성을 하드 코딩하는 것 입니다. 비헤이비어 객체 내부에 새로운 것을 사용하거나 일부 팩토리를 직접 사용하면 두 가지 다른 문제가 발생합니다. 서비스 로케이터는 분리를 돕지 만 서비스 로케이터 자체에 연결되어 있습니다.

커플 링은 구성과 동작을 분리하는 것 이상입니다. 클래스 A에서 클래스 B까지 특정 순서로 호출 해야하는 101 개의 메소드가 있으면 단단히 결합됩니다. 건축과 행동이 얼마나 훌륭하게 분리되어 있는지는 중요하지 않습니다.

커플 링은 두 개체의 상호 의존성을 측정하는 것입니다. 한 쪽에서 다른쪽에 영향을주지 않으면 서 변경하기 어렵게 만드는 것은 커플 링에 기여합니다. 의존성 주입이 이것에 도움이되지만 이것이 전부는 아닙니다.

엄밀히 말하면, Dependency Injection 은 NOT Dependency Injection에 반대 하고 따라서 Dependency Injection 이 아닌 종속성 관리 전략 에만 반대 합니다.

[원치 않는] 커플 링은 정확히 직교적인 문제는 아니지만 어느 쪽이든 일어날 수 있거나 완화 될 수 있습니다. 이들은 모두 다음에 연결됩니다 DependencyClass.

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorDependencyClass이 경우 특정 에 연결됩니다 . 그러나 둘 다에 연결되어 DependencyClass있습니다. 진정한 악은 여기에 존재하는 커플 링일 필요는 없습니다. 갑자기 자신의 의존성이 주입 된 ^1을 갑자기 필요로 DependencyLookupConstructor한다면 변화 DependencyClass해야합니다 .

그러나,이 생성자 / 클래스도되고 더 느슨하게 결합 :

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

당신은 C #으로 작업하는 경우, 위에서 당신을 허용합니다 ServiceLocator반환 아무것도 할 때 GetMyDoer()그것을 가지고만큼 수, 호출 do()무엇 DependencyLocatingConstructor그것이있다 do(). 완전한 인터페이스에 연결하지 않고도 컴파일 타임 서명 유효성 검사의 이점을 얻을 수 있습니다 ² .

따라서 독을 선택하십시오.

그러나 기본적으로 Dependency Injection의 구체적인 "반대"가있는 경우 "종속성 관리 전략"영역에서 다른 것이 될 것입니다. 무엇보다도 대화에서 다음 중 하나를 사용한 경우 NOT Dependency Injection 으로 인식합니다 .

• 서비스 로케이터 패턴
• 종속성 로케이터 / 위치
• 직접 객체 / 의존성 구축
• 숨겨진 의존성
• "의존성 주입이 아님"

^{아이러니하게도, DI가 높은 수준에서 해결하는 몇 가지 문제는 낮은 수준에서 DI를 과도하게 사용한 결과입니다. 나는 불필요한 복잡성과 코드베이스 작업의 즐거움 했어 모든 이상 과 같은 복잡성이 실제로 도움이 장소의 소수 수용의 결과를 ... 나는 틀림없이 나쁜 노출에 의해 바이어스하고있다.}

^{2. 서비스 위치를 사용 하면 호출 코드 의 기능적 역할에 의해 동일한 유형의 서로 다른 종속성을 쉽게 지정할 수 있으며, 종속성의 빌드 방법에 대해서는 여전히 거의 무관합니다. 예를 들어 대 또는 다른 목적으로 해결 User하거나 IUser다른 목적으로 사용해야한다고 가정합니다 . 내 코드는 지원하는 인터페이스를 몰라도 기능적으로 필요한 것을 요청할 수 있습니다 .Locator.GetAdministrator()Locator.GetAuthor()}

널리 인정되는 특정 산업 용어가 있다는 것을 모르겠지만 내부 인스턴스 생성 , 내부 종속성 생성 , 로컬 종속성 또는 로컬 범위 종속성 등의 대안이 있습니다 .

의존성 캡슐화 와 함께 갈 것입니다 . 이것은 의존성이 방문하고 다시 떠나는 것이 아니라 잠겨 있음을 나타냅니다.