개발공부블로그

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

하지만 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와 같이 지정하지 않는 이유는?

이클립스에 SDK 설치 등등을 하는 챕터이다. 지금은 안드로이드 스튜디오를 쓰기도 하고 별다른 내용이 없어서 정리는 하지 않겠다..

안드로이드

안드로이드 플랫폼의 구조를 나타낸 것으로 크게 애플리케이션 플레임워크,라이브러리,안드로이드 런타임,리눅스 커널로 구성되어 있다.

안드로이드 프레임워크