[Effective Java] Item64. 객체는 인터페이스를 사용해 참조하라!

Item64. 객체는 인터페이스를 사용해 참조하라!

핵심 정리

• 매개변수 타입을 클래스가 아닌 인터페이스로 사용하라는 아이템 51의 조언을 ‘객체는 클래스가 아닌 인터페이스로 참조하라’ 라는 조언으로 확장할 수 있다.
• 적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라.
• 객체의 실제 클래스를 사용해야 할 때는 ‘오직’ 생성자로 생성할 때 뿐이다.
• 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질 것이다.
  • 다른 코드는 전혀 손대지 않고 새로 구현한 클래스로 교체가 가능해진다.
  • 다만 LinkedHashSet 처럼 선언 순서를 사용하는 코드를 HashSet으로 변경해 순서 보장을 하지 못해 생기는 문제에 대한 고려는 필요하다.
  • 구현 타입을 바꾸는 이유는 원래 것보다 성능이 좋거나 멋진 신기능을 제공하기 때문일 수 있다.
• 선언 타입과 구현 타입을 동시에 바꾸면 되니, 구현 타입으로 선언해도 괜찮을 것이라 생각할 수 있다.
  • 자칫하면 프로그램이 컴파일되지 않을 수 있다.
    • 기존 타입에서만 제공하는 메서드를 사용했을 때
    • 기존 타입을 사용해야 하는 다른 메서드에 그 인스턴스를 넘겼을 때
• 적합한 인터페이스가 없다면 당연히 클래스로 참조해야 한다.
  • String, BigInteger 같은 값 클래스가 그렇다. 값 클래스를 여러 가질 구현될 수 있다고 생각하고 설계하는 일은 거의 없기 때문이다.
    • final인 경우가 많고, 상응하는 인터페이스가 별도로 존재하는 경우가 드물다.
    • 값 클래스는 매개변수, 변수, 필드, 반환 타입으로 사용해도 무방하다.
  • 클래스 기반으로 작성된 프레임워크가 제공하는 객체가 그렇다.
    • 이런 경우라도 구현 클래스보다는 기반 클래스를 참조하도록 하자.
  • 인터페이스에는 없는 특별한 메서드를 제공하는 클래스가 그렇다.
    • 예를 들어 PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다.
• 적합한 인터페이스가 없다면 클래스의 계층구조 중 필요한 기능을 만족하는 가장 덜 구체적인(상위의) 클래스를 타입으로 사용하자.

예시

• 좋은 예 - 인터페이스 타입

  List<String> stringList = new ArrayList<>();
  

• 나쁜 예 - 클래스 타입

  ArrayList<String> stringList = new ArrayList<>();