기록이 힘이다.

이처럼 퇴보한 클래스는 public이어서는 안 된다! class Point{ public double x; public double y; } 캡슐화의 이점을 제공하지 못한다. 모두 private으로 바꾸고 public 접근자(getter)를 추가한다. package effectivejava.chapter4.item16; // 코드 16-2 접근자와 변경자(mutator) 메서드를 활용해 데이터를 캡슐화한다. (102쪽) class Point { private double x; private double y; public Point(double x, double y) { this.x = x; this.y = y; } public double getX() { return x; } public double g..

어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. (정보은닉, 혹은 캡슐화) 정보 은닉의 장점 -시스템 개발 속도를 높인다. -시스템 관리 비용을 낮춘다. -정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다. -소프트웨어 재사용성을 높인다. -큰 시스템을 제작하는 난이도를 낮춰준다. 자바는 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)를 명시한다. 각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자(private, protected, public)로 정해진다. 이 접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심이다. 모든 클래스와 멤버의 접근성..

Comparable 인터페이스의 유일무이한 메서드인 compareTo를 알아보자. 성격은 두 가지만 빼면 Object의 equals와 같다. compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, 제네릭하다. Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서가 있음을 뜻한다. Arrays.sort(a); 검색, 극단값 계산, 자동 정렬되는 컬렉션 관리도 역시 쉽게 할 수 있다. public class WordList{ public static void main(String[] args){ Set s = new TreeSet(); Collections.addAll(s, args); System.out.println(s); } } 명령줄 인수들을 (중복은 제거하..

Cloneable 인터페이스는 Object의 protected 메서드인 clone의 동작 방식을 결정한다. Cloneable의 경우에는 상위 클래스에 정의된 protected 메서드의 동작 방식을 변경한 것이다. clone규약 x.clone() != x 반드시 true x.clone().getClass() == x.getClass() 반드시 true x.clone().equals(x) true가 아닐 수도 있다. 불변 객체라면 다음으로 충분하다. Cloneable 인터페이스를 구현하고 clone 메서드를 재정의한다. clone 메서드는 사실상 생성자와 같은 효과를 낸다. 즉, clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야 한다. 그래서 stack의 clone 메..

-toString은 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야 한다. -Object의 toString은 클래스이름@16진수로 표시한 해시 코드 -객체가 가진 모든 정보를 보여주는 것이 좋다. -값 클래스라면 포맷을 문서에 명시하는 것이 좋으며 해당 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자를 제공하는 것이 좋다. -toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하는 것이 좋다. -경우에 따라 AutoValue, lombok 또는 IDE를 사용하지 않는게 적절할 수 있다. package me.whiteship.chapter02.item12; import lombok.ToString; // PhoneNumber에 toString 메서드 추가 (75쪽) p..

핵심 정리: hashCode 규약 - equals 비교를 사용하는 정보가 변경되지 않았다면 hashCode는 매번 같은 값을 리턴해야 한다. (변경되거나, 애플리케이션을 다시 실행했다면 달라질 수 있다.) - 두 객체에 대한 equals가 같다면, hashCode의 값도 같아야 한다. - 두 객체에 대한 equals가 다르더라도, hashCode의 값은 같을 수 있지만 해시 테이블 성능을 고려해 다른 값을 리턴하는 것이 좋다. 동작은 한다. @Override public int hashCode(){ return 42; } hashCode가 같으면 모두 같은 버킷에 들어간다. linked list 처럼 동작 --> hash값으로 꺼내기 때문에 효용의 가치가 없다. O(n)만큼 들어가서 알고리즘의 효율성이 ..

핵심 정리: equals를 재정의 하지 않는 것이 최선 다음의 경우에 해당된다면 equals를 재정의 할 필요가 없다. 각 인스턴스가 본질적으로 고유하다. ex)enum 인스턴스의 '논리적 동치성'을 검사할 필요가 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에도 적절하다. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다. 핵심 정리: equals 규약 반사성: A.equals(A) == true 대칭성: A.equals(B) == B.equals(A) CaseInsensitiveString package me.whiteship.chapter02.item10; import java.util.ArrayList; import java.util...

public class TopLine{ //코드 9-1 try-finally - 더 이상 자원을 회수하는 최선의 방책이 아니다! 47쪽 static String firstLineOfFile(String path) throws IOException{ BufferedReader br = new BadBufferedReader(new FileReader(path)); try{ return br.readLine(); }finally{ br.close(); } } public static void main(String[] args) throws IOException{ System.out.println(firstLineOfFile("pom.xml")); } } public class BadBufferedReader..