'오브젝트' 책 보고 공부하기 - ⑪ 합성과 유연한 설계

1) 상속을 합성으로 변경하기

 

앞서 상속에서 보아온 문제점들은 다음과 같다.

1. 불필요한 인터페이스 상속 문제

2. 메서드 오버라이딩 오작용 문제

3. 부모 클래스와 자식 클래스의 동시 수정 문제

 

합성으로 변경하는 방법은 아주 간단하다. 부모 클래스를 자식 클래스의 인스턴수 변수로 변경하면 된다.

만약 부모 클래스의 모든 기능을 자식 클래스에서 구현해야 한다면 자바의 인터페이스를 사용해서 해결 할 수 있다.

(단, 부모 클래스 인스턴스 변수를 이용해서 메서드를 호출하는 방식으로 코드를 구현해야한다.)

 

3번의 경우 합성을 사용하여도 해결되지는 않을 수 있지만 (비즈니스 적인 연관관계)  그래도 합성이 훨씬 좋다.

파급효과를 자식 클래스내로 캡슐화할 수 있기 때문이다.

 

---

 

2) 상속으로 인한 조합의 폭발적인 증가

 

상속을 사용하게 되면 다양한 정책을 조합하게 될 때, 문제가 생길 수 있다.

첫번째 정책의 종류들이 N개이고 첫번째 정책 이후로 적용해야할 정책들이 M개이면

N x M의 상속 클래스들이 존재하여야 하고, 이후 또 추가적인 정책들이 존재하게 되면 N x M x L 갯수의 상속 클래스들을

만들어주어야한다. 

 

만약, 마지막으로 적용해야할 정책이 추가되면 M개의 클래스들이 추가되겠지만 N의 위치한 정책이 추가된 M x L +1 개의 

상속 클래스들을 또 만들어 주어야한다.

이렇게 상속의 남용으로 하나의 기능을 추가하기 위해 필요 이상으로 많은 수의 클래스를 추가해야하는 경우를

클래스 폭발 문제 혹은 조합의 폭발 문제라 한다.

 

---

 

3) 합성 관계로 변경하기

 

런타임 의존성을 받을 수 있게 최초 인터페이스를 설계하고, 또 분류에 따라서 공통 기능이 같은 클래스들을

추상클래스로 선언한다. (물론, 추상클래스는 장단점이 있으니 선택적인사항)

 

책에서 해결 코드로는 마지막 정책요소가 이전에 적용되어야할 정책요소들을 감싸주는 느낌으로 코드를 작성하였다.

이 부분은 나랑 조금 다른 시선이었는데, 나는 기본 클래스에서 절차적인 협력관계를 이용할줄 알았는데,

그 반대여서 조금 당황했다.

그러나  생성자 시점에서 바라보니 작가분이 왜 그렇게 작성하셨는지 알 수 있었다..

 

합성으로 변경후 엄청난 장점으로는 정책 클래스를 추가할 때나 변경할때, 하나의 클래스만 추가하고

하나의 클래스만 변경하면 된다는 것이다.

 

---

 

4) 믹스인

 

믹스인은 객체를 생성할 때 코드 일부를 클래스 안에 섞어 넣어 재사용하는 기법을 말한다.

합성이 실행 시점에 객체를 좋바하는 재사용 방법이라면 믹스인은 컴파일 시점에 필요한

코드 조각을 조합하는 재사용 방법이다.

 

자바에서 제공해주는 것이 있는지 찾아보았지만, 인터페이스에서 믹스인 할 수 있지만, 구현 클래스 레벨에서 믹스인

하는것은 찾지를 못했다.

 

믹스인은 클래스와 (스칼라의 트레이트)를 선형화해서 어떤 메서드를 호출할지 결정해주는데, 

자신 클래스의 메서드 -> 가장 마지막에 믹스인한 클래스의 메서드 -> 상속받은 클래스의 메서드 순으로

메서드를 찾아서 실행해준다.

어떻게 보면 합성관계에서 여러정책 중첩되는 것을 언어적 차원에서 잘 지원해준 것이 아닐까 생각이 든다.

 

믹스인한 인스턴스가 한군데서만 필요한 경우에 인스턴스를 생성할때 믹스인을 해줄 수 있지만, 여러곳에서

사용하는 경우 클래스를 명시적으로 만들어 사용하는 것이 좋다.

 

믹스인은 추상 서브 클래스 라고 불리기도 한다.

이렇게 필요한 시점에 차례대로 기능을 쌓는 믹스인이 가진 특징을 쌓을 수 있는 변경이라고 한다.