의존 관계 정리
1. 인터페이스를 만들어 의존 관계를 끊거나 의존의 방향을 바꿀수 있다.
2. 다형성을 사용하면 어떤 함수를 포함한 모듈에 의존하지 않고 그 함수를 호출할 수 있다.
SRP : 단 하나의 책임 원칙
1. 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다. 한 클래스가 너무 많을 것을 안다면(다양한 기능의 메소드) 부서지기 쉬운 클래스가 된다. 즉 설계 결합도가 너무 높다. UML을 통해 확인하기 쉽다. 둘 이상의 주제 영역에 의존 관계인 클래스를 찾아보면 된다. 가장 쉽게 찾을 수 있는 것은 특정 속성을 부여하는 인터페이스를 하나 또는 그 이상으로 구현하는 클래스를 확인한다.
2. 기존에 존재하는 서로 다른 속성의 인터페이스와 클래스가 하나의 단위로 묶여야 한다면 인터페이스를 바로 적용하기 보다는 클래스를 상속한 자식 클래스에서 인터페이스를 적용하여 인터페이스와 부모 클래스의 연관관계를 최소화시킨다.
어떤 클래스를 변경해야 할 이유는 오직 하나 뿐이어야 한다
OCP : 개방 - 폐쇄 원칙
1. 소프트웨어 엔티티(클래스, 모듈, 함수)는 확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 한다. 즉 모듈 자체를 변경하지 않고도 둘러싼 환경을 바꿀 수 있어야 한다. A->B->C 3개의 클래스가 의존된 상태에서 C클래스가 변경되면 A클래스 까지도 영향을 미친다. 이때 A와 B 사이에 인터페이스를 두어 환경 변경에 대해 폐쇄해야한다.
2. GUI를 사용한 MVC모델에서는 View와 Controller의 결합이 너무 강한 경우가 많다. 이때 OCP규칙을 적용하려면 FLIP-FLOP패턴을 적용하여 View와 Controller사이의 결합도를 낮춘다. FLIP-FLOP패턴은 뷰와 컨트롤러 각각 인터페이스를 생성하여 상대방의 인터페이스를 참조하게한 후 컨트롤러모델에서 뷰의 동작을 제어하는 형태를 가지는 방식이다. 이렇게 구현하는 경우 뷰와 컨트롤러 각각 테스트 케이스 작성시 SELF SHUNT패턴을 사용하여 의존성이 있는 객체를 대체할 수 있게 된다. 즉 TDD방식으로 구현하게 된다면 위와 같은 구조로 개발하기 수월해진다.
클래스를 변경하지 않고도 그 클래스의 환경을 바꿀 수 있어야 한다.
LSP : 리스코프 교체 원칙
1. 서브타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다. 즉 instanceof(클래스지정) 이나 다운캐스트를 할 필요가 없어야한다. 사용자는 파생클래스에 대해 알 필요가 없어야 한다. 이런 경우는 동일 의미를 가진 클래스이지만 실행 방식이 다른 클래스를 하나의 기반 타입으로 묶으려고 할 때 발생하게 된다. 다른 실행 방식으로 인해 예외 상황을 명시하기 위해 다운캐스트나 instanceof를 사용하게 된다. 이때 동일 의미이지만 다른 기반 성격의 클래스로 분류해야한다.
유도된 크래스으 메서드를 퇴화시키거나 불법으로 만드는 일을 피하라. 기반 클래스의 사용자는 기반 클래스에서 유도된 클래스에 대해 알 필요가 없다.
DIP : 의존 관계 역전 원칙
1. 고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두모듈 모두 다른 추상화된 것에 의존해야 한다.
2. 추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화 된것에 의존해야 한다.
즉 자주 변경되는 컨크리트 클래스에 의존하면 안된다. 어떤 클래스에서 상속받아야 한다면, 기반 클래스를 추상 클래스로 만들어야 한다.
어떤 클래스의 참조를 가져야 한다면, 참조 대상이 되는 클래스를 추상 클래스로 만들어야한다. 만약 어떤 함수를 호출해야 한다면 함수를 추상 함수롤 만들어라. 여기서 말하는 클래스는 자주 변경되는 컨크리트 클래스 이다. 즉 개발 중인 클래스이거나 변할 가능성이 높은 비즈니스 규칙을 담은 클래스이다. UML을 사요아면 이 원칙을 쉽게 검사할 수 있다. 다이어그램의 화살표마다 인터페이스나 추상 클래스를 가리키는지 확인하면 된다.
자주 변경하는 컨크리트 클래스 대신 인터페이스나 추상 클래스에 의존하라
ISP : 인터페이스 격리 원칙
비대한 클래스 메서드를 다 사용하는 일은 매우 적다. 즉 필요치 않은 메서드에 의한 변화도 영향을 받게 된다. 이런 의존 관계는 필요한 인터페이스만 제고하여 필요하지 않은 메서드를 보호하면 된다.
어떤 객체의 사용자에게 필요한 메서드만 있는 인터페이스를 제공하라
'UML,OOP,Pattern, TDD' 카테고리의 다른 글
Strategy pattern VS Brigde Pattern (0) | 2011.10.09 |
---|---|
TDD - 계약에 의한 설계(DbC, Design by Contract) (0) | 2011.04.19 |
TDD Tip (0) | 2011.04.19 |
객체지향 개발 관련 팁 (0) | 2011.04.19 |
UML Tip (0) | 2011.04.19 |