오브젝트

캡슐화

Tell, Dont' Ask

데이터와 행동을 하나의 객체로 엮어 시스템의 기본 동작들을 연결하여 동작하게 만드는 것
정보의 은닉성을 유지하며 객체를 설계하는 것이 견고한 시스템을 구성하는데 도움이 된다

출처 : MartinFlwler Tell Don't Ask

즉 Equeal(x) 보단 message로 불리는 형태를 지향
하지만 원칙이 아닌 법칙 끝까지 읽어보면 다음과 같이 이야기 한다

For me, tell-don't-ask is a stepping stone towards co-locating behavior and data, 
but I don't find it a point worth highlighting.

오브젝트 6장 메시지와 인터페이스

디미터 법칙은 객체의 내부 구조를 묻는 메시지가 아니라
수신자에게 무언가를 시키는 메시지가 더 좋은 메시지라고 속삭인다.

객체의 내부 구조를 묻지 말고, 무언가를 시켜라.
이처럼 협력하는 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 원칙이 바로 디미터 법칙(Law of Demeter)이다. 

디미터 법칙은 객체가 자기 자신을 책임지는 자율적인 존재여야 한다는 사실을 강조한다. 
정보를 처리하는 데 필요한 책임을 정보를 알고 있는 객체에게 할당하기 때문에 응집도가 높은 객체가 만들어진다.

하지만 무비판적으로 디미터 법칙을 수용하면 퍼블릭 인터페이스 관점에서 객체의 응집도가 낮아질 수도 있다. 
자세한 내용은 이번 장에 포함된 "원칙의 함정" 절을 읽어보기 바란다.

디미터 법칙은 객체의 내부 구조를 묻는 메시지가 아니라 수신자에게 무언가를 시키는 메시지가 더 좋은 메시지라고 속삭인다.

가볍게 속삭여 보자.

원칙은 아니다. 트레이드 오프가 필요하면 하자
물어보자. 과연 이것이 객체의 책임인가?

잘 만들어진(단단한) 클래스 그 다음은 메시지를 고민해보자

애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다

협력과 메시지의 관계에 대해 항상 기억하자.
결국 클래스를 표현하는 것은 메세지, 그중에서도 퍼블릭 인터페이스를 고민하자
객체가 의사 소통을 위해 외부에 공개하는 메시지 집합을 퍼블릭 인터페이스라고 한다

• 메시지 : 객체들이 협력하기 위한 의사 소통 수단
• 메세지는 오퍼레이션 명(operation)과 인자(arg)로 구성된다
• 이를 누군가에게 전송하려 할때 수신자가 필요하다.
  * 우린 모두 능동적인 생명체

  condition.isSatisfiedBy(Arg)
  수신자(who).연산자(operation).인자(arg)

그렇다면 이런 객체 지향은 왜 필요한 것일까? 결국 인지과부하를 방지하기 위함이다

오브젝트 7장 객체 분해

단기 기억과 장기기억
문제해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력이 급격히 떨어지는것

인지 과부하(cognitive overload) 발생
-> 단기기억안에 보관할 정보의 양을 조절하기위해

불필요한 정보를 제거, 현재 문제 해결에 필요한 핵심 정보만 남기는 작업(추상화)

큰 문제를 한번에 해결 가능한 작은 단위로 나누는 작업 분해(decomposition)
추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있음.

복잡성의 문제를 추상화와 분해로 해결 

내가 알아야 할 정보의 양을 줄여주는 것 만으로도 머릿속의 저장공간을 좀더 잘 쓸 수 있다

결국은 머릿속의 복잡도를 줄이기 위한 역할인데 때때로 나자신도 모르는 코드가 나오기도 한다
망치를 쥐어주면 못질을 하려 하지