레퍼런스 마이닝

계승을 위한 설계와 문서를 갖추지 않은 '이질적(foreign)' 클래스의 하위 클래스를 만들 때 생기는 문제점을 설명하고 있다. 그렇다면 계승을 위한 설계와 문서를 갖춘다는 것은 어떤 의미일까? 상속을 위한 문서에는 재정의 가능 메서드를 내부적으로 어떻게 사용하는지(self-use) 반드시 문서에 남기라는 것이다. public이나 protected로 선언된 모든 메서드와 생성자에 대해, 어떤 재정의 가능 메서드를 어떤 순서로 호출되는지, 그리고 호출 결과가 추후 어떤 영향을 미치는지 문서로 남기라는 것이다. 클래스 내부 동작에 개입할 수 있는 훅(hooks)을 신중하게 고른 protected 메서드 형태로 제공해야 한다. protected 멤버 개수는 가능한 줄여야 한다. 너무 적으면 상속해서 쓰기에 ..

계승은 코드 재사용을 돕는 강력한 도구지만, 항상 최선이라고는 할 수 없다. 계승은 상위 클래스와 하위 클래스 구현을 같은 프로그래머가 통제하는 단일 패키지 안에서 사용하면 안전하다. 이번 절에서 다루는 문제는 '인터페이스 계승' 에는 적용되지 않는다. 어떤 클래스가 다른 인터페이스를 'implement' 하거나, 어떤 인터페이스가 다른 인터페이스를 'extends' 하는 경우에는 해당되지 않는다. 메서드 호출과 달리, 계승은 캡슐화(encapsulation) 원칙을 위반한다. 상위 클래스의 구현은 릴리즈가 거듭될수록 변경되는데 하위 클래스는 수정된 적이 없어도 망가질 수 있다. public class InstrumentedHashSet extends HashSet { private int addCoun..

변경 불가능(immutable) 클래스는 그 객체를 수정할 수 없는 클래스다. 객체 내부의 정보는 객체가 생성될 때 주어진 것이며, 객체가 살아 있는 동안 그대로 보존된다. 자바 플랫폼 라이브러리에는 이런 클래스가 많다. String, 기본 자료형 클래스, BigInteger, BigDecimal 등이 그런 클래스다. 변경 불가능 클래스를 만드는 이유는 단순하다. 우선 변경 불가능 클래스는 변경 가능 클래스보다 설계하기 쉽고, 구현하기 쉬우며, 사용하기도 쉽다. 오류 가능성도 적고, 더 안전하다. 변경 불가능 클래스를 만들 때는 아래의 다섯 규칙을 따르면 된다. 1. 객체 상태를 변경하는 메서드(setter)를 제공하지 않는다. 2. 계승할 수 없도록 한다. 계승을 금지하려면 보통 클래스를 final로 ..

// 이런 클래스는 절대로 public으로 선언하지 말것 class Point { public double x; public double y; } 때때로, 아무 기능도 없는 클래스를 만들고 싶어 질 때가 있다. 하지만 이런 클래스는 데이터 필드를 직접 조작할 수 있어서 캡슐화의 이점을 누릴 수가 없다. API를 변경하지 않고서는 내부 표현을 변경할 수 없고, 불편식도 강제할 수 없고, 필드를 사용하는 순간에 어떤 동작이 실행되도록 만들 수도 없다. 객체지향 개념에 충실하고자 하는 프로그래머에게 이런 클래스는 최악이다. private필드와 public 접근자 메서드(getter/setter)를 제공해야 할 것이다. public 클래스 즉 선언된 패키지 밖에서도 사용 가능한 클래스에서는 접근자 메서드를 제공..

잘 설계된 모듈은 구현 세부사항을 전부 API 뒤쪽에 감춘다. 내부적으로 무슨 짓을 하는지는 신경 쓰지 않는다. 이 개념은 정보은닉(information hiding) 또는 캡슐화(encapsulation)라는 용어로 알려져 있으며, 소프트웨어 설계의 기본 원칙 가운데 하나다. 정보은닉이 좋은 성능을 보장하는 건 아니지만 성능 문제를 일으키는지 프로파일링 하는데 용의 하다. 또한 병행 개발이 가능하며, 다른 코드에 영향 없이 디버깅이나 성능 튜닝을 할 수 있다. 각 클래스와 멤버는 가능한 한 접근 불가능하도록 만들어라. 다시 말해서 정상적인 동작을 보증하는 한도 내에서 가장 낮은 접근 권한을 설정하라는 것이다. 클래스 접근 권한자 package-private(default) public을 붙이지 않으면 ..

compareTo 메서드는 Object에 선언되어 있지 않다. 사실 이 메서드는 Comparable 인터페이스에 포함된 유일한 메서드다. Object의 equals 메서드와 특성은 비슷하지만, 단순한 동치성 검사 이외에 순서 비교가 가능하다. Comparble을 구현한 클래스는 다양한 제네릭 알고리즘 및 컬랙션 구현체와 상호 연동이 가능하다. Comparable 인터페이스를 구현하는 클래스의 객체들은 자연적 순서(natural ordering)를 갖게 된다. compareTo 메서드의 일반 규약은 equals와 비슷하다. 객체의 값이 인자로 주어진 객체보다 작으면 음수를, 같으면 0을, 크면 양수를 반환한다. sgn(expression)은 수학에서의 signum 함수를 나타내는 것으로, -1, 0, 1 ..

Cloneable은 어떤 객체가 복제(clone)를 허용한다는 사실을 알리는 데 쓰려고 고안된 믹스인(mixin) 인터페이스다. 기본적인 문제는 이 인터페이스에는 clone 메서드가 없으며, Object의 clone 메서드는 protected로 선언되어 있다는 것이다. Cloneable 인터페이스에 아무런 메서드도 없다면 대체 Cloneable이 하는 일은 무엇인가? protected로 선언된 Object의 clone 메서드가 어떻게 동작할지 정한다. 만일 어떤 클래스가 Cloneable을 구현하면, Object의 clone 메서드는 해당 객체를 필드 단위로 복사한 객체를 반환한다. Cloneable을 구현하지 않은 클래스라면 clone 메서드는 CloneNotSupportedException을 던진다...

java.lang.Object 클래스가 toString 메서드를 제공하긴 하지만 이 메서드가 반환하는 문자열은 일반적인 문자열이 아니다. 클래스 이름 다음에 @ 기호와 16진수로 표현된 해시 코드가 붙은 문자열이다. toString의 일반 규약에는 '모든 하위 클래스는 이 메서드를 재정의함이 바람직하다.(It is recommended that all subclasses override this method.)' 라는 구절도 있다. toString을 재정의 하면 디버깅할 때에도 많은 도움이 된다. 그리고 객체를 바로 문자열과 연결시켜 사용할 때도 편하게 작업할 수 있다. 가능하다면 toString 메서드는 객체 내의 중요 정보를 전부 담아 반환해야 한다. toString이 반환하는 문자열의 형식을 떠나 ..

많은 버그가 hashCode 메서드를 재정의하지 않아서 생긴다. equals 메서드를 재정의하는 클래스는 반드시 hashCode 메서드도 재정의 해야 한다. 그렇지 않으면 Object.hashCode의 일반 규약을 어기게 되므로 HashMap, HashSet, Hashtable 같은 hash 기반 컬렉션과 함께 사용하면 오동작하게 된다. 일반 규약 같은 객체의 hashCode를 여러 번 호출하는 경우 equals가 사용하는 값이 변경되지 않았다면 언제나 동일한 정수(Integer)가 반환되어야 한다. 단 프로그램이 재시작되었을 경우 같은 값이 나올 필요는 없다. equals 메서드가 같다고 판정한 두 객체의 hashCode 값은 같아야 한다. equals 메서드가 다르다고 판정한 두 객체의 hashCod..

equals 메서드는 재정의하기 쉬워 보이지만 실수할 여지도 많다. 이런 문제를 피하는 가장 간단한 방법은 equals 메서드를 재정의 하지 않는 것이다. 아래 조건 중 하나라도 만족하면 equals 메서드를 재정의 하지 않아도 된다. 각각의 객체가 고유한 경우 상위 클래스에서 재정의한 equals가 하위 클래스에서 사용하기에도 적당 한 경우 그렇다면 Object.equals를 재정의하는 것이 바람직할 때는 언제인가? 객체 동일성(Object equality)이 아닌 논리적 동일성(Logical equality)의 개념을 지원하는 클래스인 경우 상위 클래스의 equals가 하위 클래스의 필요를 충족하지 못하는 경우 값 클래스(Value Class)는 대체로 그 조건에 부합한다. Value Class (I..