Book

[Effective Java] item 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 클래스를 안전하게 상속할 수 있도록 하려면 (상속만 아니었다면 기술하지 않았어야 할) 내부 구현 방식을 설명해야만 한다. [상속을 고려한 설계와 문서화] : 메서드를 정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다. → 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야 한다. 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출하는데, 그 메서드가 재정의 가능 메서드인 경우 어떤 순서로 API를 호출해야 하는지 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지 넓게 말하면, 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다. ☑️..

[Effective Java] item 18. 상속보다는 컴포지션을 사용하라 *

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 다른 패키지의 구체 클래스를 상속하는 일은 위험하다. [메서드 호출과 달리 상속은 캡슐화를 깨뜨린다] : 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스가 오동작할 수 있다. ☑️ HashSet를 상속받은 클래스 InstrumentedHashSet public class InstrumentedHashSet extends HashSet { // 추가된 원소의 수 private int addCount = 0; @Override public boolean addAll(Collection

[Effective Java] item 17. 변경 가능성을 최소화하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다. ☑️ 불변 클래스 생성 규칙 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. 클래스를 확장할 수 없도록 한다. 상속을 막는 대표적인 방법 ↔ 클래스를 final로 선언하기 모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법 모든 필드를 private로 선언한다. 필드가 참조하는 가변 객체를 ..

[Effective Java] item 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 이따금 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다. 이처럼 퇴보한 클래스는 public이어서는 안 된다! [패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공해야 한다] : public 클래스에서는 필드를 모두 private으로 바꾸고 public 접근자(getter)를 추가해야 한다. ☑️ 접근자와 변경자 메서드를 활용해 데이터 캡슐화하기 class Point{ public double x; public double y; } 이런 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다. API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불..

[Effective Java] item 15. 클래스와 멤버의 접근 권한을 최소화하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. [모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다] : 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다. ☑️ 톱레벨 클래스, 인터페이스에 부여할 수 있는 접근 수준 public..