JAVA
클래스와 인터페이스 - 규칙 17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라.
16번에서 정의한 것처럼 계승 (이하 상속)을 받을 경우 문제를 야기할 수 있다. 그렇기에 이를 예방하기 위해서 문서를 잘 갖추고 있어야 하는데 문서를 갖춘다는 것은 어떤 의미일까? 이는 재정의 가능 메서드를 내부적으로 어떻게 사용하는지(self-use)반드시 남기라는 것이다. -> 어떤 재정의 가능 메서드를 어떤 순서로 호출하는지, 그리고 호출결과가 추후 어떤 영향을 미치는지 문서로 남기라는 의미이다. 여러 문제를 야기할 수 있기에, 계승에 맞도록 설계하고 문서화하지 않은 클래스에 대한 하위 클래스는 만들지 않아야 한다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙17 인용.
클래스와 인터페이스 - 규칙 16 계승하는 대신 구성하라.
상속은 코드를 재사용 할 수 있도록 돕는 강력한 도구이지만, 항상 최선이라 할 수 없다. 제대로 구현하지 못한 경우 문제를 유발할 가능성이 크기 때문이다. 그리고 같은 패키지 내부에 존재하는 클래스를 상속받아야한다. 상속은 일반적으로 캡슐화 원칙을 위반한다. 그 이유는 상위클래스의 일부 개념이 변경될 경우, 하위클래스는 그대로 영향을 받을 수 밖에 없기 때문이다. 이를 예방하기 위해서는 문서를 제대로 구현해 놓아야 한다. 문제가 야기될 수 있는 상황은 다음과 같다. 1. 기존의 재정의 하여 사용하였을 경우. -> 문제가 될 수 있는 상황을 예를 들면, HashSet을 상속하고 add관련 메서드를 재정의하여 객체를 추가한 횟수를 확인하는 로직을 추가하는 로직을 만들어보자 1234567891011121314..
클래스와 인터페이스 - 규칙 15 변경 가능성을 최소화하라
immutable 클래스는 그 객체를 수정할 수 없는 클래스이다. 객체 내부의 정보는 객체가 생성될 때 주어진 것이며, 객체가 살아 있는 동안 그대로 보존된다. 이러한 변경 불가능 클래스를 만드는 이유는 다양하다. - 설계가 쉽다. - 오류 가능성이 적고 안전하다. 생성 규칙 - 객체 상태를 변경하는 메서드를 제공하지 않는다. (setter) - 상속할 수 없도록 진행한다. => 하위 클래스가 객체 상태가 변경된 것처럼 동작할 수 있다. => class에 final을 붙힌다. - 모든 필드를 final로 생성한다. => 이렇게 생성할 경우 생성된 객체에 대한 참조가 동기화(Synchronization)없이 다른 스레드로 전달 되어도 안전하다. - 모든 필드를 private로 선언한다. => 모든 필드를 ..
클래스와 인터페이스 - 규칙 14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라
가끔 아래 기재된 클래스 처럼 클래스 내부에서 사용할 데이터를 처리하기 위해 임시 클래스를 만드는 경우가 있다. 1234class Temp { private String t; private String f;} cs 이런 경우에는 이 클래스를 직접 조작할 수 있기 때문에 캡슐화의 이점이 사라질 수 밖에 없다. 하지만 package-private 클래스나 private 중첩 클래스는 데이터의 필드가 공개되더라도 잘못이라 말할 수 없다. 대신 클래스가 추상화 하려는 내용을 제대로 기술하기만 하면 된다. 기존의 public 클래스가 내부 필드를 외부로 공개하는 것은 바람직하지 않지만, 변경 불가능 필드는 그 심각성이 덜하다. 다음과 같이 내부 변수를 public으로 공개하여도 어떤한 동작도 하지 못하게(immu..
클래스와 인터페이스 - 규칙 13 클래스와 멤버의 접근권한은 최소화하라.
잘 설계된 모듈과 그렇지 못한 모듈을 구분 짓는 가장 중요한 속성은 바로 구현된 세부사항을 얼마나 잘 감추었는지를 통해 확인할 수 있다. 정보은닉을 통해 서로 API를 통해서만 이용하며, 뒤에서 동작 방식은 상관하지 않기 때문에 의존성이 낮아져 병렬적으로 개발할 수 있기 때문에 유지보수의 부담감과 다른 모듈에 영향을 끼치는 부분이 줄어들게 된다. 자바의 정보은닉 원칙은 단순하다. 각 클래스와 멤버는 가능한 한 접근 불가능하도록 만드는 것. Public을 부여하는 경우에는 전역적 객체가 되고, 아무런 접근 권한을 부여하지 않으면 package-private로 내부 패키지 접근만 가능하다. 자세한 접근 권한 규칙은 다음과 같다 Private : 클래스 내부에서만 접근이 가능하다. Package-private..
모든 객체의 공통 메서드 - 규칙 12 Comparable 구현을 고려하라.
CompareTo 메서드는 Object에 선언되어 있지 않으며, Comparable 인터페이스에 포함된 유일한 메서드이다. Object의 equals 메서드와 비슷한 특성을 가지고 있으나, 동치성 검사를 넘어 순서 비교도 가능하다. Comparable 인터페이스를 구현한 객체들은 검색하거나, 정렬, 최대/최소 구하기 등이 간단하며 정렬도 다음과 같이 간단하게 진행 할 수 있다. Arrays.sort(a) 그렇기에 알파벳 순서나 값의 크기, 또는 시간적 선후 관계처럼 명확한 자연적 순서를 가지는 값을 가진 클래스를 구현할 때는 Comparable 인터페이스를 구현하는 것이 좋다. 1234Public interface Comparable { int compareTo(T t);} Colored by Color..
모든 객체의 공통 메서드 - 규칙 11 clone을 재정의할 때는 신중하라
Cloneable은 객체의 복제를 허용한다는 사실을 알리는데 쓰려고 고안된 인터페이스이다. 하지만 Cloneable은 선언된 메서드가 없는 마커 인터페이스로, 상위 클래스의 protected 멤버가 어떻게 동작할지 규정하는 용도로 쓰인다. 또한 객체의 cloneable을 구현하면, Object의 clone 메서드는 해당 객체를 필드 단위로 복사한 객체를 반환한다. Cloneable을 구현하지 않았다면, clone 메서드는 CloneNotSupportedException을 던질 것이다. Java API 문서에 기재된 clone 메서드의 명세는 다음과 같다. - 객체의 복사본을 만들어서 반환한다. - "복사"의 정확한 의미는 클래스마다 다르다. - 일반적으로 x.clone() != x 는 참이다. - x.c..
모든 객체의 공통 메서드 - 규칙 10 toString은 항상 재정의하라
toString 재정의를 하지 않은 경우 기본으로 제공되는 toString을 사용하게 될 경우 @ 기호와 16진수로 표현된 해시코드가 붙은 문자열이 반환된다. 이는 사용자가 원하는 정보가 아니므로 사용자는 해당 객체가 원하는 형태로 문자열을 반환할 수 있도록 재정의를 해놓으면 조금 더 유용하게 사용 할 수 있다. 일반적으로 toString 메서드를 재 정의하여 사용하는 경우에는 객체 내의 중요 정보를 전부 담아 반환해야 한다. 또한 toString를 재정의 하였을 경우에는 해당 내용에 대한 주석을 상세하게 기입해 놓아야 한다. 12345678910/* * 모든 객체의 멤버 변수에 대한 데이터를 반환한다. * * a는 첫번재, b는 두번 째 값이다. */ @Override public String toSt..
모든 객체의 공통 메서드 - 규칙 9 equals를 재정의할 때는 반드시 hashCode도 재정의하라
일반적으로 equals 메서드만 재 정의하고 hashCode를 재정의 하지 않아, Object.hashCode의 일반 규약을 어기게 되므로, HashMap, HashSet, Hashtable 같은 해시 기반 컬렉션과 함께 사용하면 오동작하게 된다. 실제 프로젝트에서 Equals와 hashCode를 재정의 하지 않아서 문제가 된 적이 있다. http://blog.naver.com/rokking1/220920301116 ※ hashCode 선언의 규약 - 응용프로그램 실행 중에 같은 객체의 hashCode를 여러 번 호출하는 경우, equals가 사용하는 정보들이 변경되지 않았다면, 언제나 동일한 정수가 반환 되어야 한다. - equals(object) 메서드가 같다고 판단한 두 객체의 hashCode 값은..
모든 객체의 공통 메서드 - 규칙 8 equeals 재정의할 때는 일반 규악을 따르라
Object 는 모든 객체 생성이 가능한 클래스이긴 하지만 기본적으로 계승해서 사용하도록 설계된 클래스 이다. 그런 Object에 정의된 equals, hashCode, toString, clone, finalize는 명시적인 일반 규약이 있다. 재정의 하도록 설계된 메서드들이기 때문에 상황에 따라 재정의를 하지 않을 경우 HashMap, HashSet처럼 해당 규약에 의존하는 클래스와 함께 사용하면 문제가 발생한다. ※ equals를 재 정의 하지 않아도 되는 경우 이중 equals 메서드에 대해서 이야기 해보자. Equals 재정의를 하였을 때 실패할 경우, 문제가 되기 때문에 아래와 같은 상황에서는 구태여 재정의 하지 않아도 된다. 1. 각각의 객체가 고유하다. - Thread 같은 클래스는 Obj..