[객체지향의 사실과 오해] 7장 함께 모으기 (6일차)

7장 함께 모으기

개념관점에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 사용자가 도메인을 바라보는 관점을 반영하며, 실제 도메인의 규칙과 제약을 최대한 유사하게 반영한다.

명세 관점에 이르면 도메인을 벗어나 소프트웨어로 초점이 옮겨진다. 실제 소프트웨어 객체의 책임에 초점을 맞추며 객체의 인터페이스를 바라본다. 명세 관점에서는 객체가 협력을 위해 무엇을 할 수 있는가에 초점을 맞춘다.

구현 관점은 실제 작업을 수행하는 코드와 연관돼 있다. 객체들이 책임을 수행하는 데 필요한 동작을 코드로 직접 작성하는 것이다. 이때 어떻게 수행할 것인가에 초점을 맞춰 인터페이스를 구현하는 데 필요한 속성과 메서드를 추가한다.

이러한 관점은 개발 순서가 아닌 세 가지 관점이다. 클래스는 세 가지 관점을 모두 수용할 수 있도록 개념, 인터페이스, 구현을 함께 드러내야한다는 것을 암시한다. 동시에 코드 안에서 세 가지 관점을 쉽게 식별할 수 있도록 깔끔하게 분리해야 한다.

커피 전문점 도메인

커피 전문점을 개발하기 앞서 객체들로 도메인을 바라봐야한다. 손님, 바리스타, 메뉴판, 메뉴 항목, 커피는 모두 객체로써 커피 전문점 도메인을 구성한다. 그리고 이러한 객체들은 서로 관계를 맺으며, 손님, 바리스타, 커피, 메뉴 항목은 모두 타입으로써 인스턴스로 모델링할 수 있다. 메뉴와 메뉴 항목 사이에서는 포함 관계가 성립하며, 손님은 메뉴판을 알고 있어야하므로 연관 관계를 가진다.

설계하고 구현하기

객체지향의 목표는 협력을 설계하는 것임을 명심하자. 이때 메시지가 객체를 선택하게 해야한다.

첫 번째 메시지는 커피를 주문하라 일 것이다. 이를 처리하기 위해서는 어떤 객체들이 필요할까? 당연히 손님이 커피를 주문해야한다. 주문하기 위해서는 정확한 메뉴를 알아야하며, 메뉴판에 메시지를 보내 특정 메뉴 항목을 선택할 수 있다. 이제 바리스타에게 커피 제조를 맡겨야하며 바리스타는 커피를 실제 제조한다.

위에서 객체들의 관계를 정의한 것은 객체들의 인터페이스이다. 우리는 메시지를 통해 객체를 선택했고, 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다. 각 협력에서 메시지에 해당하는 오퍼레이션이 존재한다.

이를 구현하는 일반적인 방법은 클래스를 이용하는 것이다. 클래스의 인터페이스를 식별했으니 오퍼레이션을 수행하는 방법을 메서드로 구현하면 된다. 구현 과정은 잘 알거라 생각한다.

코드와 세 가지 관점

개념 관점에서 바라보자면 Customer, Menu, Barista 등 클래스가 보일 것이다. 이러한 클래스는 커피 전문점 도메인을 구성하는 중요한 개념과 관계를 반영하고 있다. 소프트웨어 클래스와 도메인 클래스 간의 간격이 좁을 수록 기능 변경을 위한 코드의 양도 줄어든다.

명세 관점은 클래스의 인터페이스를 바라본다. 클래스의 public 메서드는 다른 클래스가 협력할 수 있는 공용 인터페이스를 드러낸다. 외부 객체가 해당 객체에 접근할 수 있는 유일한 부분이다. 이를 수정하면 협력하는 모든 객체에 영향을 미칠 수 밖에 없으므로 수정하기 어렵다. 최대한 변화에 안정적인 인터페이스를 만들기 위해서는 인터페이스를 통해 구현과 관련된 세부 사항이 드러나지 않도록 해야한다.

구현 관점에서는 클래스의 내부 구현을 바라본다. 클래스의 메서드와 속성은 구현에 속하며 공용 인터페이스의 일부가 아니다. 따라서 메서드의 구현과 속성의 변경은 원칙적으로 외부의 객체에 영향을 미쳐서는 안된다. 이는 철저한 캡슐화를 의미한다.

이렇게 세 관점은 모두 다른 관점이다. 훌룡한 객체지향은 세 가지 관점을 하나의 클래스안에 모두 포함하면서 각 관점에 대응되는 요소를 명확하고 깔끔하게 드러낼 수 있어야한다.