<aside> 💡 상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다!

</aside>

• 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안이라면 안전하다.

  • 하지만, 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.

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

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

public class InstrumentedHashSet<E> extends HashSet<E> {

		private int addCount = 0;

		public InstrumentedHashSet() {
		}

		public InstrumentedHashSet(final int initCap, final float loadFactor) {
				super(initCap, loadFactor);
		}

		@Override 
	  public boolean add(final E e) {
				addCount++;
				return super.add(e);
		}

		@Override 
		public boolean addAll(final Collection<? extends E> c) {
				addCount += c.size();
				return super.addAll(c);
		}

		public int getAddCount() {
				return addCount;
		}
}

• 위 클래스는 잘 구현된 것 같지만, 제대로 동작하지 않는다!
  • addAll 메서드로 원소 3개를 인스턴스에 더했다고 해보자.

InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(List.of("틱", "틱틱", "펑"));

• 결과는 3이 아니라, 6이 나온다!
  • HashSet 의 addAll 은 각 원소를 add 메서드를 호출해 추가하는데, 이 때 불리는 add 는 InstrumentedHashSet 에서 재정의된 메서드이다.
  • 따라서, addCount 에 값이 중복해서 더해진 것.

→ 하위 클래스에서 addAll 메서드를 재정의하지 않거나, 다른 식으로 재정의하면 해결할 수 있다.

• 하지만 어렵고, 시간도 더 들고, 오류를 내거나 성능을 떨어뜨릴 수도 있다.
  • 또한, 하위 클래스에서 접근할 수 없는 private 필드를 써야 한다면 구현 자체가 불가능하다.

하위 클래스가 깨지기 쉬운 이유는 또 존재한다.

• 다음 릴리스에서 상위 클래스에 새로운 메서드를 추가한다면?
  • 하위 클래스에서 재정의하지 못한 그 새로운 메서드를 사용해 허용되지 않은 원소를 추가할 수 있게 된다.
  • ex) 실제로 Hashtable 과 Vector 를 컬렉션 프레임워크에 포함시키자, 관련된 보안 구멍을 다 수정해야 했었다.

<aside> 💡 다행히, 이상의 문제들을 모두 피할 수 있다! → 컴포지션(composition : 구성)

</aside>

• 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하자.
  • 새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환한다.
  • 새로운 클래스는 기존 클래스의 내부 구현 방식의 영향에서 벗어나며, 기존 클래스에 새로운 메서드가 추가되더라도 전혀 영향을 받지 않는다!