[Effective-Java] Chapter9 #64. 객체는 인터페이스를 사용해 참조하라

[Effective-Java] Chapter8 #51. 메서드 시그니처를 신중히 설계하라

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

 

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

// 나쁜 예
LinkedHashSet<Son> sonSet = new LinkedHashSet<>();

• 객체의 실제 클래스를 사용할 상황은 '오직' 생성자로 생성할 때 뿐이다.
• 인터페이스를 타입으로 사용하는 습관을 기르면 프로그램이 훨씬 유연해진다.
• 나중에 구현 클래스를 LinkedHashMap에서 HashSet으로 바꾸어도 주변 코드는 이러한 변화에 영향을 받지 않는다.

 

📌 주의할 점

• LinkedHashSet이 따르는 순서 정책을 가정하고 동작하는 상황에서 순회 순서를 보장하지 않는 HashSet으로 바꾸면 문제가 될 수 있다.
• 기존에 사용하던 구체 클래스가 인터페이스 일반 규약 이외 특별한 기능을 제공하며, 주변 코드가 해당 기능에 기대어 동작한다면 대체한 구체 클래스도 반드시 같은 기능을 제공해야 한다. (아니면 로직 자체를 갈아 엎든지..)

 

'선언 타입과 구현 타입을 동시에 바꾸면 괜찮지 않나?'라고 생각할 수 있지만, 컴파일 자체가 되지 않을 수 있다.

인터페이스 타입으로 선언을 하면 구현 클래스에 상관없이 공통으로 정의된 메서드를 쓰고 있었을 테지만,

구현 클래스를 사용하는 시점에선 그렇다고 보장할 수 없기 때문이다.

 

📌 적합한 인터페이스가 없다면 당연히 클래스로 참조하라.

💡 클래스 계층 구조 중 필요 기능을 만족하는 가장 상위의(덜 구체적인) 클래스를 타입으로 사용하라

1️⃣ 값 클래스

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

 

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

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

 

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

• PriorityQuere 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다.
• 클래스 타입을 직접 사용하는 경우는 이런 추가 메서드를 꼭 사용해야 하는 경우를 최소화 하라 (유연성 저하)