💭 TMI

프론트엔드를 공부하면서 컴포넌트의 역할, 컴포넌트 분리에 대한 고민을 많이 했었는데, 미션을 진행하면서 객체에 대한 고민이 부족하다는 것을 느꼈다. 해당 객체가 이 역할을 하는게 합리적인지, 얼마나 역할을 분리시켜야 하는지 등에 대한 기준이 혼란스러웠다.

정답이 없다고 하지만 UI 로직과 도메인 로직 분리 라는 관심사의 분리는 모든 분야에 통용된다고 생각한다. 그런 의미에서 객체의 역할, 책임에 대한 기준을 세우고 싶어 이 책을 읽게 되었다. 그리고 지금처럼 구조, 설계 측면에서 고민할 때 읽는 게 적합하다고 생각하여 책을 펼쳤다.

chapter 5까지 읽었고 읽은 부분에 대해 정리하면서 읽었는데 너무 길어서, 중요하다고 생각하는 부분과 다시 생각해볼 부분만 발췌하여 작성하였다.

📘 객체 지향 설계 관점

[ 선입견 ]
상태를 중심으로 객체를 바라보는 경우가 많다
객체가 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동 결정하려고 한다
⇒ 설계에 나쁜 영향 을 끼침

1. 상태를 먼저 결정할 경우 캡슐화 저해
   • 상태에 초점을 맞출 경우 상태가 공용 인터페이스에 그대로 노출될 확률 높음
2. 객체를 협력자가 아닌 고립된 섬으로 만듦
   • 객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서임
   • 상태를 먼저 고려할 경우 협력에 적합하지 못한 객체를 창조하게 됨
3. 객체의 재사용성 저하
   • 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어려움

[ 객체 지향 ]
객체지향 세계는 현실 세계의 단순한 모방이 아니므로, 현실의 객체보다 더 많은 일을 할 수 있음
협력을 위해 특정한 역할을 맡고 역할에 적합한 책임을 수행
객체는 다른 객체가 무엇을 수행하는지는 알 수 있지만, 어떻게 수행하는지에 대해서는 알 수 없음

• 객체가 적합한지를 결정하는 것은 그 객체의 행동
• 협력 안에서 객체의 행동은 객체가 협력에 참여하면서 완수해야 하는 책임 을 의미한다.
• 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다.
• 협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체 생성
  ⇒ 책임 주도 설계(Responsibility-Driven Design)

• 메시지를 주고받는 객체의 관점 으로 사고의 중심을 전환
  - 어떤 객체들이 어떤 메시지를 주고받으며 협력하는가
  - 메시지를 주고받는 객체들의 동적인 관계

📘 객체를 결정하는 기준

적절한 객체에게 적절한 책임을 할당하는 것 에서 객체 지향 설계 시작

[ 객체는 충분히 협력적이어야 하며, 자율적이어야 한다 ]

• 어떻게 응답할지 객체 스스로 판단 하고 결정
• 요청에 응할지에 대한 여부 도 스스로 결정

[ 행동 을 기준으로 객체 결정 ]

• 행동(메서드)을 결정하고 행동에 필요한 상태(필드값) 정의
• 상태를 먼저 고려할 경우 객체의 캡슐화를 저해하고, 클래스를 서로 강하게 결합시킴
• 행동의 결과는 상태에 의존적이며, 상태를 이용해 서술 가능
• 행동의 순서가 결과에 영향

[ 객체의 행동은 두 가지 관점의 부수효과를 명확하게 서술해야 한다 ]

• 객체 자신의 상태 변경
• 행동 내에서 협력하는 다른 객체에 대한 메시지 전송

📘 메시지

다른 객체에게 요청하는 것을 메시지를 전송한다 라고 표현
메시지가 수신자의 책임 결정

• 서비스를 제공하는 객체에게 도움을 요청하며, 요청은 연쇄적으로 발생
• 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의
• 어떤 메시지가 필요한지 결정 → 메시지를 수신하기에 적합한 객체 선택 → 메시지가 수신자의 책임 결정

📘 책임의 자율성이 협력의 품질을 결정한다

• 자율적인 책임은 협력을 단순하게 만든다.
• 자율적인 책임은 객체의 외부와 내부를 명확하게 분리한다.
• 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
• 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
• 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.