07 함께 모으기

코드와 모델을 밀접하게 연관시키는 것은 코드에 의미를 부여하고 모델을 적절하게 한다.

마틴 파울러는 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점을 각각 개념 관점, 명세 관점, 구현 관점이라고 부른다.

 

 🔎 개념 관점 (Conceptual Perspective) 

 

개념 관점에서의 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.

(도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말한다.)

이 관점은 사용자가 도메인을 바라보는 관점을 반영한다. 따라서 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다.

 

 🔎 명세 관점 (Specification Perspective) 

 

사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다. → 객체의 인터페이스를 바라보게 된다.

명세 관점에서 프로그래머는 객체가 협력을 위해 '무엇'을 할 수 있는가에 초점을 맞춘다.

* 명세 관점와 구현 관점을 명확하게 분리해야 한다.

 

 🔎 구현 관점 (Implementation Perspective) 

 

구현 관점의 초점은 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다.

프로그래머는 객체의 책임을 '어떻게' 수행할 것인가에 초점을 맞추며 인터페이스를 구현하는 데 필요한 속성과 메서드를 클래스에 추가한다.

 

 ☕️  커피 전문점 도메인 

커피 전문점에서 커피를 주문하는 과정을 객체들의 협력 관계로 구현해보자.

 

  메뉴판  

 · 네가지 메뉴 : 아메리카노, 카푸치노, 카라멜 마키야또, 에스프레소

 · 메뉴 항목들 역시 객체로 볼 수 있다.

 · 따서 메뉴판은 네 가지 메뉴 항목 객체들을 포함하는 객체라고 볼 수 있다.

 

  손님  

 · 손님 역시 하나의 객체

 · 메뉴판을 보고 바리스타에게 원하는 커피를 주문한다.

 

  바리스타  

 · 자율적으로 커피를 제조하는 객체로 볼 수 있다.

 · 바리스타가 제조하는 커피 역시 객체로 볼 수 있다.

 

객체지향 관점에서 커피 전문점이라는 도메인은 손님 객체, 메뉴 항목 객체, 메뉴판 객체, 바리스타 객체, 커피 객체로 구성된 작은 세상이다.

 

동적인 객체를 정적인 타입으로 추상화해서 복잡성을 낮춰야 한다.

상태와 무관하게 동일하게 행동할 수 있는 객체들은 동일한 타입으로 분류할 수 있다.

 

  메뉴판 타입 - 메뉴 항목 타입  

 · 하나의 메뉴판 객체는 다수의 메뉴 항목 객체로 구성돼 있다.

 · 메뉴판과 메뉴 항목 객체는 따로 떨어져 존재하지 않으며 하나의 단위로 움직인다.

 · 메뉴 항목이 메뉴판에 포함되었다고 표현할 수 있고, 이를 포함(containment) 관계 또는 합성(composition) 관계라고 한다.

 

  손님 타입 - 메뉴판 타입  

 · 손님 타입은 메뉴판 타입을 알고 있어야 원하는 커피를 선택할 수 있다.

 · 한 타입의 인스턴스가 다른 타입의 인스턴스를 포함하지는 않지만 서로 알고 있어야 할 경우 이를 연관(association) 관계라고 한다.

 

 

  손님 타입 - 바리스타 타입  

 · 손님 타입은 바리스타 타입에게 주문을 해야한다. 

 

 

  바리스타 타입 - 메뉴판 타입  

 · 바리스타 타입은 커피 타입을 알고 있어야 하고, 커피를 제조해야 한다.

 

 

커피 제조와 관련된 객체들을 타입과 관계를 이용해 추상화한 일종의 모델을 작성했으며, 이처럼 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델을 도메인 모델이라고 한다.

 

이제 적절한 객체에게 적절한 책임을 할당하여 협력을 설계해 보자.

 

 📌  설계하고 구현하기 

  1️⃣  커피를 주문하기 위한 협력 찾기  

객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택해야 한다.

