행복한 아빠

클래스 설계에서 "관계" 집중 조명 본문

SW디자인

클래스 설계에서 "관계" 집중 조명

행복한아빠 2008. 3. 16. 19:42


설계를 하면서 클래스간의 관계에 대해 정확한 이해없이 설계하는 경우가 있다.
물론 문제 영역마다 그 관계의 종류가 명확하지 않을 수도 있고 aggregation이나 composition의 경우 미묘한 차이가 있어 너무 까탈스럽게 따지는 것도 그리 좋은 생각은 아니다.

동기
그러나 관계의 종류를 명확하게 하지 않을 경우 설계자의 의도와는 다른 결과물을 생성하는 경우를 종종 본다. 클래스 설계를 UML로 주로 하는데 여기서는 클래스간의 관계 중 dependecy, association, aggregation, composition 4가지를 정리해 보겠다. Generalization(클래스 상속)이나 Realization(인터페이스 구현,실현)은 그나마 명확하기에 제외하였다.

Dependency
의존이란 제일 약한 관계로 그야 말로 한 클래스가 다른 클래스에 어떻게든 의존한다는 뜻이다. A클래스가 B클래스를 가지고 있을 수도 있고, 상속을 할 수도 있는 것이다. 즉 A 클래스가 B 클래스에 의존한다는 뜻은 B클래스가 없이는 A클래스는 동작도 컴파일도 할 수 없다는 이야기이다.
따라서 모든 관계는 암시적으로 Dependecy 관계를 가지고 있다. 다른 관계는 명확하게 그 표기법이 정해져 있으므로 보통 그외의 의존관계를 이 표기법으로 표시한다.

사용자 삽입 이미지
보통 dependency가 쓰이는 경우는 AClass에서 BClass를 멤버로 가지고 있지는 않으나 메소드 내에서 아규먼트로 사용한다던지 메소드 내의 지역변수로 사용하는 경우에 사용한다.
따라서 모델에서 dependency 관계가 굉장히 많아질 수 있으므로 보통 중요하다고 강조할 부분만 dependency를 표시하곤 한다.

Association
서로 독립적인 객체가 서로 상호작용하기 위해 멤버로 참조해야 할 경우 사용한다. 이 관계는 일 대 일, 일 대 多, 多 대 多 등 다양한 관계를 만들 수 있다. 객체 연결 시 관계에 상대 객체에 대한 자신의 역할이름을 줄 수 있으며 이 역할 이름이 상대 클래스의 멤버변수 이름이 된다. 또한 관계의 종류에 따라 cardinality를 지정하여 일대일인지 일대다인지 표기할 수 있다.
사용자 삽입 이미지

위 그림과 같은 교수와 학생간의 관계에서 볼 때 교수와 학생은 각각 독립적으로 충분한 의미가 있는 것이다. 단지 교수는 학생의 "스승", 학생은 교수의 "제자들"이란 관계가 있는 것이다. 이는 학생이 교수에 교수가 학생에 일방적으로 포함되거나 구속하지 않는 관계를 말한다.


Aggregation
전체가 부분을 포함하는(has a) 관계를 나타내며 다음에 설명할 Composition 보다는 약한 관계이다. Association과 비슷하나 인스턴스들이 순환적(cyclic)인 관계를 갖지 않는다.
사용자 삽입 이미지
위 관계에서 학생회는 학생들을 포함하고 있다. 이 관계에서 다시 학생이 학생회를 포함하는 순환관계는 갖지 않을 것이다. 또한 학생회에 포함된 학생들은 다른 곳에서도 참조되어 공유가 가능하다.
예를 들어 "홍길동"은 학생회도 속하지만 특정 동아리에도 속할 수 있을 것이다. 학생회의 "홍길동"과 동아리의 "홍길동"은 동일한 인스턴스이므로 만일 홍길동의 전화번호를 변경한다면 두 곳 모두에서 변경된 전화번호를 가진 홍길동을 볼 수 있다.
이와 같이 보통 포함하는 관계이지만 포함하는 클래스와 포함되는 클래스의 생명주기(라이프사이클)는 다르다. 즉 학생회가 생길 때 학생이 생기지 않으며 학생회가 삭제된다고 학생이 삭제되지는 않는다.

Composition
마찬가지로 전체가 부분을 포함하는(uses a) 관계를 나타내며 강력한 포함관계를 나타낸다. Aggregation과 비슷하지만 보통 포함하는 클래스와 포함되는 클래스의 생명주기가 동일하다.
사용자 삽입 이미지
위의 관계처럼 학생이 주소 객체를 가지고 있는 경우 보통 주소를 학생의 일부분으로 취급한다. 이는 학생을 삭제할 경우 주소도 더 이상 의미가 없으므로 삭제될 것이다. 즉 이 둘은 동일한 생명 주기를 지닌다.
또한 "홍길동" 학생의 주소 인스턴스를 다른 학생의 인스턴스가 참조하여 공유할 수 없다. 공유할 경우 "홍길동"의 주소를 변경한다고 이를 참조하는 다른 학생의 주소가 의도하지 않게 바뀐다면 문제가 될 것이다.

모델의 관계가 Compostion인데 생성하는 객체의 극도로 수가 많아져 문제가 될 경우 GoF 패턴 중 flightweight를 쓸 수도 있다. 이 때는 좀 다른 방법으로 문제를 해결한다.

정리
물론 이러한 관계의 정의가 설계하는데 결정적인 영향을 미치지는 않는다. 보통 처음에는 객체간의 관계가 불명확해서 모두 Association으로 연결하다가 점정 상세화하면서 Aggregation이나 Composition으로 변경하곤 한다.
그러나 이러한 관계의 차이를 정확히 이해하는 것이 개발자 입장에서 설계자의 의도를 파악하거나, 설계자의 입장에서 구현에 미치는 영향을 예측하는데 도움을 줄 수 있을 것이다.

'SW디자인' 카테고리의 다른 글

알고리즘 보다는 구조에 집중하세요  (9) 2010.04.05
Dependency Injection-1  (5) 2009.12.30
AOP와 filter  (2) 2009.11.17
클래스 설계에서 "관계" 집중 조명  (0) 2008.03.16
Dependency Injection-3  (0) 2008.03.15
Dependency Injection-2  (0) 2008.03.15
0 Comments
댓글쓰기 폼