함께 모으기

개념 관점은 도메인 안에 존재하는 개념과 개념들의 관계를 설명하는 것입니다. 명세 관점은 도메인에 초점을 맞추는 것이 아닌 객체들의 책임에 초점을 맞추게 되고 무엇에 집중합니다. 구현 관점은 실제 작업을 수행하는 것과 관련 있습니다. 어떻게 수행할 것인가에 초점을 맞히게 됩니다.

 

클래스 설계의 방법이 다른 것이 아닌 설계를 진행할 때 위와 3가지 관점 모두 고려해서 설계해야 합니다.

커피 전문점 도메인

커피 주문하는 과정을 천천히 생각해 보세요. 손님이 들어가고 메뉴판을 확인 후 선택한 메뉴를 바리스타에게 주문하게 됩니다. 객체 지향적인 관점으로 해석하면 커피 가게 객체, 손님 객체, 메뉴판 객체, 커피 메뉴 객체, 바리스타 객체가 각자의 역할을 수행하며 협력하고 있는 것으로 해석할 수 있습니다.

 

객체의 인스턴스를 분류하기 위해서는 타입이 사용됩니다. 아메리카노, 에스프레소, 바닐라라떼 등이 커피 타입의 인스턴스라고 볼 수 있습니다. 위의 객체들은 상호 연결하며 협력하게 됩니다. 협력 관계를 아래의 그림으로 나타낼 수 있습니다.

메뉴판은 메뉴를 알고 있고 포함하고 있어야 합니다. 손님은 메뉴판과 바리스타와 연관 관계를 맺게 되고 바리스타는 커피와 연관 관계를 맺게 됩니다. 이처럼 도메인을 단순화해서 표현한 모델을 도메인 모델이라고 합니다.

설계하고 구현하기

객체지향 설계의 첫 번째 목표는 훌륭한 객체를 만드는 것이 아닌 훌륭한 협력에 있다는 것은 계속해서 강조해오던 내용입니다. 객체가 메시지를 선택하는 것이 아닌 메시지로부터 객체가 선택되어야 합니다.

객체가 어떤 메시지를 수신할 수 있다는 것은 객체의 인터페이스 안에 메시지에 해당하는 연산이 존재한다는 것을 의미합니다. 메시지를 전달하기 위해서는 해당 객체의 참조가 필요한데 가장 간단한 방법은 연산의 파라미터로 해당 객체를 전달하는 것입니다.

코드와 세 가지 관점

개념 관점

개념 관점에서 코드를 바라보면 손님, 메뉴, 메뉴판, 바리스타, 커피의 개념을 확인할 수 있습니다. 잘 정리된 개념은 변경을 관리하기 쉽고 유지보수성을 향상할 수 있습니다. 도메인 클래스와 소프트웨어 클래스 간의 간격이 좁으면 좁을수록 기능을 변경하기 위해 찾아야 하는 코드의 양도 줄어듭니다.

명세 관점

클래스의 인터페이스를 드러내게 됩니다. public 메서드를 통해 협력할 수 있는 메서드를 드러내게 되고 이를 수정하게 되면 협력하는 모든 객체에게 영향을 주게 됩니다. 변화에 안정적인 인터페이스를 만들기 위해서는 최대한 구현과 관련된 세부 사항을 숨기도록 해야 합니다.

구현 관점

클래스의 내부 구현을 바라보게 됩니다. 메서드의 구현과 속성의 변경은 원칙적으로 외부의 객체에 영향을 미쳐서는 안 됩니다.

 

코드를 읽으며 위의 세 가지 관점을 확인할 수 없다면 세 가지 관점이 명확하게 드러나도록 코드를 개선해야 합니다. 그것이 변경에 유연하게 코드를 작성하는 방법입니다. 메시지를 수신할 적절한 도메인을 정해야 하고 명세와 구현은 철저히 분리하도록 해야 합니다. 이를 위해서는 훌륭한 설계가 뒷받침돼야 하는 것도 잊어서는 안 됩니다.