Whiteship's Note


EJ2E Item 18. 추상 클래스 보다는 인터페이스를 선호하라

Java : 2009.01.19 01:43


참조: Effective Java 2nd Edition. Item 18: Prefer interfaces to abstract classes

기존 클래스를 쉽게 수정하여 새로운 인터페이스를 구현할 수 있다.
- 인터페이스는 implements에 추가해주고 필요한 매서드를 구현하면 끝
- 하지만 새로운 추상 클래스를 만들어서 공통 로직을 상위로 올린다면, 하면 하위 클래스에는 자신에게 적당할지 안 할지도 모를 로직들을 상속받게 된다.

믹스인을 정의할 때 인터페이스가 제격이다.
- 믹스인(Mixin)이란 "원래 타입"에 어떤 부가적인 행위를 추가로 구현했다는 것을 나타내는 타입. ex) Comparable 인터페이스
- 추상 클래스는 믹스인으로 쓰기 어렵다.(단일 상속이니까)

인터페이스 계층구조가 아닌 타입 프레임워크를 구성할 수 있게 한다.

인터페이스는 Item 16에서 살펴본 wrapper class 개념을 통해 안전하고, 강력한 기능성 증진을 가져다준다.
- 추상 클래스를 사용하여 타입을 정의하면, 개발자가 기능을 추가하고 싶을 때 상속만을 써야 한다. 그 결과 클래스가 wrapper 클래스보다 점점 약해지고 깨지기 쉬워진다.

인터페이스 장점과 추상 클래스 장점을 추상 skeletal 구현체 클래스를 제공하여 얻을 수 있다.
- skeletal 인터페이스 = Abstact인터페이스, 해당 인터페이스를 구현할 때 필요한 모든 작업을 포함하고 있다.
- 개발자가 해당 인터페이스를 쉽게 구현할 수 있도록 도와준다.
- 보통은 skeletal 인터페이스를 extends 하여 만들지만, 그렇게 못할 경우에는 인터페이스를 직접 implements해도 된다.
- 인터페이스를 구현하고 그 것을 구현할 때 skeletal 클래스를 상속 받은 private inner class에 매소드 호출을 위임하는 식으로 구현할 수 있다. (simulated multiple inheritance)

인터페이스를 배포 한 뒤 그 구현체가 많아졌다면 그것을 변경하는 건 불가능에 가깝다.
- 따라서 주의해서 설계해야한다.
- 인터페이스를 정하기 전 가능한 여러 개발자가 그것을 구현해보게 하는 것이 최선이다.

top

  1. Favicon of http://naucika.pe.kr BlogIcon naucika 2009.01.19 08:12 PERM. MOD/DEL REPLY

    EJ2E 에 종속되는 내용은 아닌것 같습니다.
    그래도 실제 구현시에 인터페이스를 많이 쓰는건 사실 귀찮습니다. 그래서 설계가 무엇보다 중요하겠지만, 시간에 쫏기다 보면 유연성을 확보하기 위해 너무 많은 사전작업이 들어가 인터페이스를 잘 안쓰게 되더군요. 후회는 막급합니다만.....

    Favicon of http://whiteship.me BlogIcon 기선 2009.01.19 09:45 PERM MOD/DEL

    넹.. 저도 아직 인터페이스가 언제 어떻게 왜 필요한지 타당하게 말을 못 하겠습니다.

    모듈 간에 소통을 할 때 그 다리 역할로 사용하는 건 어느정도 이해가 되는데, 모듈 내에서(layered 아키텍처라는 전제하에) 계층 사이에서의 인터페이스가 꼭 필요한지는 조금 의문입니다.

  2. Favicon of http://www.arload.net BlogIcon arload 2009.01.19 10:59 PERM. MOD/DEL REPLY

    서로간에 장,단이 있는것 같습니다.

    실제 Framework 이나 라이브러리 설계때는 일괄적인 흐름을 주기 위해선
    Template Method를 써야 하거든요.

    그때 대안은 Abstract 입니다 . .NET Framework 의 설계자 Krzysztof Cwalina는 interface보다는 abstract를 선호하라고 애기하고 있습니다.

    to. 기선님
    layered 아키텍쳐 같은 경우는 interface 로 제어하기 보다는
    메세지 프로토콜을 결정해서 주고 받는 것이 낫습니다. layer에서 주고 받는 기능을 interface로 일일이 나열하기란 힘듭니다.

    composite message pattern 같은 것이 더 나을수 도 있습니다. google에 검색하시면 제가 등록한 도영상 강의를 보실수 있을거에요 :)
    그럼 수고하셔요 :)

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2009.01.19 11:19 신고 PERM MOD/DEL

    그렇군요. arload님 의견에 공감합니다.
    다 장단점이 있겠죠~

    좋은 강의 알려주셔서 감사합니다. :)

    Favicon of http://toby.epril.com BlogIcon 토비 2009.03.13 22:49 PERM MOD/DEL

    일괄적인 흐름을 주기 위해서 template을 가진 method를 만드는 것은 맞지만, 그게 Template Method Pattern으로 구현되야 할 이유는 없습니다.
    Template method에서 훅 메스도들이 아닌, 조합되어있는 협력객체들을 (주로) 인터페이스를 통해서 호출해주는 것이 훨씬 편하고 적절할 때가 많습니다.
    자바에 자주 등장하는 싱글 훅킹 메소드를 가지는 템플릿에 자주 사용되는 callback/template 스타일의 strategy 패턴의 경우도 Template Method Pattern의 상속방식 - 즉 클래스 구조의 패턴을 이용하지 않습니다.

    세상의 모든 것에는 다 장단점이 있겠지만, 원 글에서 설명한 내용은 인터페이스 사용이 적절한 예이고 그 장점이 분명합니다.

Write a comment.