의존성 주입의 실제 사용 사례는 무엇입니까?

Question

나는 의존성 주입을 이해하지만 실제로 이해할 수없는 것은 의존성 주입을 사용하는 것입니다. 이 here을 언급 한 바와 같이

이 (. 그것은 종속성을 조롱하거나 축소 스텁 할 수 있기 때문에 그것은, 테스트를위한 매우 유용한 기술입니다) 쉽게 당신의 코드를 테스트에을 할 수 있지만 지금은 일 조롱 프레임 워크의 많은있다 Mockito, powermockito과 같은 것들은 왜 의존성 주입보다 이러한 작업을 잘 할 수 있습니까?

코드로 설명 할 수 있다면 좋을 것입니다.

미리 감사드립니다.

Answer 1

Dependency injection은 mocking frameworks의 대안이 아닙니다. 요구 사항입니다. 의존성이 심한 경우 종속성을 모방하여 코드를 테스트하는 것이 훨씬 어렵습니다.

DI 또한 느슨하게 결합 된 코드를 가질 수 있습니다. 클래스는 특정 클래스를 구성하는 방법 (또는 인스턴스를 얻는 방법)을 알기보다는 다른 클래스를 주입함으로써 간단히 다른 클래스를 사용할 수 있습니다. 기술로서 DI위한

Answer 2

주된 용도는 :

쉽게가 (조롱 사용) 테스트하는 코드로 이끈다. 즉 조롱 프레임 워크 (Mockito 등)를 사용하려면 더 많은 DI를 사용해야합니다. DI를 사용하지 않고 객체를 직접 인스턴스화하는 코드를 작성하면 실질적으로 Mockito를 사용하여 종속성을 조롱 할 수 없습니다.

오케스트라 연주 코드를 작성한다고 해봅시다. 주 수업은 다른 많은 수업 (다른 사람들이 아마도 쓴 것)에 달려 있습니다.

public class Orchestra { 
    private Drums drum; 
    private Violin violin; 
    private Guitar guitar; 

public Orchestra() { 
    drum = new Drum(); 
    violin = new Violin(); 
    guitar = new Guitar(); 
} 

public Music play(){ 
    // use above in some way to run your orchestra 
    // start with violin 
    // add some guitar and then bring in the drums too 
} 

}

지금 당신이 play에있는 당신의 논리가 정확하게 작동하는지 확인하려면 :

은 당신이 쓴 말할 수 있습니다. 수업을 할 때 당신이 기대하는 음악이 아니라는 것을 알 수 있습니다. (아마 드럼 연주가 처음부터 시작됩니다.) 코드 play의 논리를 테스트하려고합니다. 어떻게 할거 니? 당신은 당신의 의존성에 대한 통제권이 없습니다. 코드가 Drum이거나 자신의 로직이 play() 인 문제는 없는지 잘 모릅니다.

Drum 여기에 있습니다. 그러나 당신은 그렇게 쉽게 할 수 없습니다. 코드가 DI를 사용하지 않기 때문입니다. 그것의 내부에 직접 Drum의 인스턴스.

이제 DI를 사용하고 어떻게 도움이되는지 확인하십시오.

public class Orchestra { 
    private Drums drum; 
    private Violin violin; 
    private Guitar guitar; 

    public Orchestra(Drums d,Violin v, Guitar g) { 
     drum = d; 
     violin = v; 
     guitar = g; 
    } 

    public Music play(){ 
     // use above in some way to run your orchestra 
    } 

} 

이 코드를 사용하면 테스트에서 Drum을 조롱하는 것이 쉬워집니다.

class TestOrchestra { 

    public void testPlay(){ 
     Drum mockDrum = mock(Drum.class); 
     Violin mockViolin = mock(Violin.class); 
     Guitar mockGuitar = mock(Guitar.class); 
     // add mock behaviour to above , here you control precisely what these dependencies will do inside your code 

     Orchestra orch = new Orchestra(mockDrum, mockViolin,mockGuitar); 
     // now play and test your logic 

    } 

} 

DI를 사용하는 두 번째 장점은 전체 코드를 통해 갈 필요없이 프로그램의 큰 부분의 구현을 변화 할 수 있다는 점이다.

위의 내용을 다시 한 번 말하면 특정 유형의 기타 (코드에 의해 내부적으로 인스턴스화 된)를 사용하여 오케스트라를 연주했다고 가정 해 봅시다.

이제 새로운 일렉트릭 기타로 변경하고 싶습니다. DI가 없으면 Orchestra 클래스를 열고 Guitar을 만들 위치를 확인하고 해당 코드 줄을 변경해야합니다. 실수로 코드의 다른 부분이 실수로 변경되지 않도록하고 Orchestra 전체를 테스트하여 정상적으로 작동하는지 확인해야합니다.

DI를 사용하면이 모든 현상을 피할 수 있습니다. 새 Guitar 개체를 생성자에 삽입하기 만하면됩니다. 그게 전부 야. 새 Guitar 개체를 자체적으로 테스트 했으므로 (이 코드는 계약을 충족 함)이 새로운 기타를 삽입하여 Orchestra 코드가 손상되지 않으므로 안심해도됩니다.