[독서] 엘레강트 오브젝트 3장. 취업(2)

wally·2022년 6월 21일
0

독서시리즈

목록 보기
5/10

3.5 절대 getter setter 를 사용하지 마세요

저자는 상태를 가지는 class 를 get set 을 통해 상태를 노출시키는 가변객체를 진짜 클래스가 아닌 단순한 자료구조로 바라본다

3.5.1 객체 대 자료구조

객체와 자료구조의 차이는 무엇인가?
객체는 객체 사이에 메세지를 주고 받고 자신의 상태를 캡슐화 한다.(불투명박스)
하지만 자료구조는 어떠한 소통 없이 직접 멤버에 접근을 한다.

객체지향적이고 선언형 스타일을 생각한다면 자신의 상태(필드) 에 직접 접근을 허락하지 않는 캡슐화가 필수적이고 메세지를 주고 받음으로써 책임있는 자율적 객체를 만드는것이 OOP의 지향점이다. 이를 생각하면 getter setter 를 통해 상태를 노출시켜 자신의 필드의 판단을 다른 객체에 위임하는 형태는 대단히 위험하다

3.5.2 좋은 의도, 나쁜 결과

getter, setter 는 결국 부가적인 로직이 있어도 자신의 필드에 직접적으로 접근을 허용하기 때문에 대단히 무례한 행동이다

3.5.3 접두사에 관한 모든 것

  • 저자는 빌더이므로 getDollar 가 아닌 Dollar 를 메서드 이름으로 쓰라고 한다.

    메서드 이름도 중요하다. 결국 get 보다는 요청받은 메세지를 자체적으로 처리한후 판단하여 최소한의 가시성을 가지고 반환을 하는 것이 중요하다. 네이밍에 대해서 항상 고민하자

3.6 부 ctor 밖에서는 new 를 사용하지 마세요

클래스 내부에서 new Cash 를 사용하여 객체를 생성한다면 하드 코딩으로 작성된 Cash 와 강한 결합도를 가지게 된다. 따라서 인터페이스를 통해 다형성을 바꿔끼우듯이 new 가 아닌 주 ctor 에서 인자로 객체를 받음으로써 느슨한 결합도를 가지게 하는 것이 중요하다.

  Cash(){ // 부생성자
    this(0;
  }
  Cash(int value){ // 부생성자
    this(value, new NYSE());
  }
  Cash(int, value, Exchange exch){ // 주생성자
    this.dollar = value;
    this.exchange = exch;
  }

부 생성자에 new 를 통해 주 생성자로 인자를 받지 않는 경우 기본적으로 설정되어있는 객체를 할당하여 의존성을 주입하는 방법은 대단히 흥미로웠다. 절대적인 규칙은 아니더라도 코드 작성에 가이드로 사용하기에 좋은 거 같다.

3.7 인트로스펙션과 캐스팅을 피하세요

자바의 instanceof , Class.cast() 메서드 등의 기능들은 런타임에 객체의 타입을 확인할 수 있다.

  • 가장 좋은 error 는 컴파일에러이다. 런타임에서 확인되고 나오는 에러는 개발자에게 좋은 코드가 아니다.
  • 따라서 런타임에 다른 코드에 의해 수정된다는 사실을 항상 기억해야 하기에 유지보수도 좋지 않고 내부 코드를 전부 훑어보게 만든다.
  • 또한 객체를 차별하기에(특정 타입에만 해당) 객체를 자율적으로 보는 관점에서도 바람직한 방식은 아니다
// 계약서에는 iterable 을 요청한다고 명시한다.
public <T> int size(Iterable<T> items){ 
// 근데 여기서 또 Collection 타입을 요청하네? 부실한 계약서다!!
  if(items instanceof Collection){ 
  return Collection.class.cast(items).size();

객체는 메세지를 통해 소통한다. 메세지를 주고 받는데 메세지 내부에 추가적인 제한사항이 걸려있다면 내부구현을 보르는 요청자는 당황스러울 것이다. 결국 내부구현에 대해서도 일부 노출을 시키거나 그럴거면 애초에 이러한 방식이 아닌 메세지 외부에서 처리하는 방식을 처리하는 것이 바람직할 것이다. 이를 저자는 내부에 결합도가 숨겨져 있다(내부 추가적인 제한사항)라고 바라본다.

저자는 이를, 방문 객체에 대한 기대를 문서에 명시적으로 기록하지 않은채 외부에 노출해버린 것이며 클라이언트와 객체사이의 불명확하고 은폐되고 암시적인 관계로 유지보수성에 좋지 않다고 한다.

덜적힌 계약서를 제시하면서 계약을 성공했지만 정작 추가적인 계약조건들을 이야기하는 거와 비슷하다. 객체간의 신뢰가 깨질것이다.

profile
클린코드 지향

0개의 댓글