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

적합한 인터페이스만 있다면 매개변수 뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라. 객체의 실제 클래스를 사용해야 할 상황은 '오직' 생성자로 생성할 때뿐이다.

 

좋은 예, 인터페이스를 타입으로 사용했다.

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

 

나쁜 예, 클래스를 타입을 사용했다.!!!

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

 

인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질 것이다. 나중에 구현 클래스를 교체하고자 한다면 그저 새 클래스의 생성자를 호출해주기만 하면 된다.

 

예컨데, LinkedHashSet은 다음처럼 바뀐다.

Set<Son> sonSet = new HashSet<>();

 

주의사항

 

 원래의 클래스가 인터페이스의 일반 규약 이외의 특별한 기능을 제공하며, 이 기능에 기대어 주변 코드들이 영향을 받는다면 클래스도 반드시 같은 기능을 제공해야 한다.

 

 LinkedHashSet과 달리 HashSet으로 바꾸면 반복자의 순회 순서를 보장하지 않기 때문에 문제가 될 수 있다.

 HashMap을 참조하던 변수가 EnumMap으로 바뀌면 속도가 빨라지고 순회 순서도 키의 순서와 같아진다. 하지만, EnumMap은 키가 열거 타입일 떄만 사용이 가능하다. 한편, LinkedHashMap은 성능은 비슷하게 유지하면서 순회 순서를 예측도 할 수 있다.

 

적합한 인터페이스가 없다면 클래스로 참조해야 하는 경우는 다음 3가지이다.

 

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

 

2. 클래스 기반으로 작성된 프레임워크가 제공하는 객체이다. OutStream 등 java.io 패키지의 여러 클래스가 속한다.

 

3. 인터페이스에는 없는 특별한 메서드를 제공하는 클래스들이다. 예를 들어, PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다. 꼭 comparator를 사용해야 하는 경우에만 클래스로 참조하도록 하며, 이외에는 인터페이스를 참조하도록 하는 것이 좋다.

 

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

 

* 느낀점

처음에 반환값, 변수, 필드 전부 인터페이스화 시키라는 것이 놀라웠다. 아무래도 최대한 유연한 구조를 설계함으로써, 변경이 필요할 때 최소한의 수정으로 요구사항을 만족하기 위해서라고 생각한다. 알고리즘 문제를 풀면서 항상 이 규칙에 맞추어서 잘 정의했다. 무작정 인터페이스로 만들기 보다는 상황에 맞춰 좀 더 세세한 부분까지도 어떻게 적용할 수 있을지 확인해야겠다.