Aggregation 과 Composition 개념

서브클래스, 서브타입, 클래스들간의 각종 관계 등에 대해 정리해보고자 시리즈물로 준비했다.

나는 이 부분에 대해 전혀 모르기 때문에 간단한 정리가 될 것이다. 

1. 타입과 클래스들의 관계 그리고 리스코프 치환원칙

2.  Aggregation 과 Composition 개념

3. Subtype 과 Subclass

---

Aggregation 과 Composition

Composition 은 Java 개발을 하면서 “상속 대신 컴포지션을 사용하라” 라는 말로 수도 없이 많이 들어온 용어다. 그리고 알게모르게 대부분의 자바 개발자들은 Composition 을 사용하고 있으니 익숙하다..고 생각했다.

그런데 이펙티브 자바 스터디를 진행하는 과정에서 누가 화두를 꺼냈다.

Aggregation 과 Composition 의 차이는 뭔가요? 나는 몰라요….

그런데 팀원 한 분이 말씀해주신 Aggregation 이라는 용어의 정의를 듣고 나니 이 둘의 차이점이 뭔지 헷갈리게 되었다.

 

뿐만 아니라 이 용어 그대로 UML 에서 도 사용되고 있고 DDD 에서도 나온다고 하고~

이 Composition 이 저 Composition 인지~~~~그 Composition 인지..

 

ㅋㅋㅋ 헷갈려.. 나는 헷갈려서 정리 해 보기로 했다~

 

---

UML 에서의 Composition 과 DDD 에서의 Composition

UML 과 DDD 모두 소프트웨어 디자인을 위한 것들이지만

UML 은 다양한 곳에서 시스템을 시각화 하기 위해 범용적으로 사용 되는 언어(?) 인 반면, DDD 는 비즈니스 도메인을 이해하고 이러한 이해를 바탕으로 디자인 하는 것에 초점을 두고 있다.

따라서 비슷한 듯.. 다른..것..같다

( DDD 에 대해서는 한 번도 공부해 보지 않았기에 잘 모르겠다..)

근데 개념으로만 보면 그냥 완전 같아보인다. DDD 를 학습하기 전까지는 비슷하게 생각하고 있어도 좋을 것 같다.

그래서 일단 UML 에서 인스턴스들 사이의 관계에 대해서라도 정리해 보았다.

 

---

UML 에서의 Assocation, Aggregation, Composition

참조한 내용이 오래된 내용이라 현재 UML 에도 맞는지는 잘 모르겠다

• ✅ UML “Association” 은 클래스들 사이의 구조적인 연결 관계를 표현한다.
  • 마틴 파울러는 UML 의 Association 을 “어떤 한 인스턴스 가 다른 인스턴스 에게 메시지를 보낼 수 있는 능력을 나타낸다” 라고 표현했다. 객체지향 에서는 “어떤 객체가 다른 객체의 함수를 호출 하는 것” 을 “메시지를 보내는 것” 으로 표현하고는 하는데 그 메시지로 받아들여도 될 것 같다.
    • 따라서 참조인스턴스 변수, 함수의 인수, 지역변수 모두 해당 클래스 객체와 Association 관계를 갖는 것으로 볼 수 있다.
  • 어떤 관계 던 Association 이라고 표현할 수 있다(영어 뜻도 그러니..). Association 자체는 양방향이다.

Aggregation, Composition 모두 Association 의 일종이다.

Aggreagtion 과 Composition 모두 “whole-part” 관계를 표현하기 위해 사용된다.

하지만 “관계의 결합도 정도” 와 “lifecycle” 에서 차이가 존재한다.

• ✅ Aggregation
  • Association 의 특별한 한 형태다.
  • 인스턴스들끼리 cyclic aggregation 관계를 가질 수 없다. 즉, 얘는 단방향.
  • 두 인스턴스 사이에 비교적 약한 결합 도를 가짐
  • 객체 사이에 “has-a 관계” 를 갖는다.
    • has 를 보고 당연히 ownership 이 있다고 생각했는데 “ownership 이 없다. ownership 이 있다면 뭐가 다른지는 Composition 에서 알 수 있다.
    • A 와 B 사이에 “A has a B “ 라는 Aggregation 관계가 존재한다고 해 보자. 이 때 A 가 삭제된다고 하더라도 B 에는 영향을 주지 않는다.
