Objects 6장 메세지와 인터페이스

카일·2020년 3월 1일

Objects 오브젝트

목록 보기

6/11

책임에 초점을 맞추는 방식으로 아래의 법칙들을 잘 지킬 수 있다. 어떻게? 객체와 클래스를 생각하는 것이 아닌 메세지를 통해 객체간의 소통을 정의하고 메세지가 객체를 선택하게 함으로써 각 객체는 객체로서가 아니라 메세지를 처리하는 역할을 담당하는 것이고 이는 상호간의 참조를 줄이고 의도를 명확하게 드러나게 해준다.
협력에 적절한 객체가 아니라 협력에 적절한 메세지를 통해 협력에 적절한 객체를 찾는다.
훌륭한 인터페이스의 특징
외부에서 내부구현과 관계없이 본인이 얻고자 하는 정보를 메세지를 통해서 얻을 수만 있으면 된다. 즉 내부구현을 드러내거나 외부에서 내부값을 사용하는 것이 아니라 무엇을 원하는 지에 대해서만 메세지를 보내면 되도록 설계하는 것이 좋은 공용 인터페이스를 의미하는 것이다

RDD를 통해 충분히 추상화되고 일반적인 인터페이스를 얻을 수 있지만 훌륭한 공용인터페이스의 특징을 알고 있는 것은 올바른 설계에 도달할 수 있는 지름길을 제공할 것이다. 이에 훌륭한 공용인터페이스의 특징에 대해 알아보겠다.

외부와의 결합도를 낮추기 위해 특정한 경우 혹은 최소한의 경우에만 외부와 협력하라라는 의미. 즉 같은 객체내에서 도트를 많이 사용하는 것을 제한하는 것이 아니라 외부와의 소통을 위해 도트를 자꾸 사용하는 것을 제한하는 것임. 내부 구조를 드러내지 않기 위해 도트를 제한하는 것이다.
내부구조와 강하게 결합되지 않도록 협력 경로를 제한해라.
- this객체 메서드의 매개변수 this의 속성 this의 속성인 콜렉션의 요소, 메서드 내 생성된 지역객체 이외의 것들과 소통하지말라.
- 소통을 최소화하라. 두개이상의 점은 안된다.
- 결합하고 있는 객체의 수를 줄이고 상호작용중인 객체들끼리만 협력해라.

필요에 따라 물어야 한다.
질문이 답변을 수정해서는 안된다 .
- 프로시저는 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다. : 명령
- 함수는 값을 반환할수 있으나 부수효과를 일으킬 수 없다. : 쿼리
  - 단순히 값만을 반환해주는 것으로 내부의 상태가 변경되지 않는 것이 중요하다.
  - 이를 통해 참조투명성을 얻을 수 있음. 명령에서는 안되지만
명령과 쿼리는 구분되어야 하며 둘의 역할을 함께 사용하는 기능은 제공하지 말아야한다.
- 이유는 ? 장점은?
  - 명령과 쿼리가 한 곳에 있으면 수정이 힘들며 이를 알아보기 힘들다
  - 분리하는 경우 공용 인터페이스가 늘어나는 단점이 있지만 이 단점은 관계를 명확하게 표현해주는 장점에 의해 상쇄된다.
  - 즉 쿼리는 내부 값을 변경하지 않는다는 확신 그리고 명령은 내부의 값을 변경한다는 명확한 기준을 제시함으로써 외부 이용자가 이에 대해 혼란을 겪지 않을 수 있다.
  - 또한 필요에 따라 물어야 한다는 것처럼 필요에 의해 값을 가져와서 처리하는 경우도 존재한다 하지만 이 경우도 확실하게 쿼리에 속하며 내부의 값을 변경하는 것이 아니라 값을 조회해 오는 기능으로 명확하게 분리되기에 내부 값이 변경되지 않는다는 확신을 줄 수 있다.

소프트웨어에 절대적인 법칙이란 존재하지 않는다. 묻지 말고 시켜라와 디미터의 법칙이 유용하게 사용되고 객체지향적인 설계를 이끌어주는 것은 일반적으로 맞지만 항상 옳은 방법을 제시하진 않는다.
결합도와 응집성이 디미터의 법칙에 의해 엇갈리는 경우도 존재하고
자료구조와 관련된 부분에서는 Getter를 사용하지 않고는 계산할 수 없는 경우도 존재한다.
즉 객체지향에서 정답은 존재하지 않으며 상황에 맞게 메세지를 보내는 것일지 상태를 가져와야하는 것일지 결정해야한다.
하지만 확실한 건 메세지를 보내는 것이 일반적인 경우에서는 객체지향에 가까워지는 경우가 많다는 사실과 그럼에도 불구하고 예외는 존재하기 때문에 매순간 Trade Off 에 대해서 고려하는 것이 바람직하다.