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

[JoisFe]

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

어디서 많이 본 주제인데?

• 아이템 51 : 메서드 시그니처를 신중히 설계하라 #131 에서 매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라 와 비슷한 느낌이 난다.
• 위 내용을 확장하여 객체는 클래스가 아닌 인터페이스로 참조하라로 확장 가능

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

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

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

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

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

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

주의할 점

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

Ex)

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

구현 타입을 바꾸려 하는 동기?

• 원래 것보다 성능이 좋거나 멋진 신기능을 제공하기 때문일 수 있음
• HashMap을 참조하는 변수가 있을때 이를 EnumMap으로 바꾸면 속도가 빨라지고 순회 순서도 키의 순서와 같아짐
• 단 EnumMap은 키가 열거 타입일 경우만 사용할 수 있음
• 한편 키 타입과 상관없이 사용할 수 있는 LinkedHashMap 으로 바꾸면 성능은 비슷하게 유지하면서 순회 순서를 예측할 수 있게 됨

오해

• 선언 타입과 구현 타입을 동시에 바꿀 수 있으니 변수를 구현 타입으로 선언해도 괜찮다는 오해가 생길 수 있음
• 하지만 자칫하면 프로그램이 컴파일 되지 않음
• 클라이언트에서 기존 타입에서만 제공하는 메서드를 사용했거나 기존 타입을 사용해야 하는 다른 메서드에 그 인스턴스를 넘겼다고 가정하면 새로운 코드에서는 컴파일 되지 않을 것
• 변수를 인터페이스 타입으로 선언한다면 이러한 일이 발생하지 않음

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

1. String, BigInteger가 대표적인 예

• 값 클래스가 여러 가지로 구현될 수 있다고 생각하고 설계하는 일은 거의 없음
• 따라서 final인 경우가 많고 상응하는 인터페이스가 별도로 존재하는 경우가 매우 드뭄
• 이러한 값 클래스 경우 매개변수, 변수, 필드, 반환 타입으로 사용해도 좋음

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

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

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

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

참고 (PriorityQueue)

• PriorityQueue 경우 Queue와 달리 우선순위에 따라 정렬하는 자료구조
• 따라서 정렬을 어떤 기준으로 할지 Comparator 인터페이스를 구현하고 있음

PriorityQueue<Integer> pq = new PriorityQueue<>((o1, o2) -> o2 - o1);

• 위 예시처럼 Comparator를 직접 구현할 수 있음 (내림차순)

클래스 타입을 직접 사용하는 경우는 이러한 추가 메서드를 꼭 사용해야 하는 위 3가지 정도의 경우로 최소화 해야함

• 딱 위 3가지만 존재하는 것은 아님 (대표적인 예 일 뿐)

정리

1. 실전에서는 주어진 객체를 표현할 적절한 인터페이스가 있는지 찾고 그 인터페이스로 참조하면 더 유연하고 세련된 프로그램을 만들 수 있음
2. 적합한 인터페이스가 없다면 클래스의 계층구조 중 필요한 기능을 만족하는 가장 덜 구체적인 (상위의) 클래스를 타입으로 사용하는 것이 좋음

[corock]

저는 지인들에게 객체지향 프로그래밍을 정복하고 싶다면 4 + 5 = 9 를 통달하면 된다고 전파합니다.
여기서 4는 4대 특징(concepts)을 말하고, 5는 원칙(principles)인데요.

이번 아이템을 읽으면서 그중에서도 4대 특징 중 가장 하이라이트라고 볼 수 있는 다형성의 중요성을 다시 한번 상기해보는 시간이었습니다.
정리하신 글 잘 읽었습니다~

[Irisation23]

3요소 5원칙으로 알았는데 4대 특징이였군요..

[corock]

3요소 5원칙으로 알았는데 4대 특징이였군요..

3요소는 어떤 건가요~?

[JoisFe]

4대 특징으로는 다형성, 추상화, 캡슐화, 상속 으로 알 고 있습니다.

[JoisFe]

3요소 경우 다형성, 캡슐화, 상속으로 보군요