[item 19] 구체클래스를 상속 금지할때 불편한 점

[NuhGnod]

p.128에서 구체 클래스가 표준 인터페이스를 구현하지 않았는데 상속을 금지하면 사용하기에 상당히 불편해진다. 라는 문장에 대한 예가 딱 생각나지 않네요. 정확히는 어떤 점이 불편할지 궁금합니다.

[gmelon]

저도 저 문장이 잘 와닿지 않았었는데요, 저는 우선 Item 18에서 다뤘던 전달 클래스 ForwardingSet 을 생각하긴 했었습니다.

예를 들어, 어떤 기능을 추가하고 싶을 때, 상속이 불가능하면서 표준인터페이스를 구현하지 않았다면, 기능을 확장하고자 하는 상위 클래스의 public 메서드를 하나하나 가져와서 컴포지션으로 구현해야 하지만, 표준 인터페이스를 구현하고 있다면 p.118 ForwardingSet 예시처럼 implements 라는 컴파일러가 모든 메서드를 구현하도록 강제하는 문법을 사용해 편리하게 상속이 불가능한 클래스를 컴포지션으로 사용할 수 있다..? 로 우선 이해하긴 했습니다.

어떻게 생각하시는지 궁금해요!

[NuhGnod]

이 글을 보고 생각을 해봤는데, ForwarindSet예제를 살짝 변경해서 ForwardingSet클래스가 final class로 두어 상속이 불가능한 클래스이고, Set인터페이스의 메소드를 사용하기 위한 클래스라 설계한 후, implement없이 단순 구현해놓은 클래스라고 가정해보았습니다. 그리고, InstrumentedSet클래스에서 컴포지션 방식으로 ForwardingSet을 내부요소로 두는 클래스로 변경하였습니다. (상속이 불가하므로.) 이렇게 되면 2가지의 불편한 점이 발생할 것 같습니다.

1. ForwardingSet클래스에서 어떤 method를 추가하는 경우, 이 클래스를 컴포지션 방식으로 사용하고 있는 모든 InstrumentedSet1, InstrumentedSet2, InstrumentedSet3, InstrumentedSet4 ' ' ' 클래스들은 일일히 해당 method를 추가해줘야할 것 입니다. 매우 귀찮은 일일겁니다..
2. ForwardingSet클래스는 현재 Set인터페이스의 구현체 처럼 사용하기를 원하고 있습니다. 만약 Set인터페이스가 수정된다면 (method가 추가 된다면) 1번과 마찬가지로 직접 구현해줘야할 것 같습니다.

혹시 잘못된 점이나 다른 생각있으시면 스터디할 때 이야기 나누면 좋을 것 같습니다!!