이펙티브 자바, 아이템 21, 22, 23

이펙티브 자바, 아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하는 것음 어렵다. 예를 들면 자바 8 Collection 인터페이스에 추가된 디폴트 메서드는 여러 서드파티 컬렉션 구현체에서 재정의 되지 않은 경우가 많기 때문에 동기화를 하지 못하는 등 여러 문제가 발생한다.
디폴트 메서드는 기존 구현체이 런타임 오류를 일으킬 수 있다. 디폴트 메서드를 추가하면 기존 구현체에 영향을 줄 수 있다.
기존 인터페이스에 새로운 디폴트 메서드를 추가하는 일은 꼭 필요한 경우가 아니라면 피해야한다.
핵심은 디폴트 메서드라는 도구가 있지만 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야 한다는 것.
새로운 인터페이스라면 릴리스 전에 반드시 테스트를 거쳐야 한다.

이펙티브 자바, 아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라

인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입의 역할만을 해야한다.

상수 인터페이스 안티패턴은 인터페이스를 잘못 사용한 예다.
상수 인터페이스 : 메서드 없이 상수 필드로만 가득 찬 인터페이스
상수 인터페이스를 구현하는 클래스는 상수, 즉 내부 구현을 API로 노출하게 된다. 클래스를 사용하는 클라이언트로 하여금 혼란을 주기도 하며 때로는 클라이언트가 이 상수에 의존하게 될 수도 있다.
상수 인터페이스 대신 상수와 강하게 연관된 클래스나 인터페이스 자체에 추가해야 한다. (대표적으로 Integer, Double의 MIN_VALUE, MAX_VALUE)
또는 열거 타입을 사용하여 공개하거나 인스턴스화 할 수 없는 유틸리티 클래스에 담아서 공개한다.
유틸리티 클래스로 상수를 공개할때는 static import로 클래스 이름을 생략하여 사용할 수 있다.

이펙티브 자바, 아이템 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

태그 달린 클래스는 장황하고 오류를 내기 쉽고 비효율적이며 클래스 계층구조를 어설프게 흉내낸 아류일 뿐이다.
태그 달린 클래스를 써야 하는 상황은 거의 없다.
새로운 클래스를 작성하는 중에 태그 필드가 등장한다면 태그 필드를 없애고 계층구조로 대처하는 방법을 생각해보아야 한다.
기존 클래스가 태그 필드를 사용하고 있다면 계층구조로 리팩터링하는 걸 고민해보아야 한다.