→ 메시지를 수신할 객체는 메시지를 처리할 책임을 맡게 되고 객체가 수신하는 메시지는 객체가 외부에 제공하는 공용 인터페이스에 포함된다.

 

  '커피를 주문하라' 

 · 메시지를 처리할 객체는 손님 타입의 인스턴스이다.

 · 손님 객체가 커피를 주문할 책임을 할당 받는다. (메시지를 선택한 다음 객체를 선택했다.)

 

  '메뉴 항목을 찾아라' 

 · 손님은 메뉴 항목에 대해서는 알지 못한다. 따라서 고객은 메뉴 항목을 누군가가 제공해 줄 것을 요청한다.

 · 메시지에 '메뉴 항목'이라는 인자를 포함해 함께 전송한다.

 · 메시지를 수신한 객체는 '메뉴 이름'에 대응되는 '메뉴 항목'을 반환해야 한다.

 · 메뉴 항목 객체를 포함하는 메뉴판 객체가 이 책임을 처리할 수 있는 가장 적절한 후보이다.

 

  '커피를 제조하라' 

 · 손님은 자신이 주문한 커피에 대한 메뉴 항목을 얻었으니 이제 커피를 제조해 달라고 요청할 수 있다.

 · 바리스타는 커피를 제조하는 데 필요한 모든 정보를 알고 있다.

 · 바리스타는 커피를 만드는 데 필요한 정보와 기술을 구비하고 있는 전문가이므로, 자율적인 객체로써 커피를 제조하는 책임을 가진다.

 

이렇게 협력에 필요한 객체의 종류와 책임, 주고받아야 하는 메시지에 대한 대략적인 윤곽을 잡았다.

이제 메시지를 정제함으로써 각 객체의 인터페이스를 구현 가능할 정도로 상세하게 정제해야 한다.

  2️⃣  인터페이스 정리하기  

객체가 수신한 메시지가 객체의 인터페이스를 결정한다.

메시지가 객체를 선택했고, 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다.

 

  손님 객체의 인터페이스  

 · '커피를 주문하라'라는 오퍼레이션이 포함되어야 한다.

 

  메뉴판 객체의 인터페이스  

 · '메뉴 항목을 찾아라'라는 오퍼레이션이 제공해야 한다.

 

  바리스타 객체의 인터페이스  

 · '커피를 제조하라'라는 오퍼레이션이 제공해야 한다.

 

  커피 객체의 인터페이스  

 · '생성하라'라는 오퍼레이션이 제공해야 한다.

 

객체들을 포괄하는 타입을 정의한 후 식별된 오퍼레이션을 타입의 인터페이스에 추가해야 한다.

→ 협력을 통해 식별된 타입의 오퍼레이션은 외부에서 접근 가능한 공용 인터페이스의 일부이다.

→ 따라서 인터페이스에 포함된 오퍼레이션 역시 외부에서 접근 가능하도록 공용(public)으로 선언되어 있어야 한다.

 

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

class MenuItem {
}

class Menu {
    public MenuItem choose(String name) {}
}

class Barista {
    public Coffee makeCoffee(MenuItem menuItem) {}
}

class Coffee {
    public Coffee(MenuItem menuItem) {}
}

 

  3️⃣  구현 하기  

클래스의 인터페이스를 식별했으므로 이제 오퍼레이션을 수행하는 방법을 메서드로 구현해보자.

  Customer  

 · Customer는 Menu에게 menuName에 해당하는 MenuItem을 찾아달라고 요청해야 한다.

 · MenuItem을 받아 이를 Barista에게 전달해서 원하는 커피를 제조하도록 요청해야 한다.

 · 객체 참조를 얻는 다양한 방법이 있지만 여기서는 Customer의 order() 메서드의 인자로 Menu와 Barista 객체를 전달받는 방법으로 참조 문제를 해결하기로 한다. 

 

