객체를 객체답게 사용하기 위해서는 “책임, 역할, 협력”이 중요하다고 했습니다.
사실 이게 뭔데? 라는 생각과 함께 내가 평소에 알고 있는 의미와 다를 것 같다는 생각에 한번 정리해 보았습니다,
협력: 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용
책임: 객체가 협력에 참여하기 위해 수행하는 로직
역할: 객체들이 협력 안에서 수행하는 책임들의 집합
즉, 책임이 모여 역할이 되는 것이고, 그러한 역할들을 통해 서로 다른 객체와 협력하여 어플리케이션의 기능을 구현하는 것입니다.
자율적인 객체란 자신의 상태를 직접 관리하고 결정에 따라 행동하는 객체입니다. 객체의 자율성을 보장하기 위해서는 필요한 정보와 그에 따른 행동을 같은 객체 안에 모아놔야 합니다. 즉 캡슐화
하는 것입니다.
그리고 자신이 할 수 없는 일을 다른 객체에 위임을 하며객체들의 전체적인 자율성을 향상킬 수 있습니다.
어플리케이션에서 객체가 필요하다면 그 이유는 협력에 참여한 객체이기 때문입니다. 그리고 그 객체에는 협력에 필요한 행동(책임)을 갖고 있기 때문에 협력을 잘 본다면 설계를 위한 문맥을 볼 수 있습니다.
책임이란 객체에 의해 정의된 응집도 있는 행위의 집합으로, 객체가 수행할 수 있는 행동을 서술한 문장입니다. 객체의 책임은 객체가 “무엇을 알고 있는지”와 “무엇을 할 수 있는지”로 구성이 됩니다.
책임의 관점에서 보면 “아는 것” 과 “하는 것”은 밀접하게 연관되어 있습니다. 객체에 적절한 책임을 할당하는 것이 설계의 완성도를 높일 수 있습니다.
협력을 설계하면서 적절한 책임을 할당하고, 그에 맞는 정보를 얻고, 협력을 하면서 남은 결과물로 시스템을 구성하는 객체들의 인터페이스를 얻을 수 있습니다.
객체를 객체답게 만드는 것은 객체의 상태가 아니라 객체가 다른 객체에게 제공하는 행동입니다.
객체의 목적은 협력 사이에서 맡게되는 역할로 알 수 있습니다. 역할이 중요한 이유는 이를 통해 유연하고 재사용이 가능한 협력을 생성할 수 있기 때문입니다.
역할은 특정한 객체의 종류를 캡슐화
하기 때문에 동일한 역할을 수행 합니다.
위와 같이 적절한 비용 안에서 쉽게 변경이 가능한 객체 설계는 응집도가 높고, 느슨한 연결로 결합되어 있는 요소로 구성되어 있습니다.
설계가 필요한 이유는 요구사항이 변화하기 때문이고, 캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제할 수 있기 때문입니다.
여기서 “높다” “낮다” 등의 표현이 너무 모호합니다. 정답은 없지만 측정할 수 있는 몇 가지 요소는 존재합니다.
캡슐화가 내부 구현을 그대로 노출하는 경우 → 클라이언트가 구현에 강하게 결합된다는 것을 의미합니다.
하나의 요구 사항 변경을 반영하기 위해 동시에 여러 모듈을 수정해야 하는 경우 → 다른 모듈에 의지해야 할 책임의 일부가 엉뚱한 곳에 위치해있기 때문입니다.
https://incheol-jung.gitbook.io/docs/study/object/2020-03-10-object-chap4