3장 정리
객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다.
객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이며,
객체 지향의 핵심은 협력을 구성하기 위한 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다.
애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고, 협력을 위해 어떤 역할과 책임이 필요한지를 고민하지 않은 채
너무 이른 시기에 구현에 초점을 맞추는것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다.
협력 - 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용
메시지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다.
메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다.
외부의 객체는 오직 메시지만 전송할 뿐, 메시지를 어떻게 처리할지는 메시지를 수신한 객체가 직접 결정한다.
즉, 객체가 자신의 일을 스스로 처리할 수 있는 자율적인 존재라는 의미이다.
자율적인 객체는 자신에게 할당된 책임을 수행 -> 외부의 도움이 필요한 경우 적절한 객체에게 메시지 전송
메시지를 수신한 객체도 자신에게 할당된 책임을 수행 -> 도움이 필요한 경우 적절한 객체에게 메시지 전송
이러한 객체들 사이의 협력을 구성하는 일련의 요청과 응답의 흐름을 통해 애플리 케이션의 기능이 구현된다.
협력이 설계를 위한 문맥을 결정한다.
협력은 객체의 행동을 결정하고, 행동은 객체의 상태를 결정한다.
- 협력이라는 문맥 속에서 객체가 처리할 메시지에 따라 행동이 결정된다.
- 행동할때 필요한 정보가 무엇인지에 따라 객체의 상태가 결정된다.
책임 - 객체가 협력에 참여하기 위해 수행하는 로직
객체의 책임은 '무엇을 알고 있는가' 와 '무엇을 할 수 있는가' 로 구성된다.
적절한 협력이 적절한 책임을 제공하고, 적절한 책임을 적절한 객체에 할당해야 단순하고 유연한 설계가 가능하다.
책임 할당 시 고려해야하는 두 가지 요소
1. 메시지가 객체를 결정한다.
- 필요한 메시지를 먼저 식별하고, 메시지를 처리할 객체를 나중에 선택하면 아래와 같은 장점이 있다.
- 객체가 최소한의 인터페이스를 가질 수 있다.
필요한 메시지가 식별될 때까지 객체의 퍼블릭 인터페이스에 어떤 것도 추가되지 않기 때문 - 객체가 충분히 추상적인 인터페이스를 가질 수 있다.
객체의 인터페이스는 무엇(what)을 하는지는 표현해야 하지만 어떻게(how)는 노출해선 안된다.
메시지는 외부의 객체의 추상적인 요청이기 때문에 메시지를 먼저 식별하면 무엇을 수행할지에 초첨을 맞추는 인터페이스를 얻을 수 있다.
2. 행동이 상태를 결정한다.
- 객체가 존재하는 이유는 협력에 참여하기 위해서다.
객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 실수는 객체의 행동이 아니라 상태에 초점을 맞추는 것이다.
초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고, 그 후에 상태에 필요한 행동을 결정한다.
이런 방식은 내부 구현이 객체의 퍼블릭 인터페이스에 노출되도록 만들기 때문에 캡슐화를 저해한다. - 캡슐화를 위반하지 않도록 구현에 대한 결정을 뒤로 미루면서 객체의 행위를 고려하기 위해서는
항상 협력이라는 문맥 안에서 객체를 생각해야 한다.
협력 관계 속에서 다른 객체에게 무엇을 제공해야하고, 다른 객체로부터 무엇을 얻어야 하는지를 고민해야만
훌륭한 책임을 수확할 수 있다.
개별 객체의 상태와 행동이 아닌 시스템의 기능을 구현하기 위한 협력에 초점을 맞춰야만
응집도가 높고 결합도가 낮은 객체들을 창조할 수 있다.
역할 - 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합
협력을 모델링할 때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하는게 좋다.
역할은 구체적인 객체를 포괄하는 추상화이며, 객체가 들어갈 수 있는 일종의 슬롯이다.
애매하면 객체로 시작해서 동일한 책임을 역할로 묶어내도록 리팩토링하면 된다.
인상깊었던 점
"너무 이른 시기에 구현에 초점을 맞추는것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다."
이번 장에서 말하고 싶은 부분은 이 부분이라고 생각한다.
역할, 책임, 협력을 충분히 고려하고 코드를 작성하는 습관을 들이도록 노력해봐야겠다.
궁금한 점
JPA 같은 ORM을 이용하면서 ERD 작성때도 그렇고 엔티티가 가질 데이터부터 생각을 하곤 했던거 같습니다.
여러분들은 이럴 때 어떤 순서로 역할, 책임, 협력을 생각하면서 설계하시는지 궁금합니다.
답변 및 토론 내용
- 한번에 좋은 엔티티들의 관계를 정의하기가 정말 어려운것 같다.
아직 처음부터 객체지향적인 사고를 가지고 설계하는게 어색해서 먼저 가장 핵심이 되는 엔티티를 기존 방식대로 좀 러프하게 설계하고 리팩토링 하는 방식을 택한다.
어느정도 핵심이되는 로직들이 만들어지면 그 이후부터는 객체간의 역할 책임 협력 관계가 어느정도 눈에 보이고,
리팩토링을 하는 과정에서 기능 단위별로 테스트코드를 잘 짜놓으면 일단 어떻게든 완성은 되기 때문에 당장은 이런 방식도 좋을것 같다.
(테스트코드를 짜는건 정말 귀찮고 힘든 일이지만...) - ERD 작성 자체가 데이터 주도 설계이다. 따라서 상태에 대해 생각하는것은 어쩔 수 없는 부분이다.
- 사실 기능 구현을 할 때 이미 "기능" 이라는 행동에 초점을 두고, 기능을 구현하기 위해 협력할 객체를 선택하고,
그 이후에 엔티티가 어떤 데이터를 가질 지 생각하는 단계가 아니었을까?
어쩌면 생각보다 꽤 객체지향적으로 사고하는 습관이 들었던걸지도 모른다.
그러므로 이 책을 보면서 현 상황에서 더 나은 방향성이 있다면 그걸 참고하면서 발전시키면 좋을것 같다.