(이펙티브 자바) 규칙64. 객체는 인터페이스를 사용해 참조하라

(Effective Java) 규칙64. 객체는 인터페이스를 사용해 참조하라

• 규칙51에서 매개변수 타입을 클래스가 아니라 인터페이스를 사용하라고 했다.

  • 조언을 "객체는 클래스가 아닌 인터페이스로 참조하라"고까지 확장할 수 있음

---

인터페이스 타입

---

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

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

• 예) Set 인터페이스를 구현한 LinkedHashSet 변수를 선언

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

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

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

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

 

인터페이스 규약

---

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

  • 주변 코드가 LinkedHashSet이 따르는 순서 정책을 가정하고 동작하는 상황에서 HashSet으로 바꾸면 문제가 될 수 있음
  • HashSet은 반복자의 순회 순서를 보장하지 않기 때문

• 구현 타입을 바꾸려 하는 동기는 원래 것보다 성능이 좋거나 멋진 신기능을 제공하기 때문일 수 있다.

  • 예) HashSet을 참조하던 변수를 EnumMap으로 바꿨을 떄 이점이 많아지는 경우

• 선언 타입과 구현 타입을 동시에 바꿀 수 있으니 변수를 구현 타입으로 선언해도 괜찮을 것이라 생각할 수도 있지만 자칫하면 프로그램이 컴파일되지 않는다.

  • 클라이언트에서 기존 타입에서만 제공하는 메서드를 사용했거나, 기존 타입을 사용해야 하는 다른 메서드에 인스턴스를 넘겼을 때 생길 수 있는 문제
  • 인터페이스로 선을 했다면 컴파일이 되지 않기 때문에 사전에 방지가 가능함

 

적합한 인터페이스가 없을 때

---

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

1. String과 BigInteger 같은 값 클래스

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

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

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

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

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

 

결론

---

• 실전에서는 주어진 객체를 표현할 적절한 인터페이스가 있는지 찾아서 그 인터페이스로 참조하면 더 유연하고 세련된 프로그램을 만들 수 있다.

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

   

---

끝으로

이 글이 도움이 되었다면, 하단의 Google 광고 👎👎👎 한번씩 클릭 부탁 드립니다. 🙏🙏🙏

광고 클릭은 많은 힘이 됩니다!