class Customer {
    public void order(String menuName, Menu menu, Barista barista) {
        MenuItem menuItem = menu.choose(menuName);
        Coffee coffee = barista.makeCoffee(menuItem);
        ...
    }
}

 

 · 설계 작업은 구현을 위한 스케치를 작성하는 단계이다. 중요한 것은 설계가 아니라 코드다. 최대한 빨리 코드를 구현해서 설계에 이상이 없는지, 설계가 구현 가능한지를 판단해야 한다.

 

  Menu  

 · Menu는 menuName에 해당하는 MenuItem을 찾아야 하는 책임이 있다.

 · Menu가 MenuItem의 목록을 포함해야 한다.

 · Menu의 choose() 메서드는 MenuItem의 목록을 하나씩 검사해가면서 이름이 동일한 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;
    }
}

 

 · MenuItem의 목록을 Menu의 속성으로 포함시킨 결정 역시 클래스를 구현하는 도중에 내려졌다.

  → 객체의 속성은 객체의 내부 구현에 속하기 때문에 캡슐화되어야 한다.

  → 가장 훌륭한 방법은 인터페이스를 정하는 단계에서는 객체가 어떤 속성을 가지는지, 또 그 속성이 어떤 자료 구조로 구현됐는지를 고려하지 않는 것이다. 

  → 객체가 어떤 책임을 수행해야 하는지를 결정한 후에야 책임을 수행하는 데 필요한 객체의 속성을 결정하자.

 

  Barista  

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

 

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

 

  Coffee  

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

 · Coffee는 커피 이름과 가격을 속성으로 가지고 생성자 안에서 MenuItem에 요청을 보내 커피 이름과 가격을 얻은 후 Coffee의 속성을 저장한다.

 

class Coffee {
    private String name;
    private int price;
    
    public Coffee(MenuItem menuItem) {
        this.name = menuItem.getName();
        this.price = menuItem.cost();
    }
}

 

  MenuItem  

 · 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;
    }
}

 

 · MenuItem의 인터페이스를 구성하는 오퍼레이션들을 MenuItem을 구현한는 단계에서 식별했다.

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

  → 설계를 간단히 끝내고 최대한 빨리 구현에 돌입해야 한다.

  → 테스트 - 주도 설계로 코드를 구현하는 사람들이 실제도 코드를 작성해가면서 협력의 전체적인 밑그림을 그린다.

 

커피 전문점을 구현한 최종 클래스 구조

 

 

 👊 결 론 👊 

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

개념 관점

 · 개념 관점에서 코드를 바라보면 Customer, Menu, MenuItem, Barista, Coffee 클래스를 확인할 수 있다.

 · 소프트웨어 클래스가 도메인 개념의 특성을 최대한 수용하면 변경을 관리하기 쉽고 유지보수성을 향상시킬 수 있다.

 · 소프트웨어 클래스와 도메인 클래스 사이의 간격이 좁으면 좁을수록 기능을 변경하기 위해 뒤적거려야 하는 코드의 양도 점점 적어진다.

 

명세 관점

 · 명세 관점은 클래스의 인터페이스를 바라본다.

 · 인터페이스를 수정하면 해당 객체와 협력하는 모든 객체에게 영향을 미칠 수밖에 없다.

 · 최대한 변화에 안정적인 인터페이스를 만들기 위해서는 인터페이스를 통해 구현과 관련된 세부 사항이 드러나지 않게 해야 한다.

 

구현 관점

 · 구현 관점은 클래스의 내부를 바라본다.

 · 메서드의 구현과 속성의 변경은 원칙적으로 외부의 객체에게 영향을 미쳐서는 안 된다.

   → 메서드와 속성이 철저하게 클래스 내부로 캡슐화되어야 한다!

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

 · 어떤 메시지가 있을 때 그 메시지를 수신할 객체를 선택하는 첫 번째 전략은 도메인 개념 중에서 가장 적절한 것을 선택하는 것이다.

   → 도메인 개념 안에서 적절한 객체를 선택하는 것은 도메인에 대한 지식을 기반으로 코드의 구조와 의미를 쉽게 유추할 수 있게 한다.

      → 유지보수성에 큰 영향을 미친다.

   → 소프트웨어 클래스가 도메인 개념을 따르면 변화에 쉽게 대응할 수 있다.

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

 · 명세 관점은 클래스의 안정적인 측면을 드러내야 하고, 구현 관점은 불안정한 측면을 드러내야 한다.

   → 인터페이스가 구현 세부 사항을 노출하기 시작하면 아주 작은 변동에도 전체 협력이 요동치는 취약한 설계를 얻을 수밖에 없다.

 · 클래스를 봤을 때 클래스의 명세 관점과 구현 관점으로 나눠볼 수 있어야 한다.

   → 캡슐화를 위반해서 구현을 인터페이스 밖으로 노출해서도 안 되고,

   → 인터페이스와 구현을 명확하게 분리하지 않고 흐릿하게 섞어놓아서는 안 된다.

 

📍 세 가지 관점 모두에서 클래스를 바라볼 수 있으려면 훌륭한 설계가 뒷받침돼야 하는 것이다.