[객체지향의 사실과 오해 | 조영호]04장: 역할, 책임, 협력

04 / 역할, 책임, 협력

객체지향 설계 정리

객체와 협력

• 객체가 가져야 할 행동이나 상태를 먼저 고민하지 않는다.
• 중요한 것은 객체 간의 협력이며, 올바른 객체가 책임을 가져야 한다.

---

객체의 책임 분류

1. 하는 것 (Doing)

• 객체를 생성하거나 계산하는 등 스스로 하는 것
• 다른 객체의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하거나 조절하는 것

2. 아는 것 (Knowing)

• 자신의 개인적인 정보에 대해 아는 것
• 관련된 다른 객체에 대해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 대해 아는 것

데이터는 객체가 행위를 수행하는 데 필요한 재료일 뿐, 객체가 존재하는 목적이 아니다.

---

역할(Role)

• 역할을 대체할 수 있는 객체란 동일한 메시지를 이해할 수 있는 객체를 의미한다.
• 역할 개념의 장점:
  • 다양한 객체들이 협력에 참여할 수 있어 유연하다.
  • 동일한 협력에 다양한 객체가 참여할 수 있어 재사용성이 높다.
  • 하나의 협력 안에 여러 종류의 객체가 참여하므로 협력을 추상화할 수 있다.

대체 가능성

• 본질적인 역할은 다른 객체에 의해 대체 가능하다 → 유연성 + 확장성
• 객체는 역할에 주어진 책임 이외의 다른 책임도 수행할 수 있다.

---

객체지향의 흔한 오류

• "데이터를 저장하기 위해 객체가 존재한다" → 잘못된 생각
• 객체는 협력에 참여하는 동적인 존재이다.
• 상태(데이터)는 일부 포함하지만, 이는 단지 행위를 위한 재료일 뿐이다.
• 클래스 간 정적 관계만이 아니라, 객체 간 동적 협력을 표현해야 한다.

---

객체지향 설계 기법

책임-주도 설계 (Responsibility-Driven Design)

• 올바른 책임을 올바른 객체에 할당하는 것
• 시스템의 책임을 객체의 책임으로 변환
• 예: 스프링의 IoC(Inversion of Control)

디자인 패턴 (Design Pattern)

• 반복적인 문제와 그 문제의 해법을 쌍으로 정의한 것
• 특정 상황에 적용 가능한 패턴을 알면, 객체의 책임을 쉽게 할당할 수 있다.

테스트 주도 개발 (Test-Driven Development)

• 객체가 존재한다고 가정하고, 어떤 메시지를 주고받을지를 먼저 고민한다.
• 단순히 테스트 코드를 작성하는 것이 아니라,
  • 어떤 객체가 책임을 수행할지,
  • 어떤 결과를 반환할지,
  • 어떤 객체와 협력할지를 명확히 하는 과정이다.