[Effective Java] 4장 클래스와 인터페이스 (1부)

정리

아이템 15. 프로그램 요소의 접근성은 가능한 최소한으로 해라. 꼭 필요한 것만 골라 최소한의 public API를 설계하자. 그 외에 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개 되는 일이 없도록 해야한다. Public 클래스는 public static final 필드외에 어떠한 public 필드를 가져서는 안되며 참조하는 객체도 불변인지 확인해야한다.

아이템 16. public 클래스는 절대 가변 팔두룰 직접 노출해서는 안된다. 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다. 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 필드를 노출하는 편이 나을 때도 있다.

아이템 17. 불변이 되는 영역의 비율이 높아지면 스레드간 동기화가 필요 없고, 문제 없이 공유가 가능하다. 불변 클래스를 만들 때 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법이 제일 좋은 방법이다. 불변 객체는 생성자와 정적 팩터리 외에는 객체를 재활용할 목적인 메서드도 public으로 제공하면 안된다. 하지만 불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 점을 염두해두자.

아이템 18. 상속은 강력하지만 캡슐화를 해친다는 문제가 있다. 상속은 상위 클래스와 하위 클래스가 is-a 관계 일 때만 써야한다. Is-a 관계에도 하위 클래스의 패키지가 상위 클래스와 다르고, 상위 클래스가 확장을 고려해 설계되지 않았다면 여전히 문제가 될 수 있다. 상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자. 특히 래퍼 클래스로 구현할 적당한 인터페이스가 있다면 더욱 그렇다. 래퍼 클래스는 하위 클래스보다 견고하고 강력하다.

아이템 19. 상속용 클래스를 설계하기란 결코 만만치 않다. 클래스내부에서 스스로 어떻게 사용하는지(자기 사용 패턴) 모두 문서로 남겨야 하며, 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다. 그렇지 않으면 그 내부 구현 방식을 믿고 활용하던 하위 클래스를 오동작하게 만들 수 있다. 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다. 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 나을 것이다. 상속을 금지하려면 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다.

---

내용

아이템 15. 클래스와 멤버의 접근 권한을 최소화하라

● 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이개념은 소프트웨어 설계의 근간이 되는 원리다.

● 정보 은닉의 장점

- 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. - 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수  있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다. - 정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음(아이템 67. 최적화는 신중히 하라),  다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있기 때문이다. - 소프트웨어 재사용성을 높인다. 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문이다. - 큰 시스템을 제작하는 난이도를 낮춰준다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.

● 자바에서 정보 은닉을 위해 다양한 장치를 제공하는데, 그중 접근 제어 매커니즘은 클래스, 인터페이스, 멤버의 접근성(private, protected, public)을 명시한다.

● 정보은닉의 기본 원칙은 모든 클래스와 멤버의 접근성을 가능한 좁혀야 한다. top 레벨(가장 바깥이라는 의미) 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private와 public 두 가지다. top 레벨 클래스와 인터페이스를 public으로 선언할 경우 공개 API가 되고 package-private 으로 선언할 경우 패키지 안에서만 사용이 가능하다. 외부에서 사용할 필요가 없다면 package-private으로 선언하자. public 으로 선언할 경우 하위 호환을 위해 영원히 관리를 해야한다.

● public 클래스에서 package-private 에서 protected로 바꾸는 순간 접근할 수 있는 대상이 엄청나게 넓어진다. 그래서 public 과 마찬가지로 영원히 관리되어야한다.

● 상위 클래스의 매서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정 할 수 없다.

● public 클래스의 private 멤버를 package-private까지 허용할 순 있다.

● public 클래스의 인스턴 필드는 되도록 public이 아니어야 한다. 불변식을 보장할 수 없기때문이다. 필드가 수정 될 때(락 획득 같은) 다른 작업을 할 수 없게 되므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다. 

● 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다.

● 예외는 있다. 해당 클래스가 표현하는 추상 개념을 완성하는데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 좋다. 관례상 이런 상수의 이름은 대문자 알파벳으로 쓰며, 각 단어 사이에 언더바(_)을 넣는다.

● 다음 코드에는 보안 허점이 숨어 있다. public static final Thing[] VALUES = {...}; 어떤 IDE가 생성하는 접근자는 private 배열 필드의 참조를 반환하여 문제를 이르킨다. 다음을 막기 위한 2가지의 방법이 있다.

1. 앞 코드의 public 배열을 private으로 만들고 public 불변 리스트를 추가하는 것이다. 2. 배열을 private로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법이다. (방어적 복사)

