• 아이템 51 메서드 시그니처를 신중히 설계하라 에서 매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라 는 내용이 있다.
• 예를 들어 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을사용하자. 그러면 어떤 Map 구현체도 인수로 건넬 수 있다. (TreeMap, ConcurrentHashMap)
• 인터페이스 대신에클래스를사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 꼴이며 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 한다.
• 이 내용을 객체는 클래스가 아닌 인터페이스로 참조하라 고까지 확장할 수 있다.

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

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

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

//좋은 예
Set<Son> sonSet = new TreeSet<>();

//나쁜 예
LinkedHashSet<Son> sonSet = new TreeSet<>(); //컴파일 에러!

• 위의 좋은 예는 Set 인터페이스 타입이기 때문에 컴파일 타임/런타임에 전혀 문제가 되지 않는다.
• 나쁜 예는 LinkedHashSet 타입이기 때문에 TreeSet을 LinkedHashSet로 형변환 할 수 없다고 에러가 발생한다.

나중에 구현 클래스를 교체하고자 한다면 그저 새 클래스의 생성자(혹은 다른 정적 팩터리)를 호출해주기만 하면 된다.

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

• 다른 코드는 전혀 손대지 않고 새로 구현한 클래스로의 교체가 완료됐다.
• 주변 코드는 옛 클래스의 존재를 애초부터 몰랐으니 이러한 변화에 아무런 영향도 받지 않는다.

• 인터페이스 타입을 사용하면 클라이언트 코드를 수정하지 않고도 참조 객체를 변경할 수 있다.
• 다른 타입의 객체를 사용하더라도 컴파일에러/런타임에러에 대한 걱정을 하지 않아도 된다.

• 인터페이스 타입에 선언된 메서드를 구현한 메서드만 사용이 가능하다.
• 특정 구현체의 내부 메서드를 사용할 수 없다.

• 원래의 클래스가 인터페이스의 일반 규약 이외의 특별한 기능을 제공하며 주변 코드가 이기능에 기대어 동작한다면 새로운 클래스도 반드시 같은 기능을 제공해야 한다.
• 선언 타입과 구현 타입을 동시에 바꿀 수 없으니 변수를 구현 타입으로 선언해도 괜찮을 거라 생각할 수도 있다. 하지만 컴파일되지 않는다.

클라이언트에서 기존 타입에서만 제공하는 메서드를 사용했거나 기존 타입을 사용해야 하는 다른 메서드에 그 인스턴스를 넘겼다고 할 경우 새로운 코드에서 컴파일되지 않을 것이다.

1. String, Integer, Long과 같이 값 타입에 대해서는 인터페이스를 사용할 수 없으니 클래스를 참조해야 한다.

   • Integer, Long과 같은 타입을 사용할 때는 Number와 같은 상위 타입을 사용하지 말아야 한다.
   • 형변환이 발생 할 때 특정 데이터가 절삭되어 다른 결과가 발생 할 수 있기 때문이다.
   • 이런 경우에는 인터페이스나 상위 타입 보다는 본래의 클래스로 참조하는 것이 좋다.

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

   • 특정 구현 클래스 보다는 (보통은 추상 클래스인) 기반 클래스를 사용해 참조하는 게 좋다.

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

   • PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다.