[이펙티브 자바] Item18. 상속보다는 컴포지션을 사용하라.

 

[이펙티브 자바] Item18. 상속보다는 컴포지션을 사용하라. 

상속을 사용하면 코드를 재사용할 수 있지만, 잘못 상속하면 오류가 발생할 수 있다. 

상위 클래스와 하위 클래스가 모두 같은 프로그래머가 통제하는 패키지 안이면서 확장할 목적으로 설계되었고, 문서화도 잘 된 클래스라면 상속도 안전한 방법이 된다. 

하지만 일반적인 구체 클래스를 패키지 경계를 넘어서 다른 패키지의 구체클래스로 상속하는 일은 오류가 발생할 위험이 존재한다!!

 

 

👾 메서드 호출과 달리 상속은 캡슐화를 깨트린다. 

: 상위 클래스가 어떻게 구현되느냐에 따라서 하위 클래스의 동작에 이상이 생길 수 있다. 

상위 클래스가 릴리즈마다 내부 구현이 달라질 수 있는데, 그에 따라서 상속을 받은 하위 클래스에서 오동작 할 수 있다. 

 

상위 클래스 설계자가 확장을 충분히 고려하고 문서화도 제대로 해두지 않았더라면 하위클래스는 상위 클래스의 변화에 맞춰서 항상 수정해야만 한다.. 

public class InstrumentedHashSet<E> extends HashSet<E>
{
   // 추가된 원소의 수
   private int addCount = 0;
   
   public InstrumentedHashSet()
   {
   
   }
   
   public InstrumentedHashSet(int initCap, float loadFactor)
   {
      super(initCap, loadFactor);
   }
   
   @Override
   public boolean add(E e)
   {
      addCount++;
      return super.add(e);
   }
   
   @Override
   public boolean addAll(Collection<? extends E> c)
   {
      addCount += c.size();
      return super.addAll(c);
   }
   
   public int getAddCount()
   {
      return addCount;
   }
   
   public static void main(String[] args)
   {
      InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
      s.addAll(List.of("틱", "탁탁", "펑"));
      System.out.println("s.getAddCount() = " + s.getAddCount());
   }
}

InstrumentHashSet은 HashSet을 사용한느데 여기서 HashSet이 처음 생성된 이후에 원소가 몇 개 더해졌는지 알 수 있어야 한다. 

따라서 HashSet에 원소를 추가하는 메서드인 add와 addAll을 재정의했다. 

 

main에서 이제 List of 를 사용해서 리스트를 생성해서 원소 3개를 더했다고 하면 getAddCount의 값으로 3을 예측할 것이다.

정상적으로 3이 출력될 것이라고 예상했지만 결과는 6이 나온다. 

왜냐하면 HashSet의 addAll 메서드가 add 메서드를 사용해서 구현되어 있기 때문이다..!

여기서 addAll 메서드가 add 메서드를 호출해 추가하는데, 이때 add는 InstrumentHashSet에서 재정의한 메서드인 add를 호출하게 된다. 

따라서 addCount 값이 중복해서 더해져서 결과로 6이 출력된 것이다!

 

 

💡 기존 클래스를 확장하는 대신 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하자. 

: 기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 뜻에서 이러한 설계를 컴포지션 Composition이라고 한다. 

새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환한다.  -> 이 방식을 전달(forwarding) 이라고 하며, 새 클래스의 메서드들은 전달 메서드 (forwarding method) 라 부른다. 

 

컴포지션으로 구현하면 새로운 클래스는 기존 클래스의 내부 구현 방식의 영향에서 벗어나며, 심지어 기존 클래스에 새로운 메서드가 추가되더라도 전혀 영향받지 않는다. 

public class ForwardingSet<E> implements Set<E>
{
   private final Set<E> s;
   
   public ForwardingSet(Set<E> s)
   {
      this.s = s;
   }
   
   public void clear()
   {
      s.clear();
   }
   
   public boolean contains(Object o)
   {
      return s.contains(o);
   }
   
   public boolean isEmpty()
   {
      return s.isEmpty();
   }
   
   public int size()
   {
      return s.size();
   }
   
   public Iterator<E> iterator()
   {
      return s.iterator();
   }
   
   public boolean add(E e)
   {
      return s.add(e);
   }
   
   public boolean remove(Object o)
   {
      return s.remove(o);
   }
   
   public boolean containsAll(Collection<?> collection)
   {
      return s.containsAll(collection);
   }
   
   public boolean addAll(Collection<? extends E> collection)
   {
      return s.addAll(collection);
   }
   
   public boolean removeAll(Collection<?> c)
   {
      return s.removeAll(c);
   }
   
   public boolean retainAll(Collection<?> collection)
   {
      return s.retainAll(collection);
   }
   
   public Object[] toArray()
   {
      return s.toArray();
   }
   
   public <T> T[] toArray(T[] a)
   {
      return s.toArray(a);
   }
   
   
}

 

-> ForwardingSet은 재사용할 수 있는 전달 클래스

 

public class InstrumentedSet<E> extends ForwardingSet<E>
{
   private int addCount = 0;
   public InstrumentedSet(Set<E> s)
   {
      super(s);
   }
   
   @Override
   public boolean add(E e)
   {
      addCount++;
      return super.add(e);
   }
   
   @Override
   public boolean addAll(Collection<? extends E> collection)
   {
      addCount += collection.size();
      return super.addAll(collection);
   }
   
   public int getAddCount()
   {
      return addCount;
   }
   
   public static void main(String[] args)
   {
      InstrumentedSet<String> s = new InstrumentedSet<>(new HashSet<>());
      s.addAll(List.of("틱", "탁탁", "펑"));
      System.out.println("s.getAddCount() = " + s.getAddCount());
   }
}

 

InstrumentedSet은 HashSet의 모든 기능을 정의한 Set 인터페이스를 활용해 설계되었다. Set 인터페이스를 구현하고, Set의 인스턴스를 인수로 받는 생성자를 하나 제공했다. 임의의 Set에 계측 기능을 덧씌워 새로운 Set을 만드는 것이 이 클래스의 핵심이다. 

 

다른 Set 인스턴스를 감싸고 (warp) 있다는 뜻에서 InstrumentedSet 같은 클래스를 래퍼 크래스라고 하며, 다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴이라고 한다. 

 

 

 

📖 정리 

상속은 반드시 하위 클래스가 상위 클래스의 '진짜' 하위 타입인 상황에서만 사용해야 한다. 클래스 B가 클래스 A와 is-a 관계일 때만 클래스 A를 상속해야 한다. 

컴포지션을 사용해야 하는 상황에서 상속을 사용하는 건 내부 구현을 불필요하게 노출하는 것이며, 이러한 결과로 api가 내부 구현에 묶이고 그 클래스의 성능도 영원히 제한되게 된다. 그리고 더 심각한 문제는 클라이언트가 노출된 내부에 직접 접근할 수 있다는 점이다. 

 

컴포지션 대신에 상속을 사용하기로 했다면 확장하려는 클래스의 api에 아무런 결함이 없는가?  만약 결함이 있다면 이 결함이 하위 클래스로 전파돼도 괜찮은가? ... 에 대해서 생각해봐야 한다. 

 

상속의 취약점을 피하려면 상속 대신에 컴포지션과 전달을 사용하자!!