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

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

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

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

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

이처럼 인터페이스를 사용하는 습관을 길러두면 프로그램이 유연해진다.

같은 인터페이스라고 구현체를 마음대로 변경해서는 안 된다.

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

위의 경우에 LinkedHashSet은 순서를 보장하지만 HashSet은 순서를 보장하지 않는다.
따라서 LinkedHashSet에서 HashSet으로 변경한다면 문제가 발생할 수 있다.

즉, 같은 인터페이스라도 구현체마다 약간씩 제공하는 기능이 다르다. 해당 사항도 파악하고 구현체를 변경해야 한다.

구현 타입 변경은 기존에 제공하는 모든 기능을 제공하면서, 성능/신기능 제공을 할 때 변경한다.

HashMap을 참조하던 변수가 있을 때, 이를 EnumMap으로 변경하면 속도가 빨라지고 순회 순서도 키의 순서와 같아진다.
하지만, EnumMap은 키가 열거 타입일 때만 사용할 수 있다.
반면, 키의 타입과 상관없이 사용할 수 있는 LinkedHashMap을 사용한다면 성능은 유지하면서 순회 속도를 예측할 수 있다.

적절한 인터페이스가 없다면 클래스로 참조하자.

String, BigInteger 같은 값 클래스는 여러 개로 구현될 수 있다고 생각하고 설계하는 일은 없다.
이 같은 경우엔 final이고 상응하는 인터페이스가 존재하지 않는 경우가 많다.

적합한 인터페이스가 없는 경우 특정 구현 클래스보다는 추상 클래스를 참조하는 게 좋다.

즉, 특정 클래스보다는 기반 클래스를 사용하자

인터페이스에는 없는 특별한 메서드를 제공하는 구현 클래스인 경우 해당 클래스를 사용하자.

PriorityQueue 클래스는 Queue 인터페이스에는 없는 메서드를 제공한다.
이렇게 구현 클래스 타입을 직접 사용하는 경우는 추가 메서드를 꼭 사용해야 하는 경우로 최소화해야 한다.

주어진 객체를 표현할 적절한 인터페이스가 있는지 찾는다>
=> 있다면 해당 인터페이스를 사용한다.
=> 없다면 클래스의 계층 구조중 필요한 기능을 만족하는 덜 구체적인(상위 클래스) 타입을 사용하자

0개의 댓글

Powered by GraphCDN, the GraphQL CDN