함께 모으기

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

• 개념 관점
  • 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.
  • 실제 도메인의 규칙과 제약이 최대한 유사하게 반영된다
• 명세 관점
  • 실제 개발하는 소프트웨어의 관점
  • 객체가 협력을 위해 무엇을 할 수 있는가
  • 인터페이스 중심의 관점
• 구현 관점
  • 가장 익숙한 관점
  • 실제 작업을 수행하는 동작하는 코드 작성
  • 객체가 책임을 어떻게 수행할 것인가

 

---

도메인 찾기

1. 요구사항 또는 예제에 대한 설명에서 도메인 찾기
   1. 예: 커피 주문하기
   2. 손님, 바리스타, 메뉴판, 메뉴 항목, 아메리카노, 카푸치노, 에스프레소, 카라멜 마키아또 객체로 구성된다.
2. 객체 간의 관계 확인
   1. 예: 손님은 메뉴판에서 주문할 커피를 고르기 때문에 메뉴판 객체를 알아야 한다. 즉, 관계를 맺는다.
3. 객체의 타입 분류
   1. 메뉴판 객체는 아메리카노, 카푸치노, 에스프레소, 카라멜 마키아또라는 메뉴 항목 객체를 포함한다.
   2. 또한 아메리카노, 카푸치노, 에스프레소, 카라멜 마키아또 객체는 ‘메뉴 항목 타입’의 인스턴스이다.
   3. 아메리카노 커피, 카푸치노 커피, 에스프레소 커피, 카라멜 마키아또 커피 객체는 ‘커피 타입’의 인스턴스로 볼 수 있다.
4. 객체 간의 관계를 도메인 모델로 표현

---

설계하고 구현하기

협력 찾기

1. 메시지 선택
   1. 예: ‘커피를 주문하라’
2. 메시지를 수신할 객체 선택
   1. 먼저 추상화한 도메인 모델에서 적절한 타입을 찾는다
   2. 책임을 수행할 객체를 그 타입의 인스턴스로 만든다
   3. 예: ‘손님’은 이 메세지를 수신할 책임이 있다.
3. 책임을 수행할 수 없을 때
   1. 객체가 책임을 수행하다 스스로 할 수 없는 일이 있다면 다른 객체에게 요청한다
   2. 예: 손님은 메뉴 항목을 알지 못한다. 따라서 메뉴 항목을 제공해 줄 것을 요청한다. 새로운 메시지(‘메뉴 항목을 찾아라’)가 생긴다.

인터페이스 정리하기

p. 219
각 객체를 협력이라는 문맥에서 떼어내어 수신 가능한 메시지만 추려내면 객체의 인터페이스가 된다.

1. 메시지와 수신자 추리기
2. 객체를 포괄하는 타입을 정의한 뒤 인터페이스에 추가

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

구현하기

1. 참조 얻어내기
   1. 다른 객체에 접근하기 위해서는 객체에 대한 참조가 필요하다
   2. 예: 메서드의 매개변수로 객체를 전달한다.
   3. 예: 객체가 속성으로 가지고 있는다.
      1. 인터페이스 구상 단계에서는 고려하지 않는다.(캡슐화)
2. 메서드 구현하기

class Customer {
	// 매개변수를 통해 참조를 얻는다.
	public coid order(String menuName, Menu menu, Barista barista) {
 	
    	...
    
   }
}

class Menu {
	// 객체가 내부적으로 속성을 통해 참조를 가진다.
	private List<MenuItem> items;
    
    ...
    
}

---

코드와 세 가지 관점

• 개념 관점
  • 개념과 관계를 반영한다.
  • 도메인의 개념과 관계를 최대한 수용하면 변경과 유지보수에 대응하기 쉬워진다.
• 명세 관점
  • 인터페이스를 바라본다.
  • 외부 객체가 접근할 수 있는 유일한 부분을 보여준다.
  • 인터페이스가 변경되면 모든 객체에 영향을 줄 수 있기 때문에 수정이 어렵다.
• 구현 관점
  • 클래스의 내부 구현
  • 메서드와 속성은 인터페이스가 아니므로 캡슐화를 통해 인터페이스와 분리되어야 한다.

---

정리

- 개념 관점, 명세 관점, 구현 관점은 순서가 아니라 한 번에 고려되어야 한다.
- 객체와 타입은 도메인
- 책임은 메시지를 통해 알 수 있다.
- 인터페이스와 구현을 분리하라.