도메인 로직을 구현하는데 있어 위와 같이 객체 하나씩 독립적으로 살펴 보면서, 메서드들을 정의/구현하는 방식을 사용한다면 즉 객체간의 문멕을 고려하지 않은채 독립적인 객체를 위주로 서비스로직을 작성하다 보면 다음과 같은 문제가 발생할 수 있습니다.
java의 math나 time도 결국 가상으 ㅣ요구사항을 고려하고 만들어집니다. 우리에게는 요구사항과, 도메인 로직이라는 좋은 가이드라인이 있는데도 불구하고, 굳이 눈을 가리고 객체에 일반적인 메서드를 고집할 필요가없습니다.
정보전문가는 특정 요청을 수행 할만한 정보를 가질 수 있는 객체를 뜻합니다.
이 정보를 자신이 직접 가지고 있을 수 도 있고 연쇄적호출로 인한 참조를 가지고 있을 수도 있습니다.
예를 들어 자동차를 생산하기에는 자동차 공장이 적합하다고 생각할수 있겠습니다.
객체간에 문맥을 이해하고 요청하는 것은 요청자가 협력자를 알고 있어야하는 의미를 가지고 있습니다.
그렇다면 어떤 객체에 협력을 요청함에 있어서 누가 협력을 요청할 것인가를 결정할 때는 가급적 낮은 결합도를 가지도록 하는것이 바람직 합니다.
어떠한 책임을 수행하는데 있어서 a는 b에 협력을 요청합니다. 책임을 수행하는데 c의 도움도 필요할때 a와 b중 누가 c에 협력을 요청해야할까?
낮은 결합도를 생각한다면 a이든 b이든 c를 이미 알고있는 객체가 협력하는 것이 바람직 합니다.
높은 응집도는 낮은 결합도와 비슷하게 느껴질 수 있는 기준입니다. 낮은 결합도와 높은응집도는 좋은 설계로가기위해 거처야하는 관문입니다 이 둘중 어떤것을 선택하여 설계하여도 결과는 좋은 설계가 된다는 점입니다.
높은 응집도를 선택하라는 것은 c와 c에 대해 협력 요청을 하는 객체가 가급적이면 변경의 이유가 유사한 것이 낫다는 것을 의미합니다.
객체를 생성할대 누가 해당 객체를 생성할 것인지 고민하느 ㄴ경우가 있습니다. GRASP의 creator pattern에서는 다음과 같은 조건을 만족하는 B에게 책임을 할당하는것이 바람직하다고 합니다.
1. B가 A객체를 초기화하는데 필요한 데이터를 가지고 있다.
2. B가 A객체를 포함하거나 참조한다.
3. B가 A객체를 기록한다.
4. B가 A객체를 긴밀하게 사용한다.
저장소에 캐시가 적용돼 있을때 원하는데이터가 캐시돼 있으면 바로 반환하고 아니면 조회를한다고 하면 서비스입장에선 이 데이터가 캐시가 된것인지 db에 조회를한것인지 알지 못합니다. 사용자입장에선 지칭한 특정요소를 반환한다라는 메서드의 정의만을 생각했지만 저장소는 목표를 달성하면서도 목표달성 방법은 자유롭게 선택했습니다.
1.내부를 고려하지 않아도 되기 때문에 협력이 단순해 지고 이해하기 쉬워집니다.
2. 내부의 변경이 외부에 영향을 미치지 않습니다.