'03.03.12 story

생성자나 static 팩토리 메소드에서 많은 매개변수를 갖게 될 클래스를 설계할 때는 빌더 패턴이 좋은 선택이다. 특히 선택 매개변수가 대부분인 경우가 그렇다. 그리고 그간 사용하던 텔리스코핑 생성자 패턴보다 빌더를 사요아면 클라이언트 코드의 가독성이 좋고 작성도 쉽다. 또한 빌더는 자바빈즈 패턴보다 훨씬 더 안전하다.

 

어디에서 메모리 누출이 생기는 걸까?

만일 스택이 커졌다가 줄어들면 스택에서 꺼냈던 객체들은 가비지 컬렉션되지 않을 것이다. 이 스택을 사용하는 프로그램에서 그런 객체들을 더 이상 참조하지 않더라도 마찬가지다

왜냐하면, 그 객체들을 가리키는 쓸모 없는 참조를 스택에서 가지고 있기 때문이다. 쓸모 없는 참조란, 객체에 대한 참조값을 가지고 있지만 다시는 사용되지 않을 참조를 말한다.

예를 들어, String s ="asb";

s는 asb를 참조하고 있다. 하지만 이것은 다시는 쓰이지 않을 때 문제가 발생 이것을 쓸모 없는 참조라고 한다.

이런 것들이 쌓인다면 성능에 심각한 영향을 줄 수 있다. 이런 부류의 문제에 대한 해결책은 간단하다. 즉 쓸모 없는 참조를 null로 만드는 것이다. stack에서 요소를 꺼내는 즉시 그 요소의 참조가 쓸모 없게 되므로 null로 바꾸어 주면 된다.

객체 참조를 null로 변경하는 것은 꼭 필요할 때만 예외적으로 행해야 한다.

 

equals메소드는 동등 관계를 구현

1. 재귀적이다 x.equals(x)는 true

2. 대칭적이다. x.equals(y) y.equals(x)는 항상 true여야 한다

3. 이행적이다. x.equals(y) y.equals(z)가 true이면 x.equals(z)는 true여야 한다

4. null이 아닌 모든 참조 값 x에 대해 x.equals(null)은 항상 false여야 한다.

 

equals메소드를 오버라이드 하는 모든 클래스에서는 반드시 hashCode 메소드도 오버라이드 해야한다.

 

toString 메소드는 항상 오버라이드 하자

Clone 메소드는 신중하게 오버라이드 하자

Cloneable 인터페이스는 무슨 일을 하는 걸까?

Object클래스의 protected메소드인 clone을 사용할지에 대한 여부를 결정한다.

어떤 클래스에서 Cloneable 인터페이스를 구현한다고 선언하고, Object의 clone메소드를 호출하면 그 클래스 객체의 복제본을 만들어 반환한다. 필드와 필드값도 복사된다.

Cloneable 인터페이스를 선언하지 않고 사용하면 CloneNotSupportedException예외 발생