• ✅ Composition
  • Association 중 특별한 한 형태다.
  • 두 인스턴스 사이에 비교적 강한 결합 도를 가짐
  • 객체 사이에 part-of 관계를 갖는다.
  • ownership 이 있는 집합 관계다. 부모-자식으로 표현하면 자식의 lifetime 이 부모에 의해 컨트롤된다.
    • 즉, whole 이 직접적으로 part 를 생성하고 파괴할 능력을 가질 수도 있고다른 다른 whole 에게 part 를 전달해서 그 다른 whole 에서 이를 책임지게 될 수도 있다. ( 직접 생성하지 않았더라도, 참조를 전달받아서 그 참조 객체의 lifetime 을 통제할 수도 있다 )
    • A 와 B 사이에 “B is part of A” 라는 Composition 관계가 존재한다고 해 보자. 이 때 A 가 삭제되면 B 도 함께 삭제된다.

이렇게 보면 어느정도 Aggregation 과 Composition 의 차이가 눈에 들어온다.

 

 

위의 정의에 따라 내가 이해한 내용으로 예시를 들어보겠다.

 

 

우리 서버에서 배송지 주소를 관리한다고 해 보자.

• “사용자가 없더라도 , 우리 서버에서 관리하고 있는 주소 데이터가 있을 것이다
  • Aggregation
• 사용자가 따로 등록하여, “특정한 사용자에 대한” 주소로서 관리되는 데이터
  • Composition

 

 

자주 보이는 예시로는 이런것도 있다

• Car - Wheel 의 관계
  • 바퀴 그 자체로도 독립적으로 존재할 수 있다. 바퀴가 끼워져 있던 차가 폐차 되더라도 바퀴는 차에서 떼인채로 독립적으로 존재할 수 있다.
• 집 - 거실 의 관계
  • 집이 존재하지 않는데 어떻게 거실이라는 공간이 존재할 수 있나? 거실은 집과 독립적으로 존재할 수 없다.

 

---

Java 에서의 Association

UML 에서의 Association 처럼 생각 하면 되는 것 같다. 두 클래스 사이에 생성되는 관계로 각 클래스를 통해 생성된 객체들 사이에 형성되는 관계다.

따라서 여기서도 Aggregation, Composition 관계가 존재하고 Composition 은 Aggregation 에 포함되는 관계다.

상속보다는 Composition 을 사용하라는 OOP 원칙에서 Composition 은 사실 Aggregation 의 의미에 가깝다고 생각된다. ( whole-part 관계 의 객체를 사용하라는 것으로 생각 되어짐 ) 왜냐하면 기능을 확장하거나 추가적인 기능을 사용하기 위해 해당 기능을 제공하는 다른 객체를 참조로서 갖고 있으면서 사용하는 것인데, 여기에는 ownership 관계의 여부까지는 포함되지 않은 것 같기 때문이다.

 

라고 생각을 했지만

 

일반적으로 Java 개발자들과 얘기를 하다 보면(이 글을 작성한 이후 신입으로 입사한 회사에서도) 모두 A 객체가 B 객체를 속성으로 갖고 있으면서 B 객체에 대한 ownership 까지는 갖고 있지 않은 경우에도 composition 이라 표현하고 있으니 이게 맞는건가 싶기도 하다.

 

상대방이 composition 이라는 용어를 쓰고 있다면 그 사람이 생각하는 composition 의 정의가 무엇인지 물어볼 필요도 있을 듯 하다.

 

실제로 팀원분이 우리의 도메인의 값 객체들을을 composition 으로 사용합시다~ 하셨는데 코드 상에서는 해당 값 객체들만을 따로 빼내서 사용하는 등의 로직이 많이 보여 객체들간의 라이프 사이클이 어떻게 되는지 다시 되물어 보기도 해야 했다.

 

참조

마틴파울러가정의하는Assocation-Aggregation-Composition

Association Vs. Aggregation - Is there a difference.

Aggregation 과 Composition

Difference Between Aggregation and Composition in UML