출생

1.1 -er로 끝나는 이름을 사용하지 마세요
1.2 생성자 하나를 주 생성자로 만드세요
1.3 생성자에 코드를 넣지 마세요

생각하기

이 책에서는 객체를 he(그) 라고 표현하고 있다. 그 이유는 객체를 사람처럼 다루고 싶어서라고 한다. 음?

그 이유는 1.1 -er로 끝나는 이름을 사용하지 마세요. 에서도 찾아볼 수 있었는데, 이는 좀 더 뒤에서 언급하기로 하자.

우리가 운영하는 서비스의 최종적인 목표는 유지보수성이라고 생각한다. 마찬가지로 이 책의 저자 또한 유지보수성을 향상시키는 것을 목표로 Tips 을 나열했다.

가장 인상깊었던 부분은 1.1 -er로 끝나는 이름을 사용하지 마세요 내용에서 인상깊었던 부분은 -er로 끝나는 validator, Formtter … 등의 이름을 사용하지 말라고 한다. 물론 예외 케이스도 존재하지만, 사용하지 말라고 강하게 단언하는 이유는(이 부분에 읽는 사람으로 하여금 오해할수도 있겠다) 코드로 설명하고 있다.

class CashFormatter {
  
  int money;
  protected CashFormatter(int money){
    this.money = money
  }
  
  public String format(){
    return money + ""
  }
}

이렇게 할 경우, 클래스의 이름은 클래스내에서 동작되는 행위(method)에 의해서 결정되어진다. 저자는 이를 굉장히 경계합니다. 아주 강하게 말하는데, 클래스의 이름은 객체가 노출하고 있는 기능에 기반해서는 안됩니다! 라고 말합니다.

그래서 이런말을 한다.

객체를 살아있는 생명체로 생각한다면 클래스는 객체의 어머니라고 할 수 있습니다. P20

클래스 이름을 짓는 것은 앞서 언급한 유지보수성과 관련이 있다고 생각합니다.

그러면서 아주 핵심을 관통하는 말을 합니다.

클래스의 이름은 무엇을 하는지(What he does)가 아니라 무엇인지(What he is)에 기반해야 합니다.

만약 위의 코드를 수정해야 한다면 아래와 같이 해야된다고 말합니다.

class Cash {
  ...
  public String won(){
    return money + " won"
  }
}

첫번째 클래스와 비교했을 때 두번째 클래스가 달라진 점은 무엇일까? 메소드의 역할이 명확해졌다는 점?

객체는 어떤 사람인지를 나타내는 속성이 아니라, 어떤 일을 할 수 있는지로 설명되어야 한다고 합니다.

아직은 와닿지 않습니다. 조금더 생각해봅시다.

첫번째 클래스보다는 보다 하는 행위를 일켜는 말이 명확해졌습니다.

이렇게 클래스 끝에 -er 이라는 말이 붙는 것은 유지보수성 관점에서 좋지 않다 라고 말하고 있습니다. 마지 -er 로 끝나는 클래스는 그 클래스가 무엇가 연결장치 라는 의미를 이끌어 내고 이는 객체간에 단순히 정보전달의 역할밖에 할 수 없다고 합니다.

저자는 객체는 외부세계와 내부세계를 연결하는 연결장치 가 아니라, 객체는 캡슐화된 데이터의 대표자(representative) 라고 합니다.

그러므로, 클래스는 대표자(representative)가 되어야 하는데, 대표자란 의미는 스스로 결정을 내리고 행동할 수 있는 자립적인 엔티티 이여야 한다는 의미입니다.

여기서 저는 무릅을 탁! 쳤습니다. 사실 -er 을 무시할 수는 없습니다. 대표적인 것으로 xxcontroller, xxxfilter 이런 클래스들을 보면 무엇을 하는지 와닿기 힘듭니다. (그 이유는 controller 안에서 무엇가 명확히 하나의 일을 하는 것이 아니라, 이것저것 하기 때문이겠죠) 저자는 이 생각을 캐치해 말한 것 같습니다.

그 외에 1.2 생성자 하나를 주 생성자로 만드세요 / 1.3 생성자에 코드를 넣지 마세요 에서도 좋은 내용이 많았는데, 이것 하나만 기억하면 될 것 같습니다. 어떻게 하면 유지보수성을 향상시킬수 있을까?

생성자 하나를 주생성자로 만들지 않았다면? 생성자에 코드를 넣었다면? 이렇게 생각해보면 왜 저자는 이런말을 했는지 단번에 알아차릴수 있을 것같습니다.