[oop] 의존성 주입은 캡슐화를 희생해야합니까?

그것은 좋은 질문 -하지만 어떤 점에서, 가장 순수한 형태의 캡슐 요구 객체가 의존성이 성취 한 그 어느 경우에 위반 될 수 있습니다. 종속성의 일부 제공자는 있어야 해당 개체가를 필요로 둘 것을 알고 Foo, 그리고 공급자가 제공하는 방법이하는 Foo개체에 있습니다.

일반적 으로이 후자의 경우는 생성자 인수 또는 setter 메소드를 통해 처리됩니다. 그러나 이것이 반드시 사실은 아닙니다. 예를 들어 Java의 최신 버전의 Spring DI 프레임 워크는 개인 필드에 주석을 달도록하고 (예 :로 @Autowired) 종속성을 공개하지 않고도 리플렉션을 통해 종속성을 설정합니다. 공개 메소드 / 생성자 클래스 이것은 당신이 찾고있는 일종의 해결책 일 수 있습니다.

즉, 생성자 주입이 큰 문제라고 생각하지 않습니다. 나는 항상 생성 후에 객체가 완전히 유효해야한다고 느꼈다. 그래서 그들의 역할을 수행하기 위해 필요한 것 (즉, 유효한 상태에 있음)은 어쨌든 생성자를 통해 공급되어야한다. 공동 작업자가 작동 해야하는 객체가있는 경우 생성자 가이 요구 사항을 공개적으로 알리고 클래스의 새 인스턴스를 만들 때이 요구 사항을 충족시키는 것이 좋습니다.

이상적으로 객체를 다룰 때 인터페이스를 통해 객체와 상호 작용하고, 더 많은 작업을 수행할수록 (DI를 통해 종속성이 연결됨) 실제로 생성자를 직접 처리 할 필요가 없습니다. 이상적인 상황에서 코드는 클래스의 구체적인 인스턴스를 처리하지 않으며 심지어는 클래스를 작성하지도 않습니다. 따라서 IFoo생성자 FooImpl가 자신의 작업을 수행해야한다는 것을 걱정 하지 않고 실제로 FooImpl존재 여부를 알지 못하고 DI를 통해 전달 됩니다. 이 관점에서 캡슐화는 완벽합니다.

이것은 물론 의견이지만, 제 생각에는 DI가 반드시 캡슐화를 위반하지는 않으며 실제로 내부에 필요한 모든 지식을 한 곳에 집중시켜 도움을 줄 수 있습니다. 이것은 그 자체로 좋은 일 일뿐 만 아니라 더 좋은 곳은 자신의 코드베이스 외부에 있으므로 작성하는 코드 중 어느 것도 클래스의 종속성에 대해 알 필요가 없습니다.

답변

switch (principle)
{
      case encapsulation:
           if (there_is_a_reason)
      break!
}