잘 이해하지 못한다.
난 합성이 왜 더 좋은지 이해하지 못하는 사람들을
이해하지 못하겠다.
합성은 상속으로부터 자유롭기 때문에
OOP 원칙에 더 잘 부합된다.
상속은 상속하는 순간
상속 계층구조에 묶여버리기 때문에
아무리 상위 클래스의 메서드를 스텁 함수로 만든다 하더라도
상위 클래스의 로직으로부터 완전히 자유로울 수 없다.
하지만 합성은 설령 상위 클래스가 바뀌더라도
얼마든지 자유롭게 구현할 수 있다.
사실 플렉스 개발자 중에 TextInput 컴포넌트가 실제로는
상속이 아니라 합성으로 구현한 것임을 제대로 알고 있는 개발자가 얼마나 될까?
사실 상속으로 치자면 TextInput 컴포넌트는 그냥 UIComponent다.
그런데 합성을 통해 마치, "훗, 난 처음부터 텍스트 인풋이었다고"라고 말하는 것처럼
누가 보기에도 텍스트 인풋처럼 돼 버렸다(심지어 클래스명까지...)
이처럼 합성은 마법 같은 힘이 있다.
원하는 요소를 모아서 내가 원하는 대로 버무릴 수 있고
내부에서 사용(합성)할 다른 컴포넌트의 속성을 커스텀 컴포넌트에 정의하고
커스텀 컴포넌트에서 내부 클래스 인스턴스로 속성을 잘 전달해주기만 하면
내부 컴포넌트를 얼마든지 부려 쓸 수 있다.
이렇게 되면 상속으로 인한 상위 클래스와의 결합도를 줄일 수 있고
필요한 로직을 언제든 추가하거나 뺄 수 있다.
또 DI나 ioC를 통해 특정 기능을 수행하는 컴포넌트를 동적으로 주입해
기능을 추가하기도 훨씬 쉽다.
예를 들어 안드로이드의 DatePickerDialog도 사실은 상속으로 치자면 AlertDialog지만
내부적으로 private final DatePicker mDatePicker;를 선언해
"내가 바로 데이트피커 다이알로그다"하고 광고하고 있다.
이는 마치 인터페이스와도 닮아 있다.
한 클래스가 다중 클래스를 상속할 수는 없지만 다중 인터페이스를 구현할 수는
있는 것처럼 한 클래스는 여러 내부 클래스 인스턴스를 합성해
마치 여러 기능을 갖춘 클래스마냥 (마치 여러 클래스를 상속한 것처럼)
행동할 수 있다.
이런 사실을 잘 이해하면 얼마든지 AlertDialog를 상속해 또 다른 컴포넌트를
합성할 수 있다. 하지만 이런 사실이 잘 이해되지 않는다면
이해될 때까지 좀 더 공부할 것을 권장한다.
Posted by joshy21
