개발공부블로그

 선언된 패키지 밖에서도 사용 가능한 클래스에는 접근자 메서드를 제공하라. 그래야 클래스 내부 표현을 자유로이 수정할 수 있게 된다. 

하지만 package-private 클래스나 private 중첩 클래스는 데이터 필드를 공개하더라도 잘못이라 말할 수 없다. 클래스의 내용을 제대로 기술하기만 한다면, 접근자 메서드보다는 시각적으로 깔끔하다. private 중첩 클래스의 경우는, 그 클래스의 바깥 클래스 외부의 코드는 아무 영향도 받지 않을 것이기 떄문이다.

요약

잘 설계된 모듈과 그렇지 못한 모듈을 구별 짓는 가장 중요한 속성 하나는 모듈 내부의 데이터를 비롯한 구현 세부사항을 다른 모듈에 잘 감추었느냐는 것이다. 정보은닉과 캡슐화가 잘 되어진 모듈은 모듈사이의 의존성을 낮춰서, 각자 개별적으로 개발 및 변경이 가능하다. 또한 다른 모듈에 영향을 끼칠 걱정 없이 디버깅을 진행할 수 있기 때문에 좋은 성능을 낸다고 할 순 없지만, 효과적인 성능튜닝을 할 수 있는 방법이다.

접근제어는 클래스와 인터페이스, 그리고 그 멤버들의 접근 권한을 규정한다. 접근 제어의 적절한 사용은 정보 은닉 원칙을 실현하는 핵심적인 부분이다.

각 클래스와 멤버는 가능한 한 접근 불가능하도록 만들어라

객체 필드는 절대로 PUBLIC으로 선언하면 안된다.

public static final 배열 필드를 두거나, 배열 필드를 반환하는 접근자를 정의해서는 안된다.

compareTo 메소드는 Comparable 인터페이스를 구현하는 유일한 메소드이다. Comparable인터페이스를 구현하는 클래스의 객체들은 자연적 순서를 갖게 된다.Comparable을 구현한 객체들의 배열을 정렬하는 것은 아래처럼 아주 간단하다.

 마찬가지로 Comparable 인터페이스를 구현한 객체들은 검색하거나 최대/최소치 계산하기도 간단하다. 그러므로

알파벳 순서나 값의 크기, 또는 시간적 선후관계처럼 명확한 자연적 순서를 따르는 값 클래스를 구현할 때는 Comparable 인터페이스를 구현할 것을 고려해봐야 한다.

compareTo 규약

-객체 참조를 비교하는 방향을 뒤집어도 객체 간 대소 관계는 그대로 유지되어야 한다. 즉 만일 첫 번째 객체가 두번째 객체봐 작다면, 두 번째 객체는 첫 번째 객체보다 큰 객체여야 한다. ( a.compareTo(b) 가 1이면 b.compareTo(a) 는 -1 이어야 한다.)

-첫 번째 객체가 두 번째 객체보다 크고 두 번째 객체가 세 번째 ㄱ개체보다 클 경우 첫 번째 객체는 반드시 세 번째 객체보다 커야 한다.

(a.compareTo(b) 가 1이고 , b.compareTo(c)가 1이면 , a.compareTo(c) 는 1이다.)

-비교결과 같다고 판정된 모든 객체 각각을 다른 어떤 객체와 비교할 경우, 그 비교 결과는 전부 통일해야 한다.

즉, 반사성, 대칭성, 추이성을 만족해야 한다는 것인데 이는 equals의 규약과 같다.

내용이 어렵다..나중에 다시 정리하도록 하자..

cloneable은 어떤 객체가 복제를 허용한다는 사실을 알리는데 쓰려고 고안된 인터페이스다. cloneable 인터페이스에는 어떠한 메소드도 없는데 그렇다면 대체 Cloneable이 하는 일은 무엇일까? protected로 선언 된 Object의 clone메서드가 어떻게 돚악할지 정하는 역할을 한다. Cloneable 인터페이스를 구현하면 해당 객체를 필드 단위로 복사한 객체를 반환한다. 구현하지 하지 않은 클래스라면 CloneNotSupportedException이 발생한다.

사실 인터페이스라는 것은 클라이언트에게 해당 클래스가 무슨 일을 할 수 있는지 알리는 것인데, Cloneable은 상위 클래스의 protected 메서드의 동작을 규정하는 역할을 하고 있으므로 좀 이상하다..

clone을 정의해야할 때 주의해야 할 점은 복재할 객체가 변경 가능 객체에 대한 참조필드를 가지고 있다면 일반적인 방법으로는 오동작하게 될 확률이 매우매우매우 높다. 

 위의 두 클래스가 있다고 했을 때, 단순히 super.clone을 해버리면 원본 객체와 복사 된 객체가 obj에 대한 같은 참조값을 가지게 되므로 문제가 생긴다. clone메소드 또 다른 형태의 생성자로 볼수 있다. 원래 객체를 손상시키는 일이 없도록 해야하고, 복사본의 불변식도 제대로 만족해야 한다. 

