Item21. 인터페이스는 구현하는 쪽을 생각해 설계하라! 자바 8 전에는 기존 구현체를 깨뜨리지 않고는 인터페이스에 메서드를 추가할 방법이 없었다. 기존 인터페이스에 메서드 추가하는 경우, 그 메서드가 이미 존재할 가능성은 미비하니 보통 컴파일 에러가 난다. 자바 8에 와서 기존 인터페이스에 메서드를 추가할 수 있도록 디폴트 메서드가 추...

Item20. 추상 클래스보다는 인터페이스를 우선하라! 자바가 제공하는 다중 구현 메커니즘 -> 인터페이스, 추상 클래스 자바 8부터 인터페이스도 디폴트 메서드 제공이 가능해져 두 메커니즘 모두 인스턴스 메서드를 구현 형태로 제공 가능 추상 클래스 정의한 타입 구현을 위해 하위 클래...

Item19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라! 상속을 고려한 문서화 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다. 호출되는 메서드가 재정의 가능 메서드일 경우, 그 사실을 API 설명에 적시한다. 어떤 순서로 호출하는지 적시한다. ...

Item18. 상속보다는 컴포지션을 사용하라! 상속은 코드를 재사용하는 강력한 수단이나, 항상 최선은 아니다. 상속을 상위, 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서 사용하거나, 확장할 목적으로 설계되었고 문서화도 잘 된 클래스에서 사용한다면 안전한 방법이다. 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 상위...

Item17. 변경 가능성을 최소화하라! 불변 클래스. Immutable class 인스턴스 내부 값을 수정할 수 없는 클래스 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 변경되지 않는다. 불변 클래스는 가변 클래스보다 설계, 구현, 사용이 쉽고, 오류가 생길 여지가 적어 안전하다. 불변 클래스 생성 규칙 ...

Item16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라! 문제점 class Point { public double x; public double y; } 위와 같은 클래스는 데이터 필드에 직접 접근이 가능하다. 캡슐화의 이점을 제공하지 못한다. API 수정 없이...

Item15. 클래스와 멤버의 접근 권한을 최소화하라! 컴포넌트의 설계는 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는지로 평가한다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 정보 은닉, 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. 정보...