[elegant] ch03 (정리중)

5 개 이하의 public 메소드만 노출하세요 → 작은 객체를 만드세요

작은 객체를 만들 수록 유지보수에 좋다는 의견에는 동의한다.

작은 크기의 객체를 만들 수록, 응집도가 높은 객체를 만들 “확률"이 높아지기 때문이다.

하지만 그 “크기" 에 대해서는 약간 의문스럽다. 책의 저자는 항상 단정지어 “이렇게만 만들어!!!” 라고 하는데 그 내용을 추상화 시켜서 딱 “ 작은 크기의 객체를 만들어 유지보수성을 높이자" 정도로만 생각하면 좋을 듯 하다.

그리고 여기서 는 “public 메소드의 개수를 제한" 하고 있는데, 실질적으로 객체 사이에 메시지를 주고 받을 때의 메시지가 “퍼블릭 메소드" 이기 때문이다. 이는 해당 “객체가 제공하는 기능" 에도 해당된다고 생각한다.

만약 그 개수가 너무 많다면, 너무 많은 기능을 제공중인, SRP 가 제대로 지켜지지 않고 있는 객체임을 의심해 볼 수 있지 않을까 생각한다.

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

예.. 정적 메소드가 순수 악 이라는 얘기를하고 있다.

정적 메소드 대신 “객체"를 사용하세요

라는 이야기를 하고 있다.

보통 “정적인 무언가(static method, static field(멤버변수) ..유틸리티 클래스 ) “ 를 만드는 것을 고려하는 상황들로는

• 클래스 로딩 시점에 한 번만 초기화 시켜두고, 그 이후 부터는 새로운 것을 생성할 필요가 없다고 판단되는 경우 들에는, 정적으로 만들어 두는 것이 속도나 성능 면에서 좋다고 생각되었기 때문이다.
  • 매 번 생성하여 GC 로 인한 성능 저하도 줄어들지 않을까?

책에서는 이게 “장점"인 것 같지만 실제로는 “유지보수를 어렵게 만든다" 라고 말한다.

근데 이유가..어디있지??? 🙄  —> 뒤의 챕터에서 이런 얘기를 한다 : “OOP 에서 정적 메소드를 사용한다는 것" 은 “절차적인 코드를 작성" 하도록 부추기는 것이다.

int x = Math.max(5,9);

객체지향 패러다임에서는 “객체간에 상호작용 하는 과정에서, 어떤 연산이 그 때서야 발현되어야" 하는데, 정적 메소드를 호출하는 경우는 “바로 발현"되어 절차 지향적인 코드를 작성하게 된다는 말이다.

이에 대해서 어느정도 공감이 된다.. 그런데 참 고민되는 부분인 것 같다.

그렇다고 자주 사용되는 공통 메소드들을 사용하고 싶다고 매 번 객체를 생성하는게 맞는건가?? 이런 고민을 하게 되는 것은 이미 내가 정적 메소드나 유틸리티 클래스에 익숙해져 있기 때문일까?

아니면 사용하고자 하는 유틸리티 클래스에 대한 퍼시드 객체 같은 것을 따로 만들어주거나 해 보는게 좋을까??

절차지향

순차적인 사고방식?

• CPU 가 코드를 처리하는 방식
  • 순차적으로 실행.
• 로우레벨의 언어들
  • CPU 에게 “수행해야할 작업" 을 직접 “지시” 할 수 있다

순차적인 사고방식의 단점?

• 순차적인 방식은 “CPU 한테 이 작업들을 이런 순서대로 해 “ 라고 “지시" 하는 것이다
• 명령의 실행 흐름을 제어할 책임 이 나에게 있다.
  • 순차적으로 실행되는 절차들을 내가 다 알아야 한다…

사실 여기까지 봤을 때 뭔 소리야??? 싶었는데

객체지향 프로그래밍에서

• 우리는 “할 일” 을 “정의" 하게 된다.
• 그리고, “객체들 이 필요할 때 스스로 상호작용" 할 뿐이다.

Number x = new Max(5,9);

→ x is “ maximum number between two numbers 5 and 9” 이라고 정의하는 것이다.

실제로 x 를 정의할 때 “max 값이 누군지 연산하는 작업이 수행되는가??” → 아니다. “정의"만 해 두는 것이다! 는 말이 많이 와닿았다.