3.1 5개 이하의 public 메서드만 노출하세요

객체를 가능한 작고 응집력 있게 유지해야 유지보수와 테스트에 유익하다는점에 동의합니다.

3.2 정적 메서드를 사용하지 마세요

3.2.1 객체 대 컴퓨터 사고

• 절차지향 프로그래밍 : 위에서 아래로 로직이 수행되며 직접 명령(요청)을 내린다.
• 선언형 프로그래밍 : 정의(is-a) 를 하고 제어를 위임한다.
  • 정적 메서드는 클래스를 정의하여 제어를 할 수 없이 절차지향적인 코드의 요청에 의한 수행이므로 OOP 와 연관성이 없다

3.2.2 선언형 스타일 대 명령형 스타일

1. 성능
   정의(is-a) 를 한 후 어느 시점에 그 값을 할당할지 혹은 계산할지 제어 할 수 있으므로 더 빠르다. 집중해야 되는 부분은 빠른게 아닌 유지보수와 제어관점에서의 이점이라고 생각한다.

2. 다형성
   일급 객체를 사용할 수 있고 생성자의 인자로 객체를 전달한다는 부분에서 다형성을 누릴 수 있다.

3. 표현력
   새로운 클래스를 만들면서 네이밍을 통해 행동을 알 수 있다 세부사항을 알지 않아도 된다. 하지만 절차지향은 처음부터 끝까지 다 읽어야만 알 수 있다. 이런부분에서 표현력의 이점을 이야기 한 거 같다.

4. 응집력
   책임을 가지고 그 책임을 수행하기 위한 코드가 모여 있다.

결론
순수한 OOP 관점에서 타당해 보인다. Math.max 처럼 변하지 않는 당연한 로직이라 생각하고 정적 메서드를 사용하지만, 원리와 이론이 아닌 실제 비즈니스와 관련된 로직이라면 변경가능성과 이에 따른 유지보수까지 고려해야 될 것이다. 결론적으로 정적 메서드 사용을 지양할 뿐 상황에 맞게 활용하는것은 가능하다고 본다.

3.2.3 유틸리티 클래스

위 결론과 이어진다.

3.2.4 싱글톤 패턴

굉장히 흥미로운 관점으로 싱글톤을 바라본다. 바로 setInstance 를 통해 mock 객체를 생성하는 다형성을 고려한것이다. 근데 뒤에서 setter 쓰지 말라고 하면서 여기서 set 을 통한 다형성을 언급하는 것 자체가 모순인거 같다. 즉 흥미로운 관점이나 실제 실무에서 활용 가능성은 없을 것 같다. 그래서인지 저자는 마지막에 static 을 쓰는싱글톤 또한 사용하지 말라고 주장한다.

3.2.5 함수형 프로그래밍

저자는 함수형 프로그래밍도 OOP 관점에서 좋게 보지 않는다(람다). 하지만 불필요한 코드를 줄이고, 가독성을 높은 람다는 표현력이 약하다는 절차 지향과는 다르며 람다를 메서드와 클래스로 감싼다면 충분히 재활용도 가능하기에 저자의 관점은 온고지신의 마음에서 온고에서만 머무는 꼰대라는 결론에 도달하였다.

3.2.6 조합 가능한 데코레이터

아도겐 코드이지만 저자의 생각의 빌드업을 따라오다보면 어떤 주장을 하고 싶은지 이해는 된다. 선언만으로도 충분한 표현력을 지닌다고 생각한다. 추가로 뒤쪽에 if 를 클래스로 활용하는 부분은 대단히 흥미롭게 참신한 관점이라 생각의 즐거움을 가져다 주었다.

3.3 NULL 을 절대 허용하지 마세요

null 은 절차지향의 유산이며 null 여부 체크 자체가 상대방에 대한 확인을 상대방이 아닌 내가 하는 것이므로 이미 그자체에서 객체의 자율성을 해친다. 2가지 방법을 제시하지만 이미 Optional 이 나왔다. 저자는 Optional 보다는 null 그 자체를 사용하지 말라고 말하고 싶은 거 같다. 기본적으로 null 사용을 피하되 불가피한 경우 Optional 을 사용하자

3.4 충성스러우면서 불변이거나, 아니면 상수이거나

상태가 불변이면 당연히 불변 객체이다. 식별자가 없어도 된다고 한다. 불변과 상수의 차이에 대해 소개하는데 머리에 잘 안들어온다. 책읽기 후 내용을 추가할려고 한다.