이러한 문제는 clone을 재귀적으로 호출하여 처리할 수 있다. 

정리

java.lang.Object 클래스가 toString 메서드를 제공하긴 하지만, 이 메서드가 반환하는 문자열은 일반적으로는 사용자가 보려는 문자열이 아니다. 클래스 이름 다음에 @ 기호와 16진수로 표시된 해시 코드가 붙은 문자열의 형태이다. 

"toString() 메소드는 사람이 읽기 쉽도록 간략하지만 유용한 정보를 제공해야 한다"

toString이 반환하는 문자열의 형식을 문서의 반환할 것인가 , 말 것 인가의 문제

toString 메서드는 어떤 의도로 작성되었는지 문서에 남겨두어야 한다. 그리고 toString에 포함되어 반환되는 정보들은 전부 프로그래밍을 통해서 가져올 수 있도록 하여야 한다(메서드를 통하여..)

equals 메서드를 재정의하는 클래스는 반드시 hashCode 메서드도 재정의 해야 한다. 그렇지 않으면 hashCode의 일반 규약을 어기게 되므로 해시기반 컬렉션과 함께 사용하면 오동작하게 된다.

실행중에 hashCode를 여러 번 호출하는 경우, equals가 사용하는 정보들이 변경되지 않았다면, 언제나 동일한 정수가 반환되어야 한다.

equals 메서드가 같다고 판정한 두 객체의 hashCode 값은 같아야 한다.

equals 메스더가 다르다고 판정한 두 객체의 hashCode 값은 꼭 다를 필요는 없다.

쓸만한 hashCode 만드는 법

hashCode를 명시적으로 42와 같이 지정하지 않는 이유는?

equals 메서드를 재정의하지 않아도 되는 경우.

1.각각의 객체가 고유하다. 

-값 대신 활성 개체를 나타내는 Thread 같은 클래스가 이 조건에 부합한다.

2.클래스의 논리적 동일성 검사 방법이 있건 없건 상관없다. 

3.상위 클래스에서 재정의한 equals가 하위 클래스에서 사용하기에도 적당하다

4.클래스가 private or package-private로 선언되어있고 equals를 호출할 일이 없다.

equals 메서드를 재정의 해야할 때

1.논리적 동일성의 개념을 지원하는 클래스.

2.상위 클래스의 equals가 하위 클래스의 필요를 충족치 못할 때.

equals 메서드는 동치 관계를 구현한다

• 반사성 : 모든 객체는 자신과 같아야 한다.  x.equals(x) 는 true
• 대칭성 : 두 객체에게 서로 같은지 물으면 같은 답이 나와야 한다. x.equals(y) == y.equals(x) 
• 추이성 : x.equals(y) 가 같고, y.equals(z) 가 같으면 x.equals(z)는 같아야 한다.
• 일관성 : x.equals(y) 가 같다고 판단되었으면, 추후 변경되지 않는 한 계속 같아야 한다.

멋진 equals 메서드를 구현하기 위한 지침.

1.  == 연산자를 사용하여 equals의 인자가 자기 자신인지 검사하라.
2. instanceof 연산자를 사용하여 인자의 자료형이 정확한지 검사하라.
3. equals의 인자를 정확한 자료형으로 변환하라. 위의 instanceof를 통과하면 반드시 성공한다.
4. 중요 필드 각각이 인자로 주어진 객체의 해당 필드와 일치하는지 검사한다.
5. equals 메서드 구현을 끝냈다면, 대칭성, 추이성, 일관성의 세 속성이 만족하는 지 검토하라.

finalize() 메소드란?

JVM이 메모리 누수를 방지하기위해 실행하는 GC가 수행될 때 더 이상 사용하지 않는 자원에 대한 정리작업을 할 때 호출하는 메소드. 이러한 종료자의 치명적인 단점이 있다. 

바로 즉시 실행되리라는 보장이 전혀 없다는 것.

종료자의 문제점은 이 뿐만이 아니다.

 일반적으로는 uncaught 예외가 던져지면 스레드는 종료되고 StackTrace가 표시되지만, 종료자 안에서는 아니다. 경고문 조차 발생하지 않는다..

또한, 종료자를 사용하면 프로그램 성능이 심각하게 떨어진다. (객체 메모리 해제 등의 이유로..)

그럼 자원의 반환 / 삭제는 어떻게?

정말 정말 종료자는 쓸 곳이 없는 녀석인가..!? ( 이것도 1번 빼고 딱히..?)

1. 명시적 종료 메서드 호출을 잊을 경우에 대비하는 안전망의 역할. 종료자는 그런 자원을 발견하게 될 경우 반드시 경고 메세지를 로그로 남겨서 코드가 잘못되어있음을 알려야 한다.

2.네이티브 피어와 연결된 객체를 다룰 때 사용될 수도 있다. 

3.하위 클래스에서 상위 클래스 종료자를 재정의 하면서 상위 클래스 종료자 호출을 잊으면, 상위 클래스 종료자는 절대 호출되지 않는다. 따라서 아래와 같이 처리할 수 있다.