아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

● 인스턴스 필드를 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려할 때가 있다. (예, class Point{ public double x; } ) 이런 경우 캡슐화의 이점을 제공하지 못한다. Public 클래스인 경우 접근자를 제공하여 해결 할 수 있다.

● package-private 클래스, private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다. 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.

● public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 줄어들지만 좋은 생각은 아니다.

아이템 17. 변경 가능성을 최소화하라

● 불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스이다. 클래스를 불변으로 만들려면 5가지의 규칙을 따르면 된다.

1. 객체의 상태를 변경하는 메서드를 제공하지 않는다. 2. 클래스를 확장할 수 없도록 한다. 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 것을 방지한다. 3. 모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 이용한다. 4. 모든 필드를 private로 선언한다. 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근하는 것을 막는다. 5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

● 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라고 한다. (이와 달리 절저적 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.)

● 함수형 프로그래밍 방식은 불변이 되는 영역의 비율이 높아지는 장점이 있다. (생성된 시점의 상태가 파괴될 때까지 그대로 간직)

● 불변 객체는 다음과 같은 장점을 갖고 있다.

1. 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다 2. 불변 객체는 안심하고 공유할 수 있다. 3. 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다. 4. 불변 객체는 그 자체로 실패 원자성을 제공한다. (내부 상태를 바꾸지 않기 때문)

객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.

하지만 불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다.

● 불변 클래스를 만드는 방법 또는 다른 설계 방법

1. 자기 자신을 상속하지 못하게 하는 가장 쉬운 방법은 final 클래스로 선언한다. 2. 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법이다.

정적 팩터리를 이용할 경우, 객체 캐싱 기능을 추가해성능을 끌어올릴 수도 있다.

만약 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 인수들은 가변이라고 가정하고 방어적으로 복사를 해야한다.

● getter가 있다고 무조건 setter를 만들지 말자. 클래스는 꼭 필요한 경우가 아니라면 불변이어야한다. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이면 좋다. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.

● 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다. 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 객체를 재활용할 목적인 메서드도 public으로 제공해서는 안된다. 복잡성만 커질 뿐이다.

아이템 18. 상속보다는 컴포지션을 사용하라

● 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서 사용이나 확장한 목적으로 설계되었고 문서화도 잘 된 클래스 안전한 방법이다. 하지만, 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.

● 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 상위 클래스는 릴리즈마다 달라질 가능성이 있기 때문에 하위 클래스에서 오작동이 생길 수 있다.

● 상위 클래스에 새 메서드가 추가 됐는데, 기존에 하위 클래스에 추가한 메서드가 존재하는 경우 컴파일이 되지 않거나 보안이슈가 생긴다.

● 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 한다면 기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 뜻에서 이러한 설계를 컴포지션(composition; 구성)이라 한다.

● 컴포지션 설계에서 새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환한다. 이 방식을 전달(forwarding)이라 하며, 새클래스의 메서드들은 전달 메서드(forwarding method)라 한다. 기존 클래스의 내부 구현 방식의 영향에서 벗어나고, 새로 추가된 메소드가 있어도 전혀 영향을 받지 않는다.

● 임의의 기존 클래스에 새로운 기능을 덧씌워 새로운 클래스를 만드는 패턴이 데코레이션 패턴(Decorator pattern)이라 한다. 이때 새로운 클래스는 레퍼 클래스라고 한다. 다른 기존 클래스의 인스턴스를 감싸고 있다는 뜻에서 지어졌다.

● 래퍼 클래스는 콜백(callback) 프레임워크와 어울리지 않다는 점만 주의해라. 이유는 콜백 프레임워크에서 자신의 참조를 다른 객체에 넘겨 다음 호출(콜백) 때 사용하도록 한다. 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르니 대신 자신(this)의 참조를 넘기고, 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 된다. 이런 문제를 SELF 문제라고 한다.

● 재사용이 가능한 전달 클래스를 인터페이스당 하나씩 만들어두면 원하는 기능을 덧씌우는 전달 클래스들을 쉽게 구현할 수 있다.

● 상속은 상위, 하위 클래스가 is-a 관계일 때만 상속해야한다. 또 확장하려는 클래스의 API에 아무런 결함이 없는지와 하위 클래스에게 결함이 전파돼도 괜찮은지를 파악하고 상속을 해야한다.

아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

