kingsubin kingsubin

// 예시 1 - Bad class Point { public double x; public double y; } 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다. API 를 수정하지 않고는 내부 표현을 바꿀 수 없다. 불변식을 보장할 수 없다. 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. // 예시 2 - Good class Point { private double x; private double y; public Point(double x, double y) { this.x = x; this.y = y; } // getter, setter } 접근자와 변경자 메소드를 활용해 데이터를 캡슐화한다. // 예시 3. 불변 필드를 노출한 public 클래스 - 과연 좋은가..

잘 설계된 컴포넌트 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐. 구현과 API 를 깔끔하게 분리한다. 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉의 장점 정보은닉, 캡슐화 라고 하는 개념은 소프트웨어 설계의 근간이 되는 원리다. 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발 할 수 있기 때문이다. 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅 할 수 있다. 다른 컴포넌트로 교체하는 부담이 적다. 성능 최적화에 도움을 준다. 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화가 가능하다. 소프트웨어 재사용성을 높인다. 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 낯선 환경에서..

package java.lang; import java.util.*; public interface Comparable { public int compareTo(T o); } compareTo() 동치성비교 순서 비교 제네릭 Comparable 구현시 해당 클래스의 인스턴스들에는 자연적인 순서가 있음을 뜻한다. Arrays.sort(a); 와 같이 손쉽게 정렬이 가능하다. 자바 플랫폼 라이브러리의 모든 값 클래스와 열거타입이 Comparable을 구현했다. 이 인터페이스를 활용하는 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다. 알파벳, 숫자, 연대 같이 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 을 구현하자. compareTo() 규약 이 객체와 주어진 객체의 순서를 비교한..

다룰 내용 clone 메서드를 잘 동작하게끔 해주는 구현 방법 언제 그렇게 해야 하는지, 가능한 다른 선택지에 관해 Cloneable Interface 가 하는 일 메서드 하나 없는 인터페이스 Object.clone()의 동작 방식을 결정한다. Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환하며, 그렇지 않은 클래스의 인스턴스에서 호출시 CloneNotSupportedException을 던진다. clone 규약 // 이 객체의 복사본을 생성해 반환한다. // 복사의 정확한 뜻은 그 개체를 구현한 클래스에 따라 다를 수 있다. // true x.clone() != x // true x.clone().getClass() == x.getCl..

toString 규약 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 나타내라 모든 하위 클래스에서 이 메서드를 재정의하라 Object.toString() public String toString() { return getClass().getName() + "@" + Integer.toHexString(hashCode()); } IDE에서의 toString() 재정의 // PhoneNumber.class @Override public String toString() { return "PhoneNumber{" + "areaCode= '" + areaCode + '\'' + ", prefix='" + prefix + '\'' + ", lineNum=..

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 hashMap, hashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 수 있다. hashCode 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메소드는 몇 번을 호출해도 같은 값을 반환해야 한다. equals()가 true 를 반환하면, 두 객체의 hashCode는 같은 값을 반환해야 한다. equals()가 false 를 반환해도, 두 객체의 hashCode가 다를 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다. 좋은 hashCod..

아래에 상황 중 하나에 해당한다면 equals 는 재정의 하지 않는 것이 최선이다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스 ex) Thread 인스턴스의 '논리적 동치성'을 검사할 일이 없다. 상위 클래스에서 재정의한 equals 가 하위 클래스에도 딱 들어맞는다. 예를들어 대부분의 Set, List 구현체들은 AbstractSet, AbstractList가 구현한 equals 를 그대로 사용한다. 클래스가 private 이거나 package-private이고 equals 메소드를 호출할 일이 없다. // euqals가 실수로라도 호출되는걸 막고싶을 때 @override public boolean equals(Obejct o) { throw new As..

자바 라이브러리에는 close 메소드를 호출해 직접 닫아줘야 하는 자원이 많다. ex) InputStream, OutputStream, java.sql.Connection 자원 닫기는 클라이언트가 놓치기 쉬워 예측할 수 없는 성능 문제로 이어지기도 한다. 상당수가 finalizer 를 안전망으로 사용하지만 믿을만하지 못하다. (아이템 8) 이전에는 자원이 제대로 닫힘을 보장하는 수단으로 try-finally 를 주로 사용했다. try-finally // 자원이 1개인 경우 static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try {..