5장 정리
데이터 중심 설계 - 행동보다 데이터를 먼저 결정해서 협력이라는 문맥을 벗어나 고립된 객체의 상태에 초점을 맞추기 때문에 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려워진다.
그러니까 책임 중심 설계로 가자.
책임 주도 설계
데이터보다 행동을 먼저 결정하라.
초보자들은 객체지향이라고 객체부터 생각하는데 협력을 통해 생기는 책임에 초점을 맞추지 않고
바로 객체의 데이터에 초점을 맞춘다.
하지만 너무 이른 시기에 데이터에 초점을 맞추면 데이터 중심 설계의 단점을 따라가서 변경에 취약해진다.
그러므로 "객체가 포함해야 하는 데이터가 무엇인가" 에서 "객체가 수행해야 하는 책임은 무엇인가" 를 결정하고 이후에 "책임을 수행하는데 필요한 데이터는 무엇인가" 를 결정하라.
즉, 책임을 먼저 결정한 후에 객체의 상태를 결정하라.
협력이라는 문맥 안에서 책임을 결정하라
책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다.
협력을 시작하는 주체는 메시지 전송자이므로 협력에 적합한 책임이란 메시지 수신자가 아닌, 메시지 전송자에게 적합한 책임을 의미한다. 즉, 메시지를 전송하는 클라이언트의 의도에 적합한 책임을 할당해야 한다.
이는 곧 객체를 결정한 후에 메시지를 선택하는 것이 아니라 메시지를 결정한 후에 객체를 선택함을 의미한다.
"메서드를 만들어두고 누가 호출하지?" 대신에 "메시지를 전송해야하는데 누구에게 전송해야하지?" 라고 질문하는것이 필요하다.
이러면 메시지를 먼저 결정하므로 송신자는 메시지 수신자에 대해 모른다. 그러므로 메시지 전송자의 관점에서 메시지 수신자는 캡슐화가 된다.
책임 중심 설계는 이처럼 캡슐화를 지키기 쉬우므로 응집도가 높고 결합도가 낮으며 변경하기 쉽다.
도메인 개념을 정리하는데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라.
올바른 도메인 모델이란 존재하지 않는다. 유연성이나 재사용성 등과 같이 실제 코드를 구현하면서 도메인 개념이 바뀔 수 있기 때문이다.
기본적으로 INFORMATION EXPERT 패턴을 따르면 자율성이 높은 객체들로 구성된 협력 공동체를 구축할 가능성이 높아진다. 하지만 동일한 기능을 구현할 수 있는 무수히 많은 설계가 존재하므로 필요에 따라 적합한 책임 할당 패턴을 고려한다.
구현과 리팩토링
요구사항에 맞춰 코드를 구현하면서 리팩토링을 진행한다.
DiscountCondition 의 예시처럼 하나 이상의 변경 이유를 가지는것은 낮은 응집도를 의미하므로 변경의 이유에 따라 클래스를 분리한다.
응집도가 낮다는 신호가 몇가지 존재한다. 그 중 하나는 초기화 할때 나타난다.
응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화 한다.
반면 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고 일부는 초기화 되지 않은채로 남는다.
따라서 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
설계를 주도하는 것은 변경이다. 변경에 대비할 수 있는 방법은 두 가지 방법이 있다.
- 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계한다.
- 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만든다.
대부분의 경우 전자가 더 좋은 방법이지만 유사한 변경이 반복적으로 발생하고 있다면 복잡성이 상승하더라도 유연성을 추가하는 두번째 방법이 더 좋다.
책임 주도 설계에 익숙해지기 위해서는 부단한 노력과 시간이 필요하다.
우선 절차적이든, 데이터 중심적이든 동작하는 코드를 작성하고 동작은 유지한 채로 내부 구조를 변경하여 책임 주도 설계 형식이 되도록 리팩토링 하라.
책임 주도 설계 방법을 단계적으로 따르지 않더라도 캡슐화, 결합도, 응집도를 이해하고 객체지향 원칙을 적용하기 위해 노력한다면 충분히 유연하고 깔끔한 코드를 얻을 수 있다.
인상깊었던 점
"도메인 개념을 정리하는데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라."
이번 장에서 저에게 가장 와닿았던 문장은 이 문장이었다.
나는 뭔가를 시작하는게 제일 어렵다고 생각하는데, 이유를 생각해보면 내가 제대로 하는게 맞나? 하는 생각때문인듯 하다.
그런데 책에서도 처음 그렸던 도메인과 구현을 통해 도메인 바뀐 구조를 보여주니까 안심하고 빠르게 시작할 용기가 생겼다.
책임 주도 설계 방법이 좋다는건 모두가 알지만 결국 적용하는데는 부단한 노력과 시간이 필요하다고.
개발 경험이 쌓이면서 더 책임 주도로 설계하고, 객체지향적인 코드를 작성할 수 있다.
그러니까 책을 읽고 여기에 매몰되지 말고 일단 뭐든 해라 라는 말을 하고 싶었던거 같다.
결국 중요한건 캡슐화, 결합도, 응집도를 이해하고 객체지향 원칙을 적용하기 위해 노력하는것 같다.
이런 기본에 충실하면 처음부터 책임 주도적으로 설계하지 않아도 유연한 설계로 리팩토링이 가능하단걸 느꼈다.