🌈 Chapter 7: 함께 모으기

• 마틴 파울러는 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점에 관해 설명한다.

1. 개념 관점(Conceptual Perspective)에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 이 관점은 사용자가 도메인을 바라보는 관점을 반영한다. 따라서 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다.
2. 명세 관점(Specification Perspective)에 이르면 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다. 명세 관점은 도메인의 개념이 아니라 실제로 소프트웨어 안에서 살아 숨쉬는 객체들의 책임에 초점을 맞춘다. 즉, 객체의 인터에피스를 바라보게 된다.
3. 구현 관점(Implementation Perspective)은 실제 작업을 수행하는 코드와 연관돼 있다. 구현 관점의 초점은 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다.

• 이 세 가지 관점은 순서대로 소프트웨어를 개발하는 것이 아니라, 개념 관점, 명세 관점, 구현 관점은 동일한 클래스를 세 가지 다른 방향에서 바로보는 것을 의미한다.
• 클래스가 은유하는 개념은 도메인 관점을 반영한다. 클래스의 공용 인터페이스는 명세 관점을 반영한다. 클래스의 속성과 메서드는 구현 관점을 반영한다.
• 객체간의 관계에서 포함된다는 사실을 나타내는 것은 포함 관계 또는 합성 관계라고 한다.
• 한 타입의 인스턴스가 다른 타입의 인스턴스를 포함하지는 않지만 서로 알고 있어야 할 경우 이를 연관(association) 관계라고 한다.
• 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델을 도메인 모델이라 한다.
• 이 다음 단계는 지금까지 배운 지식을 총동원해서 협력을 설계하는 것으로 적절한 객체에게 적절한 책임을 할당하는 것이다.

✌️ 설계하고 구현하기

• 협력을 설계할 때는 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다.
• 이제 메시지를 수신할 객체는 메시지를 처리할 책임을 맡게 되고 객체가 수신하는 메시지는 객체가 외부에 제공하는 공용 인터페이스에 포함된다.
• 이때 메시지를 처리할 객체를 찾고 있다면 먼저 도메인 모델 안에 책임을 수행하기에 적절한 타입이 존재하는지 살핀다. 적절한 타입를 발견했다면 책임을 수행할 객체를 그 타입의 인스턴스로 만든다.
• 그 후 메시지를 수신할 객체 즉, 책임을 누가 져야 하는지를 결정한다. 만약 스스로 할 수 없는 일이 있다면 다른 객체에게 이를 요청한다. 이 요청이 객체에서 외부로 전송되는 메시지를 정의한다. 반환값이 필요할 때 전달받을 반환값을 얻을 수 있다.
• 이제 남은 일은 메시지를 정제함으로써 각 객체의 인터페이스를 구현 가능할 정도로 상세하게 정제하는 것이다.

🎈 인터페이스 정리하기

• 객체가 수신한 메시지가 객체의 인터페이스를 결정한다. 메시지가 객체를 선택했고, 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다.
• 객체가 어떤 메시지를 수신할 수 있다는 것은 그 객체의 인터페이스 안에 메시지에 해당하는 오퍼레이션이 존재한다는 것을 의미한다.
• 객체의 타입을 구현하는 일반적인 방법은 클래스를 이용하는 것으로 협력을 통해 식별된 타입의 오퍼레이션은 외부에서 접근 가능한 공용 인터페이스의 일부라는 사실이다. 따라서 인터페이스에 포함된 오퍼레이션 역시 외부에서 접근 가능하도록 공용(public)으로 선언돼 있어야 한다.

class Customer {
  public void order(String menuName) {}
}

🎈 구현하기

• 오퍼레이션을 수행하는 방법을 메서드로 구현한다.
• 객체가 다른 객체에게 메시지를 전송하기 위해서는 먼저 객체에 대한 참조를 얻어야 한다.

class Customer {
  // Menu와 Barista의 객체를 전달받아 참조 문제 해결
  public void order(String menuName, Menu menu, Barista barista) {
    // 메서드의 구현을 채운다.
    MenuItem menuItem = menu.choose(menuName);
    Coffee coffee = barista.makeCoffee(menuItem);
    // ...
  }
}

• Menu는 menuName에 해당하는 MenuItem을 찾아야 하는 책임이 있다. 이 책임을 수행하기 위해서는 Menu가 내부적으로 MenuItem을 관리하고 있어야 한다.

class Menu {
  private List<MenuItem> items;

  public Menu (List<MenuItem> items) {
    this.items = items;
  }

  public MenuItem choose (String name) {
    for (MenuItem each: items) {
      if (each.getName().equals(name)) {
        return each;
      }
    }
    return null;
  }
}

• Barista는 MenuItem을 이용해서 커피를 제조한다.

class Barista {
  public Coffee makeCoffee (MenuItem menuItem) {
    Coffee coffee = new Coffee(menuItem);
    return coffee;
  }
}

• Coffee는 자기 자신을 생성하기 위한 생성자를 제공한다.

class Coffee {
  private String name; // 커피 이름
  private int price; // 가격

  public Coffee (MenuItem menuItem) {
    this.name = menuItem.getName();
    this.price = menItem.cost();
  }
}

• MenuItem은 getName()과 cost() 메시지에 응답할 수 있도록 메서드를 구현해야 한다.

public class MenuItem {
  private String name;
  private int price;

  public MenuItem (String name, int price) {
    this.name = name;
    this.price = price;
  }

  public int cost() {
    return price;
  }

  public String getName() {
    return name;
  }
}

✌️ 코드의 세 가지 관점

🎈 코드는 세 가지 관점을 모두 제공해야 한다.

• 개념 관점에서 코드를 바라보면 Customer, Menu, MenuItem, Barista, Coffee 클래스가 보인다. 이 클래스들은 커피 전문점 도메인을 구성하는 중요한 개념과 관계를 반영한다.
• 명세 관점은 클래스의 인터페이스를 바라본다. 클래스의 public 메서드는 다른 클래스가 협력할 수 있는 공용 인터페이스를 드러낸다. 객체의 인터페이스는 수정하기 어렵다. 최대한 변화에 안정적인 인터페이스를 만들기 위해서는 인터페이스를 통해 구현과 관련된 세부 사항이 드러나지 않게 해야 한다.
• 구현 관점은 클래스의 내부 구현을 바라본다. 클래스의 메서드와 속성은 구현에 속하며 공용 인터페이스의 일부가 아니다. 따라서 메서드의 구현과 속성의 변경은 원칙적으로 외부의 객체에게 영향을 미쳐서는 안 된다. 이것은 메서드와 속성이 철저하게 클래스 내부로 캡슐화돼야 한다는 것을 의미한다.

🎈 도메인 개념을 참조하는 이유

• 메시지가 있을 때 그 메시지를 수신할 객체를 선택하는 방법 중 첫 번째 전략은 도메인 개념 중에서 가장 적절한 것을 선택하는 것이다.
• 도메인 개념 안에서 적절한 객체를 선택하는 것은 도메인에 대한 지식을 기반으로 코드의 구조와 의미를 쉽게 유추할 수 있게 한다.

🎈 인터페이스와 구현을 분리하라

• 명세 관점은 클래스의 안정적인 측면을 드러내야 한다.
• 구현 간점은 클래스의 불안정한 측면을 드러내야 한다.
• 명세 관점이 설계를 주도하게 하면 설계의 품질이 향상될 수 있다.