"의존 관계 역전의 원칙"
"클라이언트는 구현 클래스가 아닌 인터페이스나 추상 클래스에 의존해야 한다."
구현 클래스는 인터페이스보다 변하기 쉽다. 구현 클래스에 의존한 클라이언트는 구현 클래스의 변경에 따라 클라이언트 역시 변경이 요구될 수 있다.
이 원칙을 따른다면, 모든 클래스는 최소 하나의 인터페이스를 가져야 한다. 이는 오히려 시스템의 복잡도를 증가시킨다.
DIP는 변화나 확장이 예측되는 부분에 적용해야 한다.
"클라이언트는 구현 클래스가 아닌 인터페이스나 추상 클래스에 의존해야 한다."
구현 클래스는 인터페이스보다 변하기 쉽다. 구현 클래스에 의존한 클라이언트는 구현 클래스의 변경에 따라 클라이언트 역시 변경이 요구될 수 있다.
"ArrayList list = new ArrayList();"
구현 클래스에서 많이 사용되고 있는 메서드의 리턴 타입이 바뀌었다면,
그 구현 클래스의 메서드를 사용하고 있는 많은 부분들은 리턴 타입에 맞게 수정을 해야한다.
"List list = new ArrayList();"
하지만, 인터페이스를 구현하게 되면, 구현 클래스를 직접 의존할 필요없이 인터페이스에 의존하여 구현 클래스의 변화에 따른 충격을 피할 수 있다.
이 원칙을 따른다면, 모든 클래스는 최소 하나의 인터페이스를 가져야 한다. 이는 오히려 시스템의 복잡도를 증가시킨다.
DIP는 변화나 확장이 예측되는 부분에 적용해야 한다.
'Design Patterns' 카테고리의 다른 글
| "LSP", Liskov Substitution Principle (2) | 2012.02.26 |
|---|---|
| "ISP", Interface Segrehation Principle (1) | 2012.02.26 |
| "SRP", Single Responsibility Principle (0) | 2012.02.25 |
| High Cohesion, Low Coupling. (0) | 2012.02.25 |
| 객체지향 소프트웨어 설계 원칙. (0) | 2012.02.25 |