3장 모든 객체의 공통 메서드 (week2)

[minSW]

3장 모든 객체의 공통 메서드

Schedule : 21.05.05 (수) 👶🏻 8PM => 21.05.12 (수) 9PM

목차

• 아이템 10. equals는 일반 규약을 지켜 재정의하라
• 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라
• 아이템 12. toString을 항상 재정의하라
• 아이템 13. clone 재정의는 주의해서 진행하라
• 아이템 14. Comparable을 구현할지 고려하라

[KimYealynn]

• Object : 상속 시 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)를 모두 재정의 해야한다.

아이템 13. clone 재정의는 주의해서 진행하라

• cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스 지만, clone 메서드가 선언된 곳이 cloneable이 아닌 object이고, 그마저도 protected라는 데에 있다. 그래서 cloneable 구현 만으로 외부 객체에서 clone 메서드를 호출 할 수 없다.
• 제대로 동작하는 clone 메서드를 가진 상위 클래스를 상속해 cloneable을 구현하고 싶다면 먼저 super.clone을 호출해야한다.
• try {} catch(CloneNotSupportedException e){} : object의 clone 메서드가 해당 검사예외를 던지도록 선언되어있기 때문 일 뿐 걸리지 않는다. 이 예외가 사실은 비검사(unchecked) 예외였어야 했다는 신호다.
  • 재정의한 public clone 메서드는 throws 절을 없애야한다.(It71)
• 단순히 super.clone만 한다면 가변 객체를 참조하는 순간 원본이나 복제본 중 하나를 수정하면 다른 하나도 수정되어 불변식을 보장하지 못 한다.
  • 가변 객체의 clone을 재귀적/반복자으로 호출해야 한다.
• 복잡한 경우에는 복사 생성자(자신과 같은 클래스의 인스턴스를 인수로 받는 생성자)와 복사 팩터리라는 더 나은 객체 복사 방식을 제공할 수 있다.
  • 언어 모순적이고 위험한 객체 생성 메커니즘(생성자를 쓰지 않는 방식)을 사용하지 않으며 엉성한 규약에 기대지 않고, 정상적인 final 필드 용법과 충돌하지 않으며 불필요한 검사예외를 던지지도 형변환도 필요치 않다.
  • 해당 클래스가 구현한 인터페이스 타입의 인스턴스를 인수로 받을 수 있다. (범용 컬렉션 구현체는 collection, map 타입을 받는 생성자를 제공한다) -> 변환 생성자/팩터리

[minSW]

3장 모든 객체의 공통 메서드

item 10

• 논리적 동치성 (logical equality) vs 객체 식별성 (object identity)
  • equals 재정의가 필요한 순간은 논리적 동치성 을 확인해야할 때
• p.53 Map의 키와 Set의 원소로..
  • equals 로 원소를 확인하기 때문에
• 동치 클래스 (equivalence class; 동치류)
  • 동치 관계 : 집합을 서로 같은 원소들로 이루어진 부분집합으로 나누는 것
  • equals() 는 모든 원소가 같은 동치류에 속한 어떤 원소와도 교환 가능해야함
• 동치 관계 (equivalenz)e relation 만족을 위한 5가지
  • 반사성 (reflexivity) : x.equals(x) = true (x !=null)
  • 대칭성 (symmetry) : if x.equals(y) : y.equals(x) (x, y != null)
  • 추이성 (transitivity) : if x.equals(y) and y.equals(z) : x.equals(z) (x,y,z != null)
  • 일관성 (consistency) : x.equals(y) == x.equals(y) == ... (항상 동일) (x, y != null)
  • Not-Null : x.equals(null) = false (x != null)
• 문제들 ...
  • 대칭성 - "허황된 꿈을 버려라.."
  • 구체 클래스 확장 + 새로운 값 추가 & equals 규약 만족? => "꿈깨라" or OOP 추상화 포기...
• instanceof 사용 vs getClass() 사용
  • instanceof : Type 비교 연산자. 인스턴스의 형태가 포함되어 있으면 true
  • getClass() : 로딩된 클래스의 주소값 반환
  • instanceof 대신 getClass 사용은 제대로 동작하기 어려움 ...
• 리스코프 치환 원칙
  • 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. (SOLID)
• 컬렉션 구현체의 contains() 확인 방법 => 대부분 equals() 사용
• p.59 view 메서드 (아이템 6) 사용
• p.61 결정적 계산만 수행할 것
  • 결정적 (deterministic) 계산 : 예측한 그대로 동작하는 알고리즘 (= pure?)
• float, double은 compare() 사용
  • 부동소수 값등을 다뤄야하므로.. => Float.compare(f1, f2)
  • 나머지 기본 타입 필드는 == 로 비교
  • 참조 타입 필드는 equals() 사용
  • null-able => static Objects.equals(o1, o2)로 NPE 발생예방
• 표준형 (canonical form) : 객체의 표현형을 '고유'하게 나타내는 표준 방식
• 3가지의 자문
  • 대칭적? 추이성? 일관적?
• 긍정 오류 (false positive, 거짓 양성) : 정상적인 접근을 비정상적인 접근이라고 잘못 판단
• 구글의 AutoValue

item 11

• 해시버킷, 해시코드, 해시테이블
  • 이상적인 해시함수 = 다른 인스턴스들은 각각 32비트 정수 범위 내에 균일 분배되게 하는 함수
  • result = 31 * result + c = (result << 5 - result) + c
• objects.hash() 는 속도는 느리지만 간단
• p.71 필드 지연 초기화 시.. 스레드안정성을 어떻게 고려? => (아이템 83)
  • hashCode 필드 초기값은 흔한 객체 해시코드와는 달라야한다
• 해시 생성규칙은 숨겨라 (몰래 바꿔치게..)

item 12

• 디버깅에 유익한 toString()

item 13

• p.79 공변 반환 타이핑 (item 2 참조)
• 검사 예외 vs 비검사 예외
• 재귀호출 MAX => 스택프레임의 스택 오버플로 발생 가능
• Cloneable/clone vs 복사 생성자/팩터리 (= 변환 생성자/팩터리)
  • => 배열빼곤 다 후자가 나음..

item 14

• x.compareTo(y)
  • x < y : -1 (음수)
  • x == y : 0
  • x > y : +1 (양수)
• p.89 compareTo() 규약은 equals 이랑 거의 비슷
  • 대칭성, 추이성, ...
  • 필수는 아니지만 강력권장) (x.compareTo(y) == 0) == (x.equals(y))
• compareTo 는 순서 비교, equals는 동치 확인
• Collection, Set, Map 등의 인터페이스는 비교 시 compareTo 사용
• HashSet vs TreeSet 동작의 차이
  • HashSet : 해싱 사용. 중복 x 순서보장 x (성능 best)
  • TreeSet : BST 사용하고 기본 오름차순 정렬되어 저장. 중복 x 인입순서 x
• 메서드 연쇄는 약간의 성능저하
• comparing() 다중메서드
• p.94 필드 값 비교 시 <, > 는 쓰지말 것
  • 정적 compare 메서드 사용 (ex. Integer.compare(o1.hashCode(), o2.hashCode());)
  • 비교자 생성 메서드 사용 (ex. Comparator.comparingInt(o -> o.hashCode()); )