머신러닝(주로 연구) 파이썬에 익숙한 사람들은 프로그램 구조화에 대한 고민을 크게 하지 않는다. 나는 상대적으로 연구보다는 엔지니어링을 많이 했다보니 코드는 금방 방대해졌고 기능추가와 확장성이 좋은 소스코드 구조에 대해 갈증을 느끼곤 했다. 이를 클린 코드, 클린 아키텍처라고 하는 것 같다.
코드 구조화를 고민하고 찾아보다 보면 자연스럽게 UML의 클래스 다이어그램이라는 것을 알게 되는데, 그나마 금방 익숙해지는 것은 상속과 관련된 것들이다. 일반화(Generalization)나 실체화(Realization)이 여기 속한다.
하지만 언제나 연관관계라는 벽에 부딪게 되었다. 상속관계와 기호는 이해했지만 연관관계와 기호들이 이해되지 않았던 것이다. 그래서 모든 것들을 다 그냥 ‘의존관계’ 정도로 표현하고 말았다. 여기서 아쉬움이 있었다. 분명히 연관관계 표기를 구체적으로 나누어 구분해 둔 이유가 있을텐데…
인터넷에서 흔히 찾아볼 수 있는 그림.
난 처음 이것들을 다 외워 버리려고 했다. 뭐 화살표를 외워 버리는 것도 좋다. 하지만 이친구 이거 생각보다 이해할만하다. 한 번 이해해두면 잊기 쉽지 않다. 상속관계와 기호는 이해했지만 연관관계와 기호들이 이해되지 않는다면, 모든 것을 지우고 의존과 연관 기호의 의미를 먼저 이해해야 한다.
표로 정리되어 있어 복잡해 보이지만, 가장 위부터 하나씩 읽어나갈 수 있게 적어보았다. 하나씩 읽어보자.
| 의존(Dependency)
| → | 일단 의존이라는 단어를 다시 바로잡자. 의존이라는 단어 자체가 범용적인 단어라 혼란을 많이 만든다. 정말 쉽게 말해 의존은 화살표의 방향을 의미한다. 한편, 의존이라는 단어가 연관-합성-집합과 비교되기도 하는데, 이들과 나란히 비교하는 것은 혼동을 줄 수 있으므로 피하도록 하자. 왜냐하면 의존은 연관-합성-집합 없이도 이해할 수 있기 때문이다. SOLID 라는 것을 들어 본 사람이라면, **‘의존성 역전’**이라는 단어는 한번쯤 들어 보았을 것이다. ‘의존성 역전’ 에서 말하는 의존은 의존관계가 어떻게 만들어졌든 상관없이(앞으로 배울 연관 관계나 일반화, 실체화 관계) 그냥 화살표 끄트머리를 의미하기 때문이다. 이들은 모두 ‘저 화살표로 짚은 저 자식이 변하면 나도 바뀌어야 할지도 몰라’ 라는 것을 나타낸다. 그 이상의 의미는 없다. (ref: … aggregation and composition describe how things are build/structured, while dependency is more a property of a certain structure) |
|---|---|
| 연관(Association) | |
| ——— | 연관은 어떤 클래스의 멤버 변수로 다른 클래스의 객체를 들고 있음을 의미한다. 구성연관(Composition)이나 집합연관(Aggregation)을 이해하기 전에 그냥 연관을 이해해야 하는 이유다. (ref: association almost always implies that one object has the other object as a field/property/attribute). 기호가 의미하듯, 다른 클래스의 참조값만을 들고 있다는 것은 그 어떤 화살표도 만들지 않는다. 어떤 클래스가 멤버 변수로 어떤 클래스를 들고 있는 것은, 의존하는 클래스의 변화와 관련이 없다. 따라서, 멤버변수로 들고 있는지 아닌지를 실선과 점선으로 표현한다고 생각하면 된다. |
| 양방향 연관 | |
| ←——→ | 앞서 의존은 연관 없이도 이해할 수 있다고 했지만, 멤버 변수로 다른 클래스의 참조를 들고 있다면 의존을 할 가능성이 높다. 그래서 주로 연관은 화살표와 함께 그려진다. |
| 단방향 연관(Direct …) | |
| ——→ | 당연히 단방향으로 연관을 만들수도 있다. 이를 단방향(Direct) 연관이라고 한다. (ref: IBM Documentation, In UML models, directed association relationships are associations that are navigable in only one direction.) |
| 의존하지만 연관은 아님 |
Engine is created inside Car. The Engine object is part of the Car. This means that a Car is composed of an Engine.) 이제 UML에는 동시에 사라지는지 아닌지를 표기할 기호가 필요하다. 화살표 반대쪽에 다이아몬드를 붙인다. 이 경우 다이아몬드는 꽉 차있다. |
| 집합(Aggregation)
o——→ | 연관의 한 형태다. 그래서 집합연관이라고도 한다. 자동차 클래스는 운전자를 멤버 변수에 등록하지만, 자동차가 폐기되어도 운전자는 생존할 수 있다. (ref: … A child object can exist outside the parent object. A Car has a Driver. The Driver CAN Exist outside the Car.) 화살표 반대쪽에 다이아몬드를 붙인다. 이 경우 다이아몬드는 비어 있다. |위 표에서 기호들을 중심으로 다시 정리해보자.
| 연관관계 표현 | 선택지1 | 선택지2 |
|---|---|---|
| 의존 방향 | 부등호 모양의 화살표 | 없음 |
| 멤버 변수 | 실선 | 점선 |
| 멤버 변수의 공동 생성과 소멸 | 속이 꽉 찬 다이아몬드 | 속이 비어 있는 다이아몬드 |
우리는 연관관계에서의 의존관계들을 이해했지만, 이 기호의 본질은 상속에도 적용된다.
| 상속관계 표현 | 선택지1 | 선택지2 |
|---|---|---|
| 의존 방향 | 세모 모양의 화살표 | |
| 부모클래스에 구현체가 존재 | 실선 | 점선 |
그게 무슨 말일까? 위 두 개 표에 공통적으로 적용되는 본질은 생각보다 단순하다. 바로 **화살표, 밀함(dense), 소함(sparse)**이다.