<div id="readability-page-1" class="page"><div id="dkContent" role="main">

					

					
						<h2>네로개발일기</h2>
					

					
						


						
							
							

							<div> <h3 data-ke-size="size23"># 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라.</h3>

<h4 data-ke-size="size20">## 1. 상속을 고려한 설계와 문서화</h4>
- 메서드를 재정의하려면 어떤 일이 일어나는지 정확히 정리하여 문서로 남겨야 한다. 즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 (자기사용) 문서로 남겨야 한다.
- 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 그런데 재정의가 가능한 메서드라면 그 사실을 API 명세에 적시해야 한다.

<h4 data-ke-size="size20">## 2. 좋은 API 문서란 어떻게가 아닌 무엇을 하는지를 설명해야 한다.</h4>
- 상속이 캡슐화를 해치기 때문에 안전하게 상속할 수 있도록 하려면 내부 구현 방식을 설명해야 한다. 그래서 특정 클래스의 메서드를 재정의하면 내부의 다른 메서드의 동작에 주는 영향도 정확하게 설명하고 있는 API들이 있다.

### @implSpec
- 자기사용 패턴(self-use pattern)에 대해서도 문서에 남겨 다른 프로그래머에게 그 메서드를 올바르게 재정의하는 방법을 알려야 한다.
- 일반적인 문서화 주석은 해당 메서드와 클라이언트 사이의 관계를 설명한다.
 - @implSpec 주석은 해당 메서드와 하위 클래스 사이의 관계를 설명하며, 하위 클래스들이 그 메서드를 상속하거나 super 키워드를 이용해 호출할 때 그 메서드가 어떻게 동작하는지를 명확히 인지하고 사용하게 해야 한다.
- tag "implSpec:a:Implementation Requirement" 스위치를 키지 않으면 @implSpec 태그를 무시한다.

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

<h4 data-ke-size="size20">## 3. 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출</h4>
- protected 메서드 하나하나가 내부 구현에 해당하므로 그 수는 가능한 적어야 한다. 다만, 너무 적게 노출해서 상속으로 얻는 이점을 없애지 않도록 주의해야 한다.
- 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다.
- 꼭 필요한 protected 멤버를 놓쳤다면 하위 클래스를 작성할 때 그 빈자리가 확연히 드러난다.
- 거꾸로 하위 클래스를 여러개 만들 때까지 전혀 쓰이지 않는 protected 멤버는 사실 private 였어야 할 가능성이 크다.

<h4 data-ke-size="size20">## 4. 상속용 클래스는 영원히 책임져야 한다.</h4>
- 널리 쓰일 클래스를 상속용으로 설계한다면 문서화한 내부 사용 패턴과 protected 메서드와 필드를 구현하면서 선택한 결정을 영원히 책임져야 한다.
- 이 결정들이 그 클래스의 성능과 기능에 영원한 족쇄가 될 수 있다.
- 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.

<h4 data-ke-size="size20">## 5. 상속용 클래스의 생성자는 재정의 메서드를 호출해서는 안된다.</h4>
- 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 기능 메서드를 호출해서는 안된다.
- 상위 클래스의 생성자는 하위클래스의 생성자 보다 먼저 실행되고, 하위클래스에서 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면, 의도대로 동작하지 않을 것이다.
- private, final, static 메서드는 재정의가 불가능하니 생성자에서 안심하고 호출해도 된다.

### clone과 readObject 메서드
- clone과 readObject 메서드는 생성자와 비슷한 효과를 낸다. (새로운 객체를 만든다.)
- 따라서, 상속용 클래스에서 Cloneable 이나 Serializable을 구현할지 정해야 한다면, 이들을 구현할 때 따라는 제약도 생성자와 비슷하다.
- 즉, clone과 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.
- readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의한 메서드부터 호출하게 된다.
- clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 수정하기 전에 재정의한 메서드를 호출한다.
- Serializable을 구현한 상속용 클래스가 readResolve나 withReplace 메서드를 갖는다면 이 메서드들은 private가 아닌 protected로 선언해야 한다.

