221116 TIL 협력을 설계하자

오늘은 이전에 설계했던 객체가 잘못되었다는 것을 인지하고 객체지향의 사실과 오해를 참고해서 객체를 재설계해봤다.

객사오에서는 객체지향 설계의 첫 번째 목표를 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이라고 강조하고 있었다.

협력을 설계한다는 것은 객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택해야 한다는 것을 의미하기 때문에 메시지를 먼저 선택 후 메시지를 수신하기에 적절한 객체를 선택해야 한다고 한다. 솔직히 글만 봐서는 잘 와닿지 않았었다.

그래서 직접 내 프로젝트에 적용해봤다. 현재 게시판에서 설계하려는 협력은 게시글을 작성하는 것인데 메시지로 작성한다면 "게시글을 작성하라"이다.

객사오에서 나오는 방법처럼 화살표를 이용해서 설계해봤다.

"게시글을 작성하라" 메시지 위에 붙은 작은 화살표는 메시지에 담아 전달될 부가적인 정보를 말하고 이 메시지는 나중에 게시글 제목, 내용을 작성하라와 같이 부가적인 정보를 포함하는 형식으로 구현이 된다. 

 

이제 이 메시지를 처리하기에 적합한 객체를 선택해야 한다. 

객사오에서는 메시지를 처리할 객체를 찾을 때 도메인 모델 안에 책임을 수행하기 위해 적절한 타입이 존재하는지 먼저 찾아본다.

그러면 "게시글을 작성하라"라는 메시지를 수신하기에 가장 적절한 객체는 무엇일까? 가장 먼저 떠오르는 건 게시글을 작성할 사용자가 떠오른다. 따라서 메시지를 처리할 객체는 사용자이고 이제 사용자 객체는 게시글을 작성할 책임을 위임받았다.

사용자라는 객체가 할당받은 책임을 수행하는 도중에 스스로 할 수 없는 일이 있다면 다른 객체에게 요청해야 하는데 이 요청이 사용자 객체에서 외부로 전송되는 메시지를 정의한다.

사용자는 게시글의 카테고리 이름에 대해서 알지 못하기 때문에 카테고리 항목들을 누군가가 제공해 줄 것을 요청해야 한다.

여기서 "카테고리 항목을 찾아라"라는 메시지가 등장한다.

사용자에게 향하는 화살표는 "카테고리 항목을 찾아라" 메시지를 수신한 객체가 사용자에게 어떤 것을 응답해야 하는지 나타낸다.

즉 "카테고리 항목을 찾아라"라는 메시지를 수신한 객체는 "카테고리 이름"에 대응되는 "카테고리 항목"을 반환해야 한다.

카테고리 항목을 찾을 책임은 어떤 객체가 수신하는 게 가장 적절할지 생각해보면 카테고리를 항목을 포함하고 있는 카테고리 객체가 처리하는 게 알맞다.

객사오에서는 이 부분을 설명할 때 현실과 객체지향의 세계와 비교하는데 카테고리는 자기 스스로 카테고리 항목을 찾을 수 없어 사용자에게 의해 선택되는 수동적인 존재이지만 객체지향의 세계에서는 수동적인 카테고리라는 개념은 유효하지 않다고 설명한다.

객체지향 세계에서는 모든 객체가 능동적이고 자율적인 존재임을 인지해야 한다.

 

 

이제 사용자는 게시글을 작성하기 위해 필요한 정보들을 알고 있다. 게시글을 작성하기 위한 게시글의 제목이나 내용은 사용자의 머릿속에 있기 때문에 게시글 작성을 위한 협력은 사용자가 새로운 게시글을 만드는 것으로 끝이 난다.

 

아직은 일부만 설계했지만 위와 같은 방법으로 객체를 설계하는 관점이 아닌 협력을 설계하는 관점으로 다가가 기존에 잘못 설계했던 객체들을 고쳐나가자.