자바
클래스와 인터페이스 - 규칙 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..
객체의 생성과 삭제 - 규칙 7 종료자 사용을 피하라
일반적으로 자주 사용하는 finalizer는 예측 불가능하며, 대체로 위험하고, 불필요하다. 그렇기에 꼭 필요로 하는 작업을 명시할 때에는, 사용해서는 안 된다. 문제 사항 1. final 문장에서 Exception이 발생하였을 경우에 하단에 기재한 문장이 실행되지 않아 결국 문제를 유발할 수도 있다. 123456789try { file = new FileWriter(new File("/test/tt"));} catch (IOException ex) { System.out.println("catch block");} finally { System.out.println(12/0); // 강제로 Exception을 발생시킨다. 하단에 file.close() 문장은 실행되지 않는다. file.close(); ..
객체의 생성과 삭제 - 규칙 6 유효기간이 지난 객체 참조는 페기하라.
Java는 GC가 있어 C나 C++처럼 순수 메모리 관리를 해주지 않아도 돼서 메모리 관리를 대부분 하지 않는다. 그러나 더 이상 참조하지 않는 객체에 대해 reference를 제거하지 않는 경우에는 어떠한 경우에도 메모리 누수가 발생되게 된다. 이런 reference는 단순하게 null 처리를 해줌으로써 해제된 참조를 해제 할 수 있다. Null로 바꾸게 되면, GC가 해당 객체를 해제할 수 있는 객체라 생각하고 반환해버린다. 하지만 이런 객체참조를 null로 처리하는 것은 규범이라기보다는 예외적인 조치가 되어야 한다. 그렇다면 이런 만기참조를 해결하는데 좋은 방법이 어떤 것인가? 가장 좋은 방법은 해당 참조가 보관된 변수가 유효범위(scope)를 벗어나게 하는 것이다. 또한 캐시(cache)도 메모리..