1. 요구사항에 대해 일반적으로 보이는 명사나 비슷한 대상을 가지고 대충 관계를 맺지 말아야한다.
-> 이런 행동은 허깨비 클래스, 상상뿐인 추상화, 하나님 클래스 등을 생성할 여지가 있고 실제 코드로 작성이 엉망으로 바뀔 가능성이 많다.

허깨비 클래스 : 실제 단순한 기능을 하는 부분을 어뎁터 생성하게 되어 기능을 사용할 때 필요 없는 클래스
상상뿐인 추상화 : 개념에 의해서 추상 클래스를 생성 한 후 다른 클래스에서 전혀 사용하지 않은 클래스
하나님 클래스 : 여러 객체로 기능을 분리하였지만 실제 중요한 동작은 한 클래스에 몰려있게 되는 클래스

2. 문제를 생각해야 한다.
-> 실제 요구사항들이 진행되는 과정을 이해하고 클래스로 구현해야 하는 문제가 무엇인지 파악해야 한다. 하지만 이때에도 주의해야 할 사항이 있다.

선을 넘어간 연결 : 각 과정을 나누고 난뒤 물리적인 순서로 연관을 맷을 경우 문제가 발생한다. 즉 논리적인 관점에서 과정의 연관을 생각해야한다.

3. 사용자 인터페이스를 생각한다.
-> 실제 사용자(호출하는 대상) 관점에서 객체와 상호작용할 수단을 만든다. 인터페이스 내에서 위 단계에서 도출된 클래스와 어떻게 연결될지 논리적인 관점에서 생각한다. 이런 연결을 협력 다이어그램으로 표현 한 후 추상 모델 클래스 다이어그램으로 정의할 수 있다.

4. 추상 모델을 실제 구현한다.
-> 생성 된 모델을 현재 환경에 의존하지 말도록 구체적으로 고민해야 한다. 즉 DIP를 사용하여 의존관계에 대해 생각해본다. 그리고 의존관계를 인터페이스로 분리하여 세부 사항 정의 할 때 고차원적인 정책과 한정 된 유도 클래스 내 행동(메소드)을 분리해야 한다.

'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

+ Recent posts