06. 객체 지도
- 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며, 변경에 안정적
- 안정적인 구조를 따라 역할/책임/협력을 구성할 것
- 설계의 가장 큰 도전은 "기능" & "구조" 두 가지 측면을 함께 녹여 조화를 이루도록 하는 것
- 객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다
- [구조: 도메인 모델]
- 안정적인 구조를 개념화하기 위해 쓰임
- 도메인: 사용자가 프로그램을 사용하는 대상 분야
- 도메인 모델: 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
- 객체지향을 통해 사용자들이 이해하고 있는 도메인의 구조와 최대한 유사하게 코드를 구조화 할 수 있다
- [기능: 유스케이스]
- 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구
- 유스케이스: 사용자의 목표를 달성하기 위해, 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것
1. 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'
2. 하나의 시나리오가 아니라 여러 시나리오들의 집합
3. 단순한 기능 목록과는 다름
- 단순히 기능을 나열하는 것이 아니라, 이야기를 통해 연관된 기능을 묶을 수 있음
4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말 것
5. 내부 설계와 관련된 정보를 포함하지 않는다
07. 함께 모으기
- 개념(도메인) 관점: 클래스가 은유하는 개념
- 명세 관점: 클래스의 공용 인터페이스
- 구현 관점: 클래스의 속성과 메서드
- 객체지향 설계의 첫 번째 목표는 훌륭한 객체를 설계하는 것이 아니라, 훌륭한 협력 설계하는 것임을 잊지 말자
- 메시지를 먼저 선택하고, 그 후에 메시지를 수신하기에 적절한 객체를 선택하라
- [커피 만들기 실습]
- 개념 관점: Customer, Menu, MenuItem, Barista, Coffee 클래스가 보인다
- 클래스가 도메인 개념의 특성을 최대한 수용하면, 변경 관리가 쉽고, 유지보수성이 올라간다
- 명세 관점: 공용 인터페이스는 해당 객체에 접근할 수 있는 유일한 부분
- 세부 사항은 드러나지 않도록 하자
- 구현 관점: 클래스의 내부 구현을 바라봄
- 메서드의 구현과 속성의 변경은 외부의 객체에게 영향 미치지 않을 것
- 명세 관점이 설계를 주도하게 하면 설계의 품질이 향상된다!