상속용 클래스의 문서화

• 상속용 클래스는 overriding할 수 있는 method들을 내부적으로 어떻게 이용하는 지 문서로 남겨야 한다.
• 클래스의 API로 공개된 method에서 클래스 자신의 또 다른 method를 호출할 수도 있는데, 이 method가 overriding이 가능하다면 method의 API 설명에 적어두어야 한다.
• 어떤순서로 호출되는지, 호출 결과가 이어지는 처리에 어떤 영향을 줄 수 있는지도 문서화해야한다.

문서화 예시 : https://docs.oracle.com/javase/7/docs/api/java/util/AbstractCollection.html

API 문서의 method설명 끝에서 종종 ‘This Implementation’ ~ 로 시작하는 절을 볼 수 있는데 이 부분이 method의 내부 동작 방식을 설명하는 곳이다.

클래스를 안전하게 상속할 수 있도록 하려면, 내부 구현 방식에 대해 설명해주어야 한다.

( Java method 주석에 @implSpec tag를 붙여주면 자바독 도구가 생성해준다. )

상속의 단점

• 상속은 캡슐화를 꺠트린다.

상위 class 내부 구현 변경에 따라 하위 class가 영향을 받을 수도 있다. 상위 class가 확장을 충분히 고려해두고 설계되지 않으면 하위 class는 상위 class의 변화맞추어 수정되야 한다.

다음과 같이 캡슐화되지 않은 class는 필드를 외부에서 직접 접근이 바로 가능하니 작성하지 않는 것이 좋다. (모듈간 독립성이 떨어짐)

1
2
3
4
5
6

public class Point {
    
    public double x;
    
    public double y;
}

불변 클래스란 객체 생성 후에 객체의 내부 값을 수정할 수 없는 클래스이다. 불변 객체에 간직된 정보는 고정되어 객체 소멸 시점까지 변경되면 안된다.

자바 String,primitive type boxing 클래스, BigInteger,BigDecimal 이 여기에 속한다.

불변 객체를 사용하는 이유는 다음과 같다.

• 가변 클래스보다 사용하기 쉬우며 , 안전하다.

  ex) 멀티쓰레드상황에서 여러 client가 동시에 객체를 사용하는 경우 (Thread-Safe)

불변 객체 만드는 규칙

1. 객체의 상태를 변경하는 메소드 (ex) setter) 를 제공하지 않는다

2. class를 확장할 수 없도록 한다. 대표적으로 class를 final로 선언하면 된다.

3. 모든 필드를 final로 선언한다.
   ( 어떤 method도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다. )

4. 모든 필드를 private로 선언한다. 불변 필드인 경우에는 public final로 선언하여도 불변 객체는 되지만, API를 수정하기 힘들어진다.

5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 클래스 내부에 가변 필드가 있다면, client에서 그 가변 필드의 참조값을 가지고 수정할수 있으므로 생성자/접근자/readObject method에서 모두 방어적 복사를 수행해야 한다.

잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔하게 분리한다.

오직 API를 통해서만 다른 컴포넌트와 소통하며, 서로 구체적인 동작 방식은 개의치 않는다.

정보 은닉 (Information Hiding) 의 장점

1. 시스템을 구성하는 컴포넌트를 서로 독립시켜서 개발/테스트/적용/수정 분석을 개별적으로 할 수 있게 해준다

2. 여러 컴포넌트를 병렬로 개발 가능함으로, 개발 속도를 높임

3. 각 컴포넌트를 빨리 파악 및 디버깅이 관리하고, 다른 컴포넌트로 교체하는 작업이 손쉽기 때문에 유지보수 비용이 덜 든다

4. 직접적으로 성능을 높여주지는 않지만, 성능최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정하고, 해당 컴포넌트만 최적할 수 있기 때문이다.

5. SW 재사용을 높임

6. 시스템 개발 난이도를 낮춘다. 개별 컴포넌트단위로 나누어 개발하고 테스트할 수 있기 때문이다.

compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, generic하다.

1
2
3

public interface Comparable<T> {
    public int compareTo(T o);
}

comparable을 구현했다는 것은 그 클래스의 인스턴스들에 순서가 있음을 뜻한다. 그래서 Comparable을 구현한 객체들의 배열은 다음과 같이 정렬이 가능하다.

1
2
3

Arrays.sort(arrayOfInstance);

순서가 명확한 값 class를 작성한다면 Comparable 인터페이스 구현을 고려하자.

