Item16 Item 16 : 계승하는 대신 구성하라 계승 => 상속 요약 상속(계승)은 강력한 도구지만 캡슐화 원칙을 침해하므로 문제를 발생시킬 소지가 있다.상위 클래스와 하위클래스 사이에 IS-A 관계가 있을 때만 사용하는 것이 좋다.IS-A 관계라도 서로 다른 패키지에 있거나 상속을 고려해 만들어진 상위클래스가 아니라면 하위 클래스는 깨지기 쉽다.이런문제 때문에 구성과 전달 기법을 사용하는 것이 좋다. 계승은 캡슐화 원칙을 위반한다. 하위 클래스가 정상 동작하기 위해서는 상위 클래스의 구현에 의존할 수 밖에 없다. 상위 클래스 작성자가 계승을 고려해 클래스를 설계하고 문서까지 만들어 놓지 않았다면, 하위 클래스는 상위 클래스의 변화에 발맞춰 진화해야 한다. B는 A와 "IS-A" 관계가 성립할 때 ..
Item15 Item 15 : 변경 가능성을 최소화하라 요약1. 변경 가능한 클래스로 만들 타당한 이유가 없다면, 반드시 변경 불가능 클래스로 만들어야 한다. 2. 변경 불가능한 클래스로 만들 수 없다면, 변경 가능성을 최대한 제한하라. 3. 특별한 이유가 없다면 모든 필드는 final로 선언하라. 변경 불가능(Immutable) 클래스 어떤 메소드도 외부에서 관측 가능한 상태변화를 야기하지 않아야 한다. String class public final class String implements java.io.Serializable, Comparable, CharSequence { /** The value is used for character storage. */ private final char val..
Item14 Item 14 : public 클래스 안에는 public필드를 두지 말고 접근자 메서드를 사용하라 요약 1. public class는 변경가능 필드를 외부로 공개하면 안된다. 2. package-private class/ private nested class의 필드는 public이 바람직할 때도 있다. 정보은닉 //잘못된 클래스 (데이터 필드 직접 조작 가능 -> 캡슐화 안됨) class Point{ public double x; public double y; } //getter, setter를 이용한 데이터 캡슐화 class Point { private double x; private double y; public Point(doyble x, double y){ this.x = x; thi..
Item13. 클래스와 멤버의 접근 권한은 최소화하라 Item 13 : 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 모듈과 그렇지 못한 모듈을 구별 짓는 가장 중요한 속성 하나는 모듈 내부의 데이터를 비롯한 구현 세부사항을 다른 모듈에 잘 감추느냐의 여부다. 요약1. 접근권한은 가능한 낮추라 2. 최소한의 public API를 설계한 다음, 다른 모든 클래스, 인터페이스, 멤버는 API에서 제외하라 3. public static final 필드를 제외한 어떤 필드도 public 필드로 선언하지 마라 4. public static final 필드가 참조하는 객체는 변경 불가능 객체로 만들라 정보은닉 모듈 사이의 의존성을 낮추자각자 개별적으로 개발, 테스트, 유지보수 등 수행다른 모듈에 영향을 끼치지 ..
Item12. Comparable 구현을 고려하라 Item 12 : Comparable 구현을 고려하라 (Consider implementing Comparable) Comparable 인터페이스를 구현하는 클래스의 객체들은 자연적 순서(natural ordering)를 갖게 된다. 자바 플랫폼 라이브러리에 포함된 거의 모든 value class는 Comparable 인터페이스를 구현한다. compareTo() 잘못짜면 비교 연산에 기반한 클래스들이 오작동할 수 있다. TreeSet이나 TreeMap 같은 sorted collection Arrays와 Collections같은 utility class 탐색과 정렬 알고리즘을 포함하는 class -> 당연.. compareTo가 이상하면 정렬이상하게 되겠찌..
Item10. toString은 항상 재정의하라 Item 10 : toString은 항상 재정의하라 (Always override toString) toString 일반 규약[JavaSE6] "사람이 읽기 쉽도록 간략하지만 유용한 정보를 제공해야 한다." toString을 잘 만들어 놓으면 클래스를 좀 더 쾌적하게 사용할 수 있다. 디버깅, 유지보수, 간단한 체크할 때 유용 기본 Object의 toString()은 className@해시코드 이기때문에 의미없다. {Jenny=PhoeNumber@163b91} {Jenny=(707) 867-5309} 어떤 toString이 더 유용하겠는가? 가능하다면 toString 메서드는 객체 내의 중요 정보를 전부 담아 반환해야 한다. 객체가 아주 크거나 문자열로 변..
Item09. equals를 재정의할 때는 반드시 hashCode도 재정의하라 Item 09 : equals를 재정의할 때는 반드시 hashCode도 재정의하라 (Always override hashCode when you override equals) Object 클래스 명세 일반 규약[JavaSE6] 프로그램 실행 중에 객체의 hashCode를 여러 번 호출하는 경우, equals가 사용하는 정보들이 변경되지 않았다면, 언제나 동일한 정수(integer)가 반환되어야 한다. 종료 후 다시 실행시 값이 같을 필요는 없다. equals() 가 같다고 판정한 두 객체의 hashCode 값은 같아야 한다. equals() 가 다르다고 판정한 두 객체의 hashCode가 같을 수도 있다. 이 경우 hash t..
README Item 08 : equals를 재정의할 때는 일반 규약을 따르라 (Obey the general contract when overriding equals) equals() 를 재정의(overriding) 안해도 될 때 각각의 객체가 고유(unique)할 때 클래스에 "논리적 동일성(logical equality)" 검사 방법이 있건 없건 상관없을 때 상위 클래스에서 재정의한 equals()를 하위클래스에서 사용해도 문제없을 때 클래스가 private또는 package-private로 선언되었고, equals()를 호출할 일이 없을 때 euqals()를 재정의 해야할 때 객체 동일성(object equality)이 아닌 논리적 동일성(logical equality)의 개념을 지원하는 클래스일..
