CH07 함께 모으기

이번 챕터는 카페에서 커피를 주문하는 예시를 가지고 실제로 설계를 하고 코드 단위까지 구현하는 내용이었다. 딱히 새로운 개념은 없었고 전반적으로 책에서 말한 모든 내용을 가지고 실습하는 단원의 개념이었다.

다만 설계에 관한 저자의 생각이 공감이 가서 아래에 옮겨둔다.

인터페이스를 통해 실제로 상호작용을 해보지 않은 채 인터페이스의 모습을 정확하게 예측하는 것은 불가능에 가깝다.

설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라. 설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라.

완벽한 설계를 먼저하고 그다음 구현을 하는 것이 아니라 설계라는 행위 자체를 손으로 하는 게 좋다는 저자의 생각이다. 사람의 머리가 일정 수준의 복잡성을 넘어서면 이전의 것을 잊어버리거나 구체적으로 연상하는 것이 어려울 수 있으므로 충분히 공감이 갔다.

꼭 코드 레벨로 구현하지 않더라도 화이트보드나 종이에 그려가면서 객체 구조를 그려보는 것이 개인적으로 좋았던 것 같다.

저자는 클래스 다이어그램에 대해서 경계하고 있고, 그 내용도 충분히 공감이 가지만 도메인 모델이 확립된 상태에서 객체 구조를 그려보는 것에 있어 클래스 다이어그램은 좋은 도구가 된다. 저자도 이 효용을 무시하는 것이 아니라 '객체 지향 패러다임' 이 곧 클래스 다이어그램이라는 식의 주객전도식 사고를 하지 말라는 내용이었다.

아무튼 그런 의미에서 클래스 다이어그램에 대한 구체적인 이해는 반드시 하고 있는 것이 설계에 도움이 되겠다.

음, 이건 이번 챕터와는 아무런 관련이 없는 내용이지만 생각해보니 새로운 도메인 및 레거시 프로젝트를 이해할 때 객체 구조를 클래스 다이어그램으로 그려보는 것이 빨리 이해를 하기 위한 가장 좋은 방법인 것 같다.

코드를 보지 않고 구체적인 수준까지 객체 구조, 각 객체가 가진 책임과 역할, 객체 간 오고가는 메세지를 말하거나 그릴 수 있을 때 전체 협력 구조를 이해하고 있다고 할 수 있지 않을까 싶다. 앞으로 새로운 도메인이나 레거시 프로젝트를 파악할 때는 반드시 이렇게 해야겠다는 생각이 든다. 그런 과정에서 더 좋은 설계도 생각날 수 있을 것 같다.