compareTo method의 일반 규약은 다음과 같다.

 
compareTo method는 주어진 객체와 this 객체의 순서를 비교한다. 
this 객체가 주어진 객체보다 작으면 음의 정수 , 같으면 0 , 크면 양의 정수를 반환하고
이 객체와 비교할수 없는 타입의 객체가 주어지면 ClassCastException을 던진다. 
1. Comparable을 구현한 class는 모든 x,y에 대해서 sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) 
2. Comparable을 구현한 class는 추이성을 보장해야 한다. ( x.compareTo(y) > 0 && y.compareTo(z) > 0)이면 x.compareTo(z) > 0이다. 
3. Comparable을 구현한 class는 모든 z에 대해 x.compareTo(y) == 0 이면, sgn(x.compareTo(z)) == sgn(y.compraeTo(z)) 다.
4. 부가적으로 다음의 규약은 필수는 아니나 지키면 좋다.(x.compareTo(y) == 0) == x.equals(y) 여야 한다. 
   만약 위 식이 성립하지 않는다면 이 클래스의 순서는 equals method와 일관되지 않음을 명시해야 한다. 

compareTo규약을 지키지 못하면 비교를 활용하는 TreeSet, TreeMap, Collections,Array등의 클래스에서 제공해주는 API가 정상적으로 작동하지 않을 수도 있다.

Object class에는 clone() method가 protected로 선언되어 있고, 객체를 복사하려면 java.langCloneable Interface를 implement하여 복사할 수 있다.

1
2
3

package java.lang;
public interface Cloneable {
}

(https://docs.oracle.com/javase/7/docs/api/java/lang/Cloneable.html)

Cloneable은 아무 method도 없는 marker interface지만 ,Object의 clone method의 동작 방식을 결정한다.

Cloeanble을 구현한 class에서부터 만들어진 객체에서 clone을 호출하면 객체의 필드들을 복사한 객체를 반환하도록 하고, 그렇지 않은 객체에서는 CloneNotSupportedException을 던진다.

Object toString 은 별도로 overrriding 하지 않는 경우에는 class명@16진수_해시코드 를 반환한다.

1

getClass().getName() + '@' + Integer.toHexString(hashCode())

Object 명세에 보면 toString은 간결하며, 사람이 읽기 쉬운 형태의 정보를 반환해야 하며,

toString을 overrding한 모든 하위 클래스에서도 toString 을 재정의해야 하며, 해당 객체가 가진 주요 값 필드를 반환하는게 바람직하다.
(https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html)

• toString을 재정의하면 다음과 같은 장점을 가지고 있다.

  1. 해당 객체의 주요필드를 로그에 남김으로 빠른 디버깅 가능

• 선택사항 : toString 사용시 포맷을 문서화 여부

  • 값 class라면 문서화하는 것을 권장하나, 단점은 해당 포맷에 종속된다.

• 포맷 명시 여부와 상관없이 toString 반환 값에 포함된 정보를 가져올 수 있는 API 제공해야 함

hashCode method는 해싱(hashing) 기법에 사용되는 해시함수를 구현한 것이다.

hashCode가 반환해주는 결과값(해시코드값)은 hashTable,hashMap내 실제값이 저장되는 위치를 알려주는 일종의 인덱스로 사용된다.

Object 명세에 보면 다음과 같이 기술되어 있다.

(https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode())

1
2
3
4
5
6
7
8
9
10
11
12

1. equals 비교에 사용되는 정보가 변환되지 않았다면, 
   app이 실행되는 동안 객체의 hashCode값은 항상 같아야 함

2. equals(Object)가 두 객체를 같다고 판단했다면, 
   두 객체의 hashCode는 똑같은 값을 반환해야 한다.

   => 논리적으로 같은 객체는 같은 해쉬코드값을 반환해야 함

3. equals(Object)가 두 객체를 다르다고 판단했더라도,
   두 객체의 hashCode 값이 다를 필요는 없음 

• Java HashMap은 hash함수 적용할떄, hashCode값을 사용함으로 다른 두 객체가 hashCode값이 같다면 두 객체는 같은 인덱스로 해쉬됨(collision)으로 성능상 단점이 있음.
  (Jdk 8 hashMap:해시 키 값 충돌 시 separtate chaining 방식 사용)

Java에서 최상위 class인 Object의 final이 아닌 methode들 (equals, hashCode, toString ,clone, finalize)는 모두 overriding을 염두에 두고 설계된 것이라, overriding시 지켜야 하는 일반 규약이 명확하다.

1

public boolean equals(Object obj);

이 중에서 equals method는 == 연산자와 마찬가지로 참조변수의 참조값을 비교하도록 정의되어 있는데, 다음과 같은 상황에서는 overriding 하지 않는 것이 좋다.

1
2
3
4
5
6
7

1. 각 인스턴스가 고유한 경우  ex) Thread와 같이 객체가 값을 표현하는 목적이 아닌 경우

2. 인스턴스가 논리적으로 동일한지 검사할 일이 없는 경우

3. 상위 class에서 재정의한 equals가 하위 클래스에도 적합한 경우 

4. 클래스가 private 이거나, package-private이고, equals method가 호출될 일이 없는 경우