객체지향의 목적
객체지향 언어를 이용하여 유연한 소프트웨어를 만드는 것이다.
유연하다는 것은 다양한 요구사항의 변화에도 대처가 가능하다는 의미이다.
요구사항의 변화는 소프트웨어에 기능의 추가, 제거, 변경과 같은 수정을 말하며
즉 유연성은 소프트웨어가 얼마나 쉽게 수정될 수 있는가 이다.
위의 모든 장난감은 배터리를 필요로 합니다. 그러나 배터리 일체형 장난감은 배터리가 떨어지면 장난감을 새로 구입해야합니다. 다만 배터리 분리형 장난감은 배터리만 교체해주면 됩니다.
장난감에 배터리를 따로 넣어주는 것을 의존성 주입이라고 생각하면 편합니다.
- 의존성 (Denpendency)이 생기는 코드의 예시
위 코드에서 Programmer 클래스 내부에서 startProgramming 함수가 실행될때 Coffee 클래스의 객체를 필요로 합니다. 이것을 보고 Programmer 클래스는 Coffee 클래스에 의존성을 가진다고 합니다.
문제는, Coffee 클래스가 수정되는 경우 이에 의존을 가지는 Programmer 클래스도 수정되어야 합니다. 이는 곧 결합도(Coupling)가 높다는 의미이고 객체지향 프로그래밍에서 지양되어야하는 부분입니다.
- 의존성이 있는 경우의 코드
만약 위와 같이 Coffee 클래스를 상속하는 Cappuccino , Americano 클래스를 사용해야 한다면, Programmer 클래스에 가서 의존성을 가지는 부분을 일일히 찾아 수정해줘야 합니다.
또한 갑자기 Coffee 클래스가 삭제된거나 클래스 명이 변경되는 등 여러가지 상황에 대처하기 어려워진다. 실제로 Coffee 클래스가 다른 Interface를 구현하게 된다면 자신이 가지는 메소드가 변경되기도 합니다.
- 책임의 정의
객체지향 설계의 5원칙 중 하나는 '단일 책임의 원칙' 입니다. 단순히 표현하면 객체 지향의 구성요소는 단 하나의 책임만을 가진다는 원칙입니다. 즉 Coffee 클래스가 수정되었다고 해서 Programmer 클래스의 수정까지 책임지는 것은 이 원칙에 위배되는 것입니다.
- 그렇다면 의존성 주입이란 말의 의미는?
의존성 '주입' 이라는 의미는 외부에서 의존성을 생성하여 넘겨주는 것을 의미합니다.
Programmer 클래스에서 Coffee 클래스의 객체를 'new' 키워드를 통해 직접 생성하지않고 외부에서 객체를 생성하고 넘겨주는 것을 '의존성을 주입했다' 라고 표현합니다.
그렇다면 '주입'은 어떻게 하는 것일까요? setter() 와 생성자를 이용하여 외부에서 객체를 생성하고 그것을 주입받는 형태로 이루어집니다.
- IoC (Inversiont of Control) 제어의 역전
제어가 거꾸로 가는 개념을 IoC 라고 합니다. 의존성 주입의 경우 내부에서 객체의 생성을 제어하지 않고 외부에서 객체를 생성하고 주입하기 때문에 IoC를 구현하는 방법 중 하나 입니다.
- 의존성을 줄인 코드
이제 의존성을 줄인 코드를 보겠습니다.
Programmer 클래스에 생성자로 Coffee 클래스의 객체를 받아오기 때문에 Coffee 클래스가 수정된다고 하여도 Programmer 클래스에는 영향이 없습니다.
즉, 하나의 객체에서 다른 클래스의 객체가 필요하다면 내부에서 생성하지 않고 생성자나 setter() 를 이용하여 필요한 객체를 주입받는 것이 의존성이 없는 클래스 관계를 설계하는 방법입니다. Spring 4 부터는 생성자를 통한 주입을 강력히 권장한다고 합니다.
의존성 주입을 통해 얻는 이점
-
코드의 재활용성을 높여줍니다
-
객체간의 의존성을 줄이거나 없애줍니다.
-
객체간의 결합도가 낮아져 유연한 코드작성이 가능합니다.
-
Unit Test가 용이해집니다.
-> 의존성 주입을 이용해 특정 모듈간의 의존성을 떨어뜨리고 이를 통해 Mock 객체를 이용 해 테스트를 진행할 수 있게 된다.
즉, 특정 단위 유닛만을 테스트하고 싶은데 다른 클래스와의 의존도가 너무 높다면 단위 테스트를 하기가 어렵다. 여기서 Mock이라는 개념이 나오는데 실제로 객체를 만들어 사용하기엔 너무 의존성이 강하기에 가짜 객체를 만들어 테스트 하는 것이다.
참고한 곳
https://velog.io/@wlsdud2194/what-is-di
