Ch.7 함께 모으기

객체지향 설계 안에 존재하는 세가지 상호 연관된 관점

개념관점

• 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하라.
  => 도메인 설계를 잘해라.

명세관점

• 소프트웨어 관점에서 객체가 다른 객체와의 협력을 위해 '무엇'을 할 수 있는가에 초점을 맞춰라
  => 인터페이스와 구현체를 하나의 클래스 혹은 생략하지말고 분리하여 생각하자.

구현관점

• 객체들이 책임을 수행하는데 필요한 코드를 작성한다.
  => 즉, 인터페이스는 객체들간의 책임과 협력에서의 명세서로써 분리하고 그 인터페이스에 메서드와 속성들을 구현하자.

---

커피 전문점 도메인

객체

• 손님
• 바리스타
• 메뉴판
• 메뉴
• 커피

연관관계

메뉴판 <- 메뉴 (메뉴는 메뉴판에 포함된다.)
손님 - 메뉴판 (손님과 메뉴판은 연관된다.)
손님 - 바리스타 (연관)
바리스타 - 커피 (연관)

---

객체가 수신하는 메시지는 인터페이스에 포함되어 요청하게 된다.

손님

1. 커피를 주문한다.
2. 메뉴 항목을 찾는다.
3. 메뉴를 고르기 위해 메뉴판 객체를 부른다.
4. 메뉴판 객체에게 메뉴항목을 전달받는다.
5. 고른 메뉴를 바리스타에게 전달한다.
6. 커피를 받은 후 주문도메인은 종료된다.

메뉴판

3-1. 요청을 받은 메뉴판 객체는 메뉴 객체를 부른다.
3-2. 손님에게 전달받은 요청(파라미터)와 같은 메뉴객체를 찾는다.
3-3. 찾은 메뉴를 손님에게 전달한다.

바리스타

5-1. 요청을 받은 바리스타는 요청에 맞는 커피 객체를 부른다.
5-2. 커피를 제조 후 손님에게 전달한다.

---

코드와 세가지의 관점

앞서 말한 세가지 관점을 생각해보자

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

커피 제조과정에 유지보수가 필요하다면 '바리스타 객체'를 수정하면 된다. 현실에서도 그렇다.

• 명세관점
  변화에 안정적인 인터페이스는 인터페이스의 구현과 관련된 세부사항을 드러나지 않게 한 인터페이스다.

공용 인터페이스를 수정한다면 인터페이스를 가지고 있는 객체와 인터페이스를 호출하는 객체도 수정을 거쳐야하기 때문이다.

• 구현관점
  메서드와 내부 속성은 철저하게 클래스 내부로 캡슐화 되어있어야 한다.

---

느낀점

• 굳이 impl을 추가하여 구현과 인터페이스를 분리하는 행위를 관습적인 추상화라고 생각했던 적이 있었다. 책을 읽으면서 생각을 고치게 되었다.

서비스 레이어는 호출을 받으면 그 호출에 대한 객체를 불러오고 로직을 적용하여 모델로 만들어 응답해주어야 하는 객체이다.
만약 이 객체를 인터페이스로 만들지 않는다면 다른 객체에서 '객체를 가공하여 로직을 수행하는 가장 중요한 부분'을 쉽게 들여다 볼 수 있게된다.

• 객체지향 안에선 모든 설계와 코드는 변할 수 있다.
  난 모든 것이 변할 수 있는 객체지향의 세계에서 변하지 않게 하겠다는 코드를 만들고 있었던 것 같다.

• 다음부턴 인터페이스와 구현체의 특성을 살려 관습적인 추상화가 아닌 누군가 클래스이름과 상속여부, 구현체이름 만 봐도 대략적인 도메인의 흐름을 알 수 있는 코드를 작성해보도록 하자.