<h4 data-ke-size="size20">## 6. 클래스를 상속용으로 설계할 때는 주의해야 한다.</h4>
- 클래스를 상속용으로 설계하려면 엄청난 노력이 들고 그 클래스에 안기는 제약도 상당하다.
- 추상 클래스나 인터페이스의 골격 구현처럼 상속을 허용하는 게 명백히 정당한 상황이 있고, 불변 클래스처럼 명백히 잘못된 상황이 있다.
- 일반적인 구체 클래스는 final도 아니고 상속용으로 설계되지도 않았고 문서화되지도 않았다. 따라서 그대로 두면 위험하다. 클래스에 변화가 생길 때마다 하위 클래스를 오동작하게 만들 수 있다.
 * 이 문제를 해결하는 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다.

<h4 data-ke-size="size20">### 7. 상속을 금지하는 두 가지 방법</h4>
1. 클래스를 final로 선언
2. 모든 생성자를 private나 package-private로 선언하고 public 정적 팩터리를 만들어 주는 것

- 핵심 기능을 정의한 인터페이스가 있고, 클래스가 그 인터페이스를 구현했다면 상속을 금지해도 개발하는 데 아무런 어려움이 없을 것이다. Set, List, Map이 그 예다. 또는 래퍼 클래스를 이용하는 것도 적절한 대안이 될 수 있다.

### 상속을 반드시 허용해야 한다면?
- 클래스 내부에서는 재정의 가능 메서드를 사용하지 않게 만들고 문서로 남겨야 한다.
- 즉, 재정의 가능 메서드를 호출하는 자기사용 코드를 완벽히 제거해야 한다.
- 이렇게 하면 상속해도 그리 위험하지 않다. 메서드를 재정의해도 다른 메서드의 동작에 아무런 영향을 주지 않기 때문이다.

<h4 data-ke-size="size20">## 정리</h4>
- 상속용 클래스를 설계한다면, 클래스 내부에서 스스로를 어떻게 사용하는지(자기사용 패턴) 모두 문서로 남겨야 한다.
- 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다. 그러지 않으면 그 내부 구현 방식을 믿고 활용하던 하위 클래스를 오동작하게 만들 수 있다.
- 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다.
- 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 낫다.
- 상속을 금지하려면 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다. 
</div>
							

							
								
							

							


						
					

					

					

					

					

					

					
						
					
				</div></div>

개구린개구리

# 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라.
 
## 1. 상속을 고려한 설계와 문서화
- 메서드를 재정의하려면 어떤 일이 일어나는지 정확히 정리하여 문서로 남겨야 한다. 즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 (자기사용) 문서로 남겨야 한다.
- 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 그런데 재정의가 가능한 메서드라면 그 사실을 API 명세에 적시해야 한다.
 
## 2. 좋은 API 문서란 어떻게가 아닌 무엇을 하는지를 설명해야 한다.
- 상속이 캡슐화를 해치기 때문에 안전하게 상속할 수 있도록 하려면 내부 구현 방식을 설명해야 한다. 그래서 특정 클래스의 메서드를 재정의하면 내부의 다른 메서드의 동작에 주는 영향도 정확하게 설명하고 있는 API들이 있다.
 
### @implSpec
- 자기사용 패턴(self-use pattern)에 대해서도 문서에 남겨 다른 프로그래머에게 그 메서드를 올바르게 재정의하는 방법을 알려야 한다.
- 일반적인 문서화 주석은 해당 메서드와 클라이언트 사이의 관계를 설명한다.
 - @implSpec 주석은 해당 메서드와 하위 클래스 사이의 관계를 설명하며, 하위 클래스들이 그 메서드를 상속하거나 super 키워드를 이용해 호출할 때 그 메서드가 어떻게 동작하는지를 명확히 인지하고 사용하게 해야 한다.
- tag "implSpec:a:Implementation Requirement" 스위치를 키지 않으면 @implSpec 태그를 무시한다.
 
- 효율적인 하위 클래스를 큰 어려움없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태로 공개해야 할 수도 있다. 또는 드물게는 protected 필드로 공개해야 할 수도 있다.
 
