Inhertiance와 composition

개발을 하다 보면, 늘 이렇게 짤까 저렇게 짤까 고민을 하기도 한다.

특히 Inheritance로 개발할지 composition으로 개발할지 고민은 여전히 지금까지도 있다.

 

Spring IOC을 쓰는 사람은 자연스럽게 interface 1개, 구현체 1개 이렇게 만들어서 bo와 dao를 쓰고 있는 현실을 보게 된다. 볼 때 마다. 나는 좀 갑갑스럽기 하다.

 

interface나 abtract class는 기본적으로 상속이기 때문에

super를 수정할려면 좀 귀찮다. (managability가 많이 떨어진다.) 재 사용성을 위해서 쓴다는 장점과 함께~

보통 이 정도 수정되면, 크게 바뀌는 개념이라 할 수 있겠다.

 

반면 Composition을 쓰면, 쓰기가 참 편한데. 재사용성이 떨어진다는 점. (polymophism은 기본적으로 reusability를 위해서 만들어짐 개념이다.) 이 가장 떨떨하다.

또한 더 많은 인스턴스를 양산할 수 있는 소지가 발생한다.

 

항상 이런 고민인데. Effective java의 authour인 Joshua는 이렇게 써놨다.

 

Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software. It is safe to use inheritance within a package, where the subclass and the superclass implementation are under the control of the same programmers. It is also safe to use inheritance when extending classes specifically designed and documented for extension (Item 15). Inheriting from ordinary concrete classes across package boundaries, however, is dangerous. As a reminder, this book uses the word “inheritance” to mean implementation inheritance (when one class extends another). The problems discussed in this item do not apply to interface inheritance (when a class implements an interface or where one interface extends another).

 

 

패키지 내에서 상속관계, 세부적인 디자인이나 확장을 위해서 상속을 쓰는 것이 안전하다고 했다.

최대한 상속의 개념은 제한적으로 쓰는 것이 좋다는 것이 그의 주장이다.

 

아티마의 글을 볼까나?

http://www.artima.com/designtechniques/compoinhP.html

http://www.artima.com/designtechniques/interfaces.html

 

어쩌면, 정확히 이럴 때는 이렇게 쓰는 것이야 라는 고민보다는 수많은 시행착오를 통해서 겪는 것들은 정말 우리에게 도전을 주는 거 같다. 시도해보고 자신만의 노하우를 습득하고 타인의 스킬들에 대해서 인정해보면서 생각해보는 것 외에는 특별한 방법이 없긴 하다.