● 아이템 18에서는 상속을 염두에 두지 않고 설계했고, 상속할 때의 주의점도 문서화해놓지 않은 '외부'클래스를 상속할 때의 위험을 경고했다. 여기서 '외부'란 프로그래머의 통제권 밖에 있어서 언제 어떻게  변경될지 모른다는 뜻이다.

● 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야한다.

클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 호출되는 메서드가 재정의 가능 메서드라면 그 사실을 호출하는 메서드의 API설명에 적시해야 한다. 어떤 순서로 호출하는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 한다. 재정의 가능 메서드를 호출할 수 있는 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야한다.

● API 문서 작성 예시이다. API 문서의 메서들 설명 끝에 종종 "Implementation Requirements"로 시작하는 절을 볼 수 있는데, 그 메서드의 내부 동작 방식을 설명하는 곳이다. 이 절은 @implSpec 태그를 붙여주면 자바독 도구가 생성해준다.

Java.util.AbstractCollection에서 발췌한 예시이다. public boolean remove(Object o) 주어진 원소가 이 컬렉션 안에 있다면 그 인스턴스를 하나 제거한다. 이 컬렉션 안에 'Object.equals(o, e)가 참인 원소' e가 하나 이상 있다면 그 중 하나를 제거한다. 주어진 원소가 컬렉션 안에 있었다면(호출 결과 이 컬렉션이 변경 됐다면) true를 반환한다. Implementation Requriements : 이 메서드는 컬렉션을 순회하며 주어진 원소를 찾도록 구현되었다. 주어진 원소를 찾으면서 반복자의 remove 메서드를 사용해 컬렉션에서 제거한다. 이 켈렉션이 주어진 객체를 갖고 있으나, 이 컬렉션의 iterator 메서드가 반환한 반복자가 remove 메서드를 구현하지 않았다면 UnsupportedOperationException을 던지니 주의하자.

이 설명에 따르면 iterator 메서드를 재정의하면 remove 메서드의 동작에 영향을 줌을 확실히 알 수 있다. Iterator 메서드로 얻은 반복자의 동작이 remove 메서드의 동작에 주는 영향도 정확히 설명했다.

● 효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태로 공개해야 할 수 있다. 드물게는 protected 필드로 공개해야할 수도 있다.

● 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 '유일'하다. 상속용 클래스의 공개된 API들은 성능과 기능에 영원히 책임져야 하기 때문에 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.

● 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다. 이유는 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이 때 그 재정의한 메서드가 하위 클래스의 생성자에 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이 때문이다.

● clone과 readObject 메서드는 생성자와 비슷한 효과를 내는데, clone과 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다. 이유는readObject의 경우 하위 클래스의 상태가 역직렬화되기 전에 재정의한 메서드부터 호출하게 된다. clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 수정하기 전에 재정의한 메서드를 호출하기 때문이다.

● Serializable을 구현한 상속용 클래스가 readResolve나 writeReplace 메서드를 갖는다면 이 메서들은 private이 아닌 protected로 선언해야 한다.

● 일반적인 구체 클래스를 상속할 경우 해당 클래스가 변화할 때마다 하위 클래스를 오작동하게 만들 수 있기 때문이다. 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이 좋다. 상속을 꼭 허용해야하는 경우 클래스 내부에서는 재정의 가능 메서드를 사용하지 않게 만들고 이 사실을 문서로 남기는 것이다. 재정의 가능 메서드를 호출하는 자기 사용 코드를 완벽히 제거해야한다.

● 상속을 금지하는 방법은 두가지이다.

1. 둘 중 더 쉬운 쪽은 클래스를 final로 선언하는 방법이다. 2. 모든 생성자를 private이나 package-private 으로 선언하고 public 정적 팩터리를 만들어주는 방법이다.

●  클래스의 동작을 유지하면서 재정의 가능 메서드를 상용하는 코드를 제거할 수 있는 방법은 먼저 각각의 재정의 가능 메서드를 호출하도록 수정한다. 그런 다음 재정의 가능 메서드를 호출하는 다른 코드들도 모두 이 도우미 메서드를 직접 호출하도록 수정하면 된다.

---

용어정리

● 실패 원자성 : 메서드에서 예외가 발생한 후에도 그 객체는 여전히 유효한 상태여야한다는 설정.

---

4장 클래스와 인터페이스 1부는 클래스의 접근 권한내용과 상속에 대해 소개하고 있다. public 이나 protected 인 경우 API가 공개 되어 계속 관리를 해야한다. 공개할 의도가 없으면 default나 private로 정의하는 것이 좋다. 상속을 할때 철저히 설계를 하고 문서화를 해야한다.