추상 클래스보다는 인터페이스를 우선하라

• 일반 적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다.
• 복잡한 인터페이스라면 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해 보자.
• 골격구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하는 것이 좋다.
• '가능한 한' 이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.

왜 인터페이스가 추상클래스 보다 우선해야 하나?

기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다.

• 인터페이스가 요구하는 메서드를 (아직 없다면)추가하고, 클래스 선언에 implements 구문만 추가하면 끝이다.
  • Comparable, Iterable, AutoCloseable 인터페이스가 추가됐을 때 표준 라이브러리의 수많은 기존 클래스가 이 인터페이스를 구현한 채 릴리즈 됐다.
• 기존 클래스 위에 새로운 클래스를 끼워넣는 것은 어려운 일이다.

인터페이스는 믹스인(mixin) 정의에 안성맞춤이다.

믹스인(mixin)

클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.

• 인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 스 있다.
  • 클래스 n개를 사용하여 만들 수 있는 조합의 수는 2^n개 이다. 흔히 조합 폭발 이라는 현상이 나타나게 된다.(Object 11장 에서도 비슷한 내용을 본 적이 있다)
  • 거대한 클래스 계층구조에는 공통기능을 정의해놓은 타입이 없으니, 자칫 매개변수 타입만 다른 메서드들을 수없이 많이 가진 거대한 클래스를 낳을 수 있다.

래퍼 클래스 관용구와 함께 사용하면 인터페이스는 기능을 향상 시키는 안전하고 강력한 수단이 된다.(rule 18 참조)

• 타입을 추상 클래스로 정의해두면 그 타입에 기능을 추가하는 방법은 상속 뿐이다. 상속해서 만든 클래스는 래퍼클래스 보다 활용도는 떨어지고 깨지기는 더 쉽다.

추가로.. 인터페이스 사용할 때 팁

• 인터페이스 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 디폴트 메서드로 제공해 프로그래머의 일감을 덜어줄 수 있다.
  • equals나 hashcode와 같은 메서드는 디폴트 메서드로 제공하면 안 된다.(왜?)
• 인터페이스는 인스턴스 필드를 가질 수 없고 public이 아닌 정적 멤버도 가질 수 없다.(단, private 정적 메서드는 예외)
• 한편, 템플릿 메서드 패턴(인터페이스와 추상 골격 구현 클래스)을 사용하여 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다.