개요 코드를 재사용하기 위한 일반적인 방법은 상속을 이용한 방법이 있습니다. 하지만 상속을 이용한 방법은 최선의 선택이 아니고 잘못 사용하면 오류가 발생하기 쉽습니다. 이 글에서는 어떻게 상속이 캡슐화를 망가뜨릴 수 있는지 알아보고, 상속을 잘못되게 설계한 예제를 소개합니다. 그리고 상속을 사용하여 코드를 재사용하는대신 컴포지션을 사용하여 코드를 재사용하는 방법에 대해서 소개합니다. 마지막으로 상속을 사용시 주의할 점에 대해서 알아봅니다. 1. 상속이 캡슐화를 망가뜨릴 가능성이 높은 이유는 무엇인가? 메서드 호출과는 달리 상속의 사용은 캡슐화를 망가뜨릴 가능성이 높아지게 됩니다. 상위 클래스가 어떻게 구현하느냐에 따라 하위 클래스의 동작에 이상이 발생시키거나 하위 클래스의 멤버를 노출시킬 수 있습니다. ..

1. 불변 클래스(Immutable Class)란 무엇인가? 불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스입니다. 대표적인 불변 클래스로 String, Integer와 같은 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal과 같은 클래스가 불변 클래스에 해당됩니다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 발생할 여지도 적고 훨씬 안전한 클래스입니다. 2. 클래스를 불변으로 만들기 위한 5가지 규칙 클래스를 불변 클래스로 만들려면 다음 다섯 가지 규칙을 따르면 됩니다. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않습니다 대표적인 예가 Setter 메서드가 존재합니다 클래스를 확장할 수 없도록 합니다 하위 클래스에서 객체의 상태를 변..

1. 적절하지 않는 public 클래스 class Point{ public double x; public double y; } 위와 같은 Point 클래스의 x,y 데이터 필드는 접근이 가능하기 때문에 다음과 같은 문제점이 있습니다. 데이터 필드에 직접 접근이 가능하기 때문에 캡슐화의 이점을 갖지 못합니다 외부에 클래스의 멤버를 노출시키지 않을 수 있습니다 API를 수정하지 않고는 내부 표현을 바꿀 수 없습니다 예를 들어 Point 인스턴스의 필드 x를 직접 접근하는 클라이언트가 있다면 Point 클래스의 필드 x를 함부로 바꾸기가 어렵습니다. 필드 x를 변경한다면 그것을 참조하는 클라이언트도 변경되어야 합니다. 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수 없습니다 불변..

1. Comparable을 구현할때 무엇을 고려해야 하는가? 알파벳, 숫자, 연대같이 순서가 명확한 값 클래스를 정의한다면 반드시 Comparable 인터페이스를 구현하자. Collection, Set, Map과 같은 인터페이스는 비교를 할때 Object.equals 메서드를 사용하지 않고 Comparable.compareTo 메서드를 사용하기 때문에 컬렉션과 같은 인터페이스에 인스턴스를 넣을때 Comparable을 구현하자. Comparable을 구현하지 않은 필드나 표준이 아닌 순서로 비교해야 한다면 비교자(Comprator)를 대신 사용하자. compareTo 메서드에서 관계 연산자 를 사용하는 이전 방식은 오류를 유발할 가능성이 있습니다. 클래스의 필드 멤버가 여러개 있고 비교해야 한다면..

1. toString의 규약 toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"입니다. 2. toString을 재정의 해야하는 이유는 무엇인가? toString을 재정의함으로써 인스턴스 자체를 참조할때 인스턴스 멤버에 대한 정보를 표시할 수 있기 때문이다. toString을 재정의하지 않으면 인스턴스를 출력시 클래스_이름@16진수로_표시한_해시코드를 반환할 뿐이다. toString을 재정의한 클래스를 사용하는 시스템은 디버깅이 쉽게 됩니다. 인스턴스를 참조하는 컴포넌트가 오류 메시지를 로깅(logging)할때 자동으로 호출하는데 이때 메시지에 유용한 로그를 남길 수 있습니다. 3. toString 구현시 문서화 toString을 구현할 때 반환값의 포맷을 문서화할지 정애야 합니다. ..

1. equals를 재정의 할 때 hashCode도 재정의해야 하는 이유 equals를 재정의하고 hashCode를 재정의하지 않으면 hashCode 일반 규약을 거기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet과 같은 컬렉션의 원소로 사용할때 문제를 일으킵니다. Object 명세 규약 equals 비교에서 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 합니다. 단, 애플리케이션이 다시 실행한다면 이 값이 달라져도 상관없습니다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 합니다. 두 인스턴스가 물리적으로 같은 경우 ..