Ch.4 역할, 책임, 협력

Ch.4 역할, 책임, 협력

객체가 가져야 할 행동 혹은 상태를 먼저 생각하지 말자.
객체간의 협력이 우선이다.

즉, 책임을 어떻게 구현할 것인가? (no)
객체간의 협력에서 올바른 객체가 책임을 가져야 한다.

---

객체의 책임 분류

하는것(doing)

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

아는것(knowing)

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

아는것의 경우
    책에서의 재판의 관한 예를 보았지만
    프로그래밍 내의 예시를 생각하여 이해하기는 힘들었다.

---

역할

역할을 대체할 수 있는 객체란, 동일한 메세지를 이해할 수 있는 객체

역할의 개념을 사용한다면

1. 다양한 객체들이 협력에 참여할 수 있어 협력에 유연
2. 다양한 객체들이 동일한 협력에 참여할 수 있기에 재사용성이 높아진다.
3. 하나의 협력안에 여러 종류의 객체가 참여함으로써 협력을 추상화 할 수 있다.

---

대체가능성

본질적인 역할은 다른 객체에 의해 대체가능하다.
-> 유연성 + 확장성

객체가 역할에 주어진 책임 이외에 다른 책임을 수행할 수도 있다.
=> "하나의 객체가 CRUD의 역할을 갖고 있는 것이 되는걸까?"

---

객체지향의 흔한 오류

1. 데이터를 저장하기 위해 객체가 존재한다?

   • 상태의 일부로 데이터를 포함하지만,
     데이터는 객체가 행위를 수행하는데 필요한 재료!

2. 클래스와 클래스간의 정적인 관계만을 표현하는가?

   • 협력에 참여하는 동적인 객체이다.

---

객체지향 설계기법

책임-주도 설계

1. 올바른 책임을 올바른 객체에 할당하는것
2. 시스템의 책임을 객체의 책임으로 변환(스프링의 IOC가 예가 될수 있지 않을까 싶다.)
   

디자인 패턴

1. 반복적인 문제와 그 문제의 해법의 쌍으로 정의
2. 특정상황에 적용가능한 디자인 패턴을 안다면
   책임-주도 설계를 따르지 않고 시스템 안에 구현할 객체들을 손쉽게 작성할 수 있다.
   

테스트 주도 개발

1. 객체가 존재한다 가정 후 어떤 메세지를 전송할지 생각
2. 단순히 테스트를 작성하는 것이 아니다.
3. 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메세지를 수신할 때,
   어떤 결과를 반환하는지 어떤 객체와 협력할지 작성

---

느낀점

• "객체지향의 흔한 오류"의 경우 부끄럽게도 제가 계속 헷갈리는 부분을 잘 잡아준 것 같습니다.
• 객체의 역할, 책임, 협력을 설계기법과 잘 생각하여 도메인 설계를 해봐야겠다. 라고 느꼈습니다.
• 스프링부트의 경우 자주 사용하는 디자인패턴을 어노테이션으로 처리하거나 그 구조를 편하게 만들었다고 예전에 공부하며 적용했던 부분이 생각났습니다.

---

의견을 나눌 점

아직 TDD 의 경험 + 객체지향적 설계가 완벽하지 않아
어떤 점에서 TDD가 더욱 고차원적인 객체지향적 설계를 나타낼 수 있는지 궁금하네요.