[이펙티브 자바] 객체는 인터페이스를 사용해 참조하라 ─ 9장:일반적인 프로그래밍 원칙:Item64

클래스를 타입으로 사용하지 마라

 

매개변수 타입을 지정할 때, 클래스가 아닌 인터페이스를 사용하라고 했다. (Item51)

이 조언을 확장한다면 "객체는 클래스가 아닌 인터페이스로 참조하라"는 의미이다.

유연한 프로그래밍을 위하여..

 

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

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

클래스를 타입으로 사용하지 말아라!

 

// O
Set<Son> sonSet = new LinkedHashSet<>();

// X
LinkedHashSet<Son> sonSet = new LinkedHashSet<>();

 

 

 

---

주의점

 

구현 클래스를 갈아끼우는 상황을 떠올려보자.

 

기존의 클래스가 인터페이스의 일반 규약 이외의 특별한 기능을 제공하는 상태고, 주변 코드가 이 기능에 기대어 동장한다면, 새로운 클래스도 반드시 같은 기능을 제공해야 한다.

 

예를 들어, LinkedHashSet가 따르는 순서 정책을 가정하고 주변 코드들이 동작하고 있다고 해보자. 이때 HashSet으로 바꾸면, 반복자의 순회 순서를 보장하지 않아 문제가 될 수 있다.

 

 

 

---

마땅한 인터페이스가 없는 경우는요?

 

당연히 클래스로 참조해야 한다. 

 

(케이스1)

특히 값 클래스들이 그러하다. String, BigInteger 등.. 값 클래스를 여러 가지로 구현될 수 있다고 생각하고 설계하는 일은 거의 없다. 따라서 final인 경우가 많고, 상응하는 인터페이스가 별도 존재하는 경우가 드물다. 자연스럽게 이런 값 클래스들은 매개변수, 변수, 필드, 반환타입으로 사용한다.

 

(케이스2)

클래스 기반으로 작성된 프레임워크가 제공하는 객체들도 그렇다. 이런 경우라도 특정 구현 클래스보다는 기반 클래스를 사용해 참조하는 것이 좋다 (보통은 추상 클래스)

예를 들어, OutputSteam 등 java.io 패키지의 여러 클래스가 이 부류에 속한다.

 

(케이스3)

인터페이스에는 없는 특별한 메서드를 제공하는 클래스들 또한 적합한 인터페이스를 선택하지 못할 것이다. 예를 들어 PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다. 클래스 타입을 직접 사용하고 싶으면, 이런 추가 메서드를 "꼭" 사용해야 하는 경우로 최소화하길 바라며, 절대 남발하지 말아야 한다.

 

 

적합한 인터페이스가 없다면, 클래스의 계층구조 둥 필요한 기능을 만족하는 가장 덜 구체적인, 상위의 클래스를 타입으로 사용하자.

 

 

---