2017-05-19 1 views
0

필자는 의존성 주입이 무엇인지 이해하지만 전체적인 그림이 아직 소비자에게 어떻게 도움이되는지에 대해서는 아직 알지 못합니다. 아래 예를 참조하십시오.의존성 주입 프레임 워크 - 종속성 전파

//bad 
class car() { 
    var tire = new Tire('snow'); 
} 

//good 
class car() { 
    var tire; 
    constructor(tire){ 
    this.tire=tire 
    } 
} 

그래서 대부분의 기사 나는 차에서 타이어 의존성을 제거하여보다 검증되기 때문에 위의 예는 좋다고 상태를 읽었습니다. 그러나 차 객체를 인스턴스화하는 다른 클래스는 어떻습니까? driver 클래스가 car 클래스를 소환하는 경우 드라이버가 car 오브젝트와 tires을 인스턴스화하도록 강요하지 않습니다. 의존성이 항상 더 많이 전파되는 것처럼 보입니다. 이 부분은 어디에서 끝나나요? 객체를 실제로 인스턴스화하는 것은 무엇입니까? 이것이 DI 프레임 워크가 무엇에 관한 것입니까?

+1

간단히 말해서, 그렇습니다. "그렇습니다."그렇습니다. 그렇습니다. 단순화하기 위해 DI 프레임 워크가 있습니다. – deceze

답변

1

종속성 요구 사항이 모든 단계에서 "전파"되는 것은 맞습니다. 자동차를 인스턴스화하려는 운전자는 CarTire을 가져와야합니다. 드라이버가 많은 드라이버 풀은 Driver, CarTire 등을 가져와야합니다.

당신은 다른 차를 만들 수있는 다른 공장을 삽입 할 수

class Driver { 
    constructor(carFactory) { 
     this.car = carFactory.newCarWithRegularTires(); 
    } 
} 

하고 (만 설명을 위해, 아래를 참조하십시오.) : 그 대처하는 간단한 방법은 공장에 일을 번들되어 Car의 종속성은 Driver을 인식하지 않아도 변경 될 수 있습니다.

더 나아가서 모든 종류의 객체를 생성 할 수있는 일반 글로벌 팩토리를 생성 할 수 있으며, 의존성 주입 컨테이너 인 각각의 의존성을 충족시키는 방법을 알 수 있습니다. 일반적으로 CarTire이 필요하다고 선언하는 텍스트 형식으로 구성하고 Car 인스턴스를 요청하면 Tire을 인스턴스화하고 전달합니다.

DI 컨테이너의 단점은 DI 컨테이너를 다시 구성하여 종속성을 간단히 바꿀 수는 있지만 전체 작업을 다시 구성해야한다는 것을 의미합니다.이 작업은 거대한 상호 종속적 개체 레지스트리가됩니다. 하나의 커다란 컨테이너를 만들지 말고 모듈화 된 컨테이너를 유지해야합니다.

공장에 대한 또 다른 단어 : 위의 공장 예는 훌륭하지 않습니다. 런타임에 객체의 새 인스턴스를 만들어야하는 경우 객체는 팩토리를 사용해야합니다. 이 아니어야합니다.은 단순히 직접 주입 할 수있는 종속성을 만족시키기 위해 공장을 사용합니다.

결국에는 의존성을 직접 선언하고받는 클래스 간의 균형을 유지하려고하지만, 매우 깊은 의존성 계층 구조는 생성하지 않습니다. 의존성을 가능한 한 얕게 유지하는 것이 좋은 출발이며, 공장이나 모듈 식 DI 컨테이너를 stategic point에 도입하는 것은 다른 방법입니다.

+0

좋은 답변입니다. 내 이해를 확인하려면 객체를 인스턴스화하는 것이 불가피하다고 말하고 있습니다. 의존성 계층 구조를 가능한 한 간단하고 얕게 유지하고 필요한 경우 공장을 사용하는 것이 중요합니다. 그렇게 할 때 일반적으로 안내 할 엄지 손가락 규칙이 있습니까? – alaboudi

+1

고통이되기 시작할 때 "뒤로 물러서서 리팩터링하십시오."- 객체는 기본적으로 의존성 그래프를 정의하는 생성자에서 직접 의존성을 가져와야합니다. 의존성 그래프는 DI 컨테이너/팩토리가 그래프를 다시 좁히지 만 더 많은 번들을 도입하고 대체하기가 다소 어려워집니다. 적합한 곳이라면 어디서나 그래프를 표시 할 수 있습니다. – deceze