## 3. 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출
- protected 메서드 하나하나가 내부 구현에 해당하므로 그 수는 가능한 적어야 한다. 다만, 너무 적게 노출해서 상속으로 얻는 이점을 없애지 않도록 주의해야 한다.
- 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다.
- 꼭 필요한 protected 멤버를 놓쳤다면 하위 클래스를 작성할 때 그 빈자리가 확연히 드러난다.
- 거꾸로 하위 클래스를 여러개 만들 때까지 전혀 쓰이지 않는 protected 멤버는 사실 private 였어야 할 가능성이 크다.
 
## 4. 상속용 클래스는 영원히 책임져야 한다.
- 널리 쓰일 클래스를 상속용으로 설계한다면 문서화한 내부 사용 패턴과 protected 메서드와 필드를 구현하면서 선택한 결정을 영원히 책임져야 한다.
- 이 결정들이 그 클래스의 성능과 기능에 영원한 족쇄가 될 수 있다.
- 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.
 
## 5. 상속용 클래스의 생성자는 재정의 메서드를 호출해서는 안된다.
- 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 기능 메서드를 호출해서는 안된다.
- 상위 클래스의 생성자는 하위클래스의 생성자 보다 먼저 실행되고, 하위클래스에서 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면, 의도대로 동작하지 않을 것이다.
- private, final, static 메서드는 재정의가 불가능하니 생성자에서 안심하고 호출해도 된다.
 
### clone과 readObject 메서드
- clone과 readObject 메서드는 생성자와 비슷한 효과를 낸다. (새로운 객체를 만든다.)
- 따라서, 상속용 클래스에서 Cloneable 이나 Serializable을 구현할지 정해야 한다면, 이들을 구현할 때 따라는 제약도 생성자와 비슷하다.
- 즉, clone과 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.
- readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의한 메서드부터 호출하게 된다.
- clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 수정하기 전에 재정의한 메서드를 호출한다.
- Serializable을 구현한 상속용 클래스가 readResolve나 withReplace 메서드를 갖는다면 이 메서드들은 private가 아닌 protected로 선언해야 한다.
 
## 6. 클래스를 상속용으로 설계할 때는 주의해야 한다.
- 클래스를 상속용으로 설계하려면 엄청난 노력이 들고 그 클래스에 안기는 제약도 상당하다.
- 추상 클래스나 인터페이스의 골격 구현처럼 상속을 허용하는 게 명백히 정당한 상황이 있고, 불변 클래스처럼 명백히 잘못된 상황이 있다.
- 일반적인 구체 클래스는 final도 아니고 상속용으로 설계되지도 않았고 문서화되지도 않았다. 따라서 그대로 두면 위험하다. 클래스에 변화가 생길 때마다 하위 클래스를 오동작하게 만들 수 있다.
 * 이 문제를 해결하는 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다.
 
### 7. 상속을 금지하는 두 가지 방법
1. 클래스를 final로 선언
2. 모든 생성자를 private나 package-private로 선언하고 public 정적 팩터리를 만들어 주는 것
 
- 핵심 기능을 정의한 인터페이스가 있고, 클래스가 그 인터페이스를 구현했다면 상속을 금지해도 개발하는 데 아무런 어려움이 없을 것이다. Set, List, Map이 그 예다. 또는 래퍼 클래스를 이용하는 것도 적절한 대안이 될 수 있다.
 
### 상속을 반드시 허용해야 한다면?
- 클래스 내부에서는 재정의 가능 메서드를 사용하지 않게 만들고 문서로 남겨야 한다.
- 즉, 재정의 가능 메서드를 호출하는 자기사용 코드를 완벽히 제거해야 한다.
- 이렇게 하면 상속해도 그리 위험하지 않다. 메서드를 재정의해도 다른 메서드의 동작에 아무런 영향을 주지 않기 때문이다.
 
## 정리
- 상속용 클래스를 설계한다면, 클래스 내부에서 스스로를 어떻게 사용하는지(자기사용 패턴) 모두 문서로 남겨야 한다.
- 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다. 그러지 않으면 그 내부 구현 방식을 믿고 활용하던 하위 클래스를 오동작하게 만들 수 있다.
- 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다.
- 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 낫다.
- 상속을 금지하려면 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다.

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

댓글