Java를 사용할 때면 객체를 비교하기 위해 equals를 재정의하는 경우가 종종 있다. equals 메서드는 재정의하기 쉬워 보이지만 잘못하면 끔찍한 결과를 초래한다. 이 문제를 회피하기 가장 쉬운 방법은 아예 재정의하지 않는 것이다. 그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. Object.equals를 그대로 상속받기 때문이다. 그러니 다음에서 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다. equals를 재정의할 필요가 없는 경우 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 개체를 표현하는 클래스가 여기에 해당된다. Thread가 좋은 예로, Object의 equals는 이러한 클래스에 딱 맞게 구현되었다. 값 클래스라 하더라도, 값이 같은 ..

상속은 코드를 재사용하는 강력한 수단이지만 잘못 사용하면 오류를 만들어내기 쉬운 소프트웨어가 된다. 슈퍼 클래스와 서브 클래스가 같은 프로그래머에 의해 다루어지며 통제하는 경우는 안전하다. 확장할 목적으로 잘 설계되었고 문서화도 잘 된 클래스 또한 안전하다. 그러나 외부 패키지에서 이를 상속하는 경우 문제가 발생한다. 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 다르게 말하면 슈퍼 클래스가 어떻게 구현되었느냐에 따라 서브 클래스의 동작에 문제가 생길 수 있다. 슈퍼 클래스는 버전마다 내부 구현이 달라질 수 있다. 이때문에 확장을 충분히 고려하여 설계하지 않거나 문서화가 부족한 경우 이를 상속하는 서브 클래스들은 이에 발맞춰서 코드를 수정해야 하는 불상사가 생긴다. 구체적인 예제를 살펴보자. HashSe..

문제 일반적인 자바빈 규약을 준수한 객체를 생성하려고 하면 코드가 장황해지고 메서드를 여러 개 호출해야 한다. 다음과 같은 객체가 그러하다. public class Room { private int roomNo; private Sofa sofa; private TV tv; private Bed bed; public Room() {} // 게터 및 세터 } 위와 같은 경우 빈 객체를 생성하고 세터 메서드로 모두 값을 지정해주어야 한다. 이렇게 객체를 구성하면 세터로 모든 멤버 변수를 지정해주기 전까지 일관성이 무너진 상태가 된다. 또한 매개변수들이 전부 유효한지 생성자를 통해 확인했는데 세터로 값을 주입받기 시작하므로 안정성 또한 무너졌다. 이러한 문제점 때문에 버그가 발생할 확률이 증가하고 디버깅 및 유..