[ Item 64 ] 객체는 인터페이스를 사용해 참조하라

[co323co]

📚 [ Item 64 ] 객체는 인터페이스를 사용해 참조하라

적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라.

• 객체의 실제 클래스를 사용해야 할 상황은 '오직' 생성자로 생성할 때뿐이다.

예시

//좋은 예. 인터페이스를 타입으로 사용했다.
Set<Son> sonSet = new LinkedHashSet<>();

//나쁜 예. 클래스를 타입으로 사용했다!
LinkedHashSet<Son> sonSet = new LinkedHashSet<>();

• 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해진다.

// 나중에 원한다면 다음과 같이 구현 클래스만 교체할 수 있다.
Set<Son> sonSet = new HashSet<>();

주의할 점

• 원래의 클래스가 인터페이스의 일반 규약 이외의 특별한 기능을 제공하며, 주변 코드가 이 기능에 기대어 동작할 때
• 위의 예시에서 LinkedHashSet이 따르는 순서 정책을 가정하고 동작하는 상황에서 HashSet으로 바꾸면 문제가 될 수 있다.

구현타입을 바꾸는 동기

• 원래 것보다 성능이 좋거나, 신기능을 제공
• HashMap을 참조하던 변수를 EnumMap으로 바꾸면 속도가 빨라지고 순회 순서도 키의 순서와 같아짐 (단 열거 타입일 때만 사용 가능)
• LinkedHashMap을 사용하면, 키 타입도 상관 없으면서 성능은 비슷하게 유지하면서 순회 순서를 예측할 수 있다.

적합한 인터페이스가 없는 경우

• 적합한 인터페이스가 없다면 당연히 클래스로 참조해야 한다.

값 클래스인 경우

String, BigInteger 같은 값 클래스

• 값 클래스를 여러 가지로 구현될 수 있다고 생각하고 설계하는 일은 거의 없다
• 따라서 이런 값 클래스는 매개변수, 변수, 필드, 반환 타입으로 사용해도 무방하다.

클래스 기반으로 작성된 프레임워크가 제공하는 객체들

• 이런 경우라도 특정 구현 클래스보다는 기반 클래스를 사용해 참조하는 게 좋다.
  • 이 경우 기반 클래스는 보통 추상 클래스
  • ex) OutputStream 등 java.io 패키지의 여러 클래스들

인터페이스에는 없는 특별한 메서드를 제공하는 클래스들

• ex) PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다
• 클래스 타입을 직접 사용하는 경우는 이런 추가 메서드를 꼭 사용해야 하는 경우로 최소화해야 한다. (절대 남발하지 말아야 한다)

---

💡 팁

• 실전에서는 주어진 객체를 표현할 적절한 인터페이스가 있는지 찾아서 그 인터페이스로 참조하면 더 유연하고 세련된 프로그램을 만들 수 있다
• 적합한 인터페이스가 없다면 클래스의 계층구조 중 필요한 기능을 만족하는 가장 덜 구체적인(상위의) 클래스를 타입으로 사용하자