Whiteship's Note

상위 클래스 보다는 인터페이스를...

Design Pattern : 2007.08.31 23:56


AJN의 AgileJava 4th 스터디에서 Head First Java를 가지고 스터디하고 있습니다. 이번주는 7, 8, 9장을 다룰 것 같은데 7장을 열자마자 이상함을 느꼈습니다.

해당 챕터의 주제가 "상속과 다형성" 이다보니 상속을 이야기 하기 위해 여러 예제를 보여주며 설명하고 있는데 대부분의 예제의 상위 클래스가 제가 보기엔 클래스로 정의하기에는 상당히 추상적이라 인터페이스로 선언하는 것이 맞게 보입니다.

Shape 이라는 클래스에 rotate()와 playSound() 메소드가 정의되어 있고 이 클래스를 상속한 Square, Circle, Triangle, Amoeba 클래스가 있습니다.
사용자 삽입 이미지
도대체 Shape 클래스에 있는 메소드들은 어떻게 구현을 하는 걸까요? 흠;;

상위 클래스는 아래에서 위로 만들어져야 자연스러운 것 같습니다. 반대로 위에서 아래로 구조가 만들어 질 떄는 인터페이스가 어울립니다.

상속 구조는 하위 클래스들 간에(아직 자신이 하위 클래스인줄 모르는 상태에서) 공통되는 코드가 있을 때 그것을 제거하기 위해서 상위클래스가 만들어져야 합니다. 그래야 상위클래스가 쓸모가 있어집니다. 안그럼 위처럼 멍하니 하는일이 애매한 상위클래스가 만들어집니다.

반대로 인터페이스는 애초에 다른 컴포넌트와의 약속을 위해 미리 정해 놓을 수도 있고 이 인터페이스를 구현하는 클래스에 반드시 있어야할 메소드들을 강제 할 수 있기 때문에 미리 인터페이스를 설계 해두고 클래스들이 구현하도록 할 수 있습니다. 물론 매우 자연스러운 현상이며 나중에 필요로 인해 인터페이스와 클래스들 사이에 추상 클래스가 들어설 수도 있겠습니다. 그때가 되면 아래와 같이 바뀔 것입니다.

사용자 삽입 이미지
이러한 구조로 가더라도 결국 다형성은 사용할 수 있게 되며 필요에 따라 Shape 인터페이스를 구현하여 확장할 수도 있으며 AbsractShape을 상속 받아서 구현할 수도 있기 때문에 확장성은 더욱 좋아집니다.

새로운 기능의 추가을 추가 한다고 했을 때에도 새로운 메소드를 가진 인터페이스를 구현하도록 추가만 하면 되는 반면에 상속 구조에서는 상위 클래스를 수정해야 하고, 그렇게 되면 하위 클래스들 중에는 원치 않는데도 상위 클래스의 메소드를 가지게 되는 경우가 발생할 수 도 있습니다.

이래저래 애초부터 상위클래스를 계획하지 말고 처음에는 인터페이스 기반으로 설계를 하고 상위클래스는 필요에 따라 뽑아 내는 것이 그럴싸해 보입니다.
top

  1. Favicon of http://epro.tistory.com BlogIcon epro 2007.09.01 10:29 PERM. MOD/DEL REPLY

    좋은지적인 것 같습니다. 이번주에 나갈 진도는 7,8장이구요.
    7장에선 상속을 중점적으로 설명하다보니 어색한 형태의 구조가 나온 것 같구요..
    8장에서 기선님이 지적한 부분에 대한 논의가 나오면서 interface와 abstract를 설명하고 있습니다.
    이 내용 좋네요~
    발표자료 만들고 있는데... 요 포스팅을 응용해도 되겠죠? ㅎㅎ

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2007.09.01 11:30 PERM MOD/DEL

    네 저도 써놓고나서 뒤를 계속 봤는데..
    제가 좀 성급했다는 생각이 들더라구요.
    역시 좋은 책입니다.ㅋㅋ

  2. Favicon of http://blog.naver.com/drvoss BlogIcon drvoss 2007.09.05 02:14 PERM. MOD/DEL REPLY

    Shape와 AbstractShape은 subtyping, AbstractShape와 Amoeba, Square... 은 subclassing관계라 그런것 같습니다. 설계 입장에서는 subtyping과 subclassing 사이의 목적과 사용하는 방법이 다른데도, 한국어로 번역된 책들은 subtyping과 subclassing 모두 하위클래스라고 번역을 해 버렸죠.

    첫번째 디자인의 의도는 subtyping을 이용한 인터페이스 통일 효과를 노린것이고, 두번째 디자인의 AbstractShape의 의도가 subclassing으로 보입니다. 원래 디자인 패턴이라는게 한번에 한가지씩 쓰는것이 아니라 콤보로 만들어 쓰기 때문에 subtyping을 이용한 패턴 하나는 그 나름대로 존중해 주면서 바라보는게 좋지 않나 생각됩니다.

    좋은 블로그 잘 구경하고 갑니다.

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2007.09.05 08:58 PERM MOD/DEL

    좋은 댓글 남겨 주셔서 감사합니다.

    subtyping과 subclassing이라는 이름을 붙이니까 더 명확하고 좋은 것 같습니다.

    설계 초반에는 subtyping을 그리고 구현 중에 subclassing을 끌어내자는 것이 글의 의도였지만 제목에서는 마치 subtytping이 더 좋다. 라는 식으로 이야기를 하는 것이 되어 있어서.. ㅋㅋ 잘 찝어 주셨습니다.

Write a comment.




: 1 : ··· : 6 : 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : ··· : 48 :