[개발 서적] 객체지향의 사실과 오해(설계 중심)

🔗 들어가며

이번 게시글에서는 객체지향의 사실과 오해: 7장을 중심으로 다뤄보고자 한다. 사실 1-6장의 내용을 종합한 내용이 7장이라 생각한다. 앞에서 정리했던 개념들을 바탕으로 설계를 어떻게 진행해야 하는지 이번 게시글에서 다뤄보며 객체지향의 막을 내려보자!:>

🔗 객체지향 설계의 세 가지 상호 연관된 관점

1. 개념 관점

• 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.
• 사용자가 도메인을 바라보는 관점을 반영한다.

2. 명세 관점

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

3. 구현 관점

• 우리에게 가장 익숙한 관점으로, 실제 작업을 수행하는 코드와 연관돼 있다.
• 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다.

🔗 커피 전문점 도메인

일반적으로 손님이 메뉴를 통해 커피를 주문하고 바리스타가 주문을 받고 커피를 제공하는 상황을 생각해보자.

1. 도메인을 단순화 해서 이해하자. (도메인 모델)

---

동적인 객체를 그대로 다루기에는 너무 많은 상태와 변화가 존재한다. 이를 위해 객체들을 정적인 타입으로 추상화해 복잡성을 낮추자!

커피 전문점 도메인을 이루는 작은 객체들을 찾고, 객체들 사이 관계를 나타내보자!

이렇게 하면 커페 전문점이라는 도메인을 단순화해 이해할 수 있다. 그렇다면 이제 소프트웨어로 초점을 옮길 차례다.

객체지향의 세계는 협력하는 자율적인 객체들의 공통체이다. 이제는 협력을 설계하고, 이를 적절한 객체에게 할당하자!

2. 협력을 설계하자!

---

해당 도메인에는 정말 많은 협력이 존재한다. 하지만 여기서는 협력의 일부분만을 바라볼 것이다.

위의 협력들은 다음의 과정을 통해 하나씨 결정이 된다.

1. 커피주문이라는 메시지로 협력이 시작된다.
2. 해당 메시지를 수신할 객체로 손님이 선택된다.
   • 손님은 커피주문이라는 메시지를 처리할 책임을 가진다.
   • 커피주문이라는 메시지를 통해 손님의 인터페이스 형태가 결정된다.
3. 커피주문이라는 메시지를 수신할 때 주문할 커피 메뉴가 함께 전달된다.
   • 메시지와 함께 전달되는 것은 인자로 취급된다.

위와 같이 how - what 사이클을 반복적으로 진행하며 도메인 내에서의 협력을 찾는다.

3. 메시지를 바탕으로 인터페이스 설계!

---

앞에서도 말했듯이 메시지가 인터페이스의 형태를 구성한다. 그리고 이러한 인터페이스는 외부에서 접근이 가능한 형태의 공용 인터페이스이다.

// 손님 인터페이스 일부

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

4. 내부 설계 구현하기!

---

필요한 인터페이스를 모두 설계했다면 내부 설계를 구현할 차례다.

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

여기서 단순 인터페이스를 설계할 때와 다르게 인자가 늘어난 것을 확인할 수 있다. 설계 작업은 구현을 위한 스케치를 작성하는 단계이므로 구현 그 자체가 될 수 없다. 구현 도중에는 객체의 인터페이스가 변경될 수 있다는 점에 주목하자.

따라서 설계를 완벽하려고 하지 않아도 된다. 100% 완벽한 설계란 없다. 따라서 해당 책에서도 설계를 간단히 끝내고 빠르게 구현에 돌입하는 것을 추천한다.

🔗 커피 전문점 도메인을 세 가지 관점으로 바라보기

여기까지 진행했다면 설계가 마무리된다. 물론 책의 내용처럼 모든 부분을 자세히 다루지는 못했지만 핵심적인 부분을 짚고 넘어갈 수 있었을 거라 생각한다.

그렇다면 위의 설계를 개념 / 명세 / 구현 관점에서 바라보자!

1. 개념 관점

• 커피 전문점 도메인 설계에는 ustomer, Menu, MenuItem.. 등의 클래스가 존재한다.
• 이러한 클래스들은 커피 전문점 도메인을 구성하는 중요 개념과 관계를 반영한다.
• 소프트웨어 클래스가 도메인 개념의 특성을 최대한 수용한 것이다!
  • 이를 통해 변경을 관리하기 쉽고 유지보수성을 향상시킬 수 있게 된다.

2. 명세 관점

• 공용 인터페이스는 외부 객체가 해당 객체에 접근할 수 있는 유일한 부분이다.
• 객체의 인터페이스는 수정이 어렵다는 점을 명심하자.
  • 구현과 관련된 세부 사항이 드러나지 않도록 하여 변화에 안정적인 인터페이스 만들기!

3. 구현 관점

• 클래스 내부 구현을 바라본다.
• 클래스의 메서드와 속성은 구현에 속하며 공용 인터페이스의 일부가 아니다.
  • 따라서 메서드와 속성은 클래스 내부로 철저히 캡슐화해야 한다.

위 세 가지 관점은 코드를 바라보는 서로 다른 관점이다. 이처럼 코드를 바라보았을 때 세 가지 관점을 쉽게 포착하지 못하겠다면 코드를 개선하자! 개선을 통해 변경에 유연하게 대응할 수 있는 객체지향 코드를 작성하자.