전통적인 소프트웨어 개발 방법
- 변경이 반번하게 발생하는 기능에 안정적인 구조를 종속시키는 길을 묻는 방법
- 길찾기라는 기능을 위한 지도를 그리는 방식
객체지향 개발 방법
- 안정적인 구조에 변경이 빈번하게 발생하는 기능을 종속시키는 방법
- 안정적인 지도 위에서 길찾기라는 기능을 구현
기능 위주 개발 : To-Do list에서의 "작업 추가", "작업 수정", "작업 삭제", "작업 조회"와 같은 독립된 기능 단위
구조 위주 개발 : 사용자 인터페이스(프런트엔드), 비즈니스 로직(서비스 레이어), 데이터베이스(데이터 액세스 레이어)로 나누어 구성
자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라
미래의 변경에 대비할수는 있지만, 예측할 수는 없다
객체 지도는 안정적이면서 재사용 가능하며 범용적이다. 객체를 이용해 지도를 만들어라. 기능은 지도에 표시된 길을 따라 자연스럽게 흘러갈 것이다.
도메인 모델
사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
- 은행원 - 고객과 계좌 사이의 돈의 흐름
- 중고차 거래 - 구매되는 자동차와 판매되는 자동차와 돈의 교환과정
도메인 모델의 최종 제품은 사용자의 관점을 반영해야 한다는 점. 사용자의 관점을 모델링하기 가장 최적화되고 범용화 된 모델링 패러다임이 객체지향.

사용자 모델에 포함된 개념과 규칙(그림에서 도메인 모델 속 개념과 관계)은 거의 변경되지 않는다. 따라서, 개념과 규칙을 바탕으로 코드를 작성하면 향후 변경에 용이하다.
Use-Case Diagram
사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있다
UML 2.0의 Communication Diagram
OOAD 중, 설계 단계에서 사용 - Use Case 분석 이후, Sequence Diagram과 같이 병행
코드는 세 가지 관점을 모두 제공해야 한다.
- 개념 관점 - 실제 세계에서의 개념과 가깝게 생각하는 것(도메인 개념과 규칙)
- 소프트웨어와 도메인의 간격이 좁을수록 요구자의 변경 사항을 수용하기 용이함
- 명세 관점 - 코드가 수행해야 할 기능과 요구 사항을 다루는 관점
- 인터페이스. 해당 객체들이 도메인에 최대한 맞게 행동하는 것
- 구현 관점 - 코드의 작성 및 동작 방식을 다루는 관점
- 클래스 내부 구현. 캡슐화 등이 잘 되어 있는지
'책 > 객체지향의 사실과 오해' 카테고리의 다른 글
5장 Part2. 인터페이스 (0) | 2025.01.01 |
---|---|
5장 Part1. 책임과 메시지 (1) | 2025.01.01 |
4장. 역할, 책임, 협력 (0) | 2025.01.01 |
3장. 타입과 추상화 (0) | 2025.01.01 |
2장. 이상한 나라의 객체 (2) | 2025.01.01 |
전통적인 소프트웨어 개발 방법
- 변경이 반번하게 발생하는 기능에 안정적인 구조를 종속시키는 길을 묻는 방법
- 길찾기라는 기능을 위한 지도를 그리는 방식
객체지향 개발 방법
- 안정적인 구조에 변경이 빈번하게 발생하는 기능을 종속시키는 방법
- 안정적인 지도 위에서 길찾기라는 기능을 구현
기능 위주 개발 : To-Do list에서의 "작업 추가", "작업 수정", "작업 삭제", "작업 조회"와 같은 독립된 기능 단위
구조 위주 개발 : 사용자 인터페이스(프런트엔드), 비즈니스 로직(서비스 레이어), 데이터베이스(데이터 액세스 레이어)로 나누어 구성
자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라
미래의 변경에 대비할수는 있지만, 예측할 수는 없다
객체 지도는 안정적이면서 재사용 가능하며 범용적이다. 객체를 이용해 지도를 만들어라. 기능은 지도에 표시된 길을 따라 자연스럽게 흘러갈 것이다.
도메인 모델
사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
- 은행원 - 고객과 계좌 사이의 돈의 흐름
- 중고차 거래 - 구매되는 자동차와 판매되는 자동차와 돈의 교환과정
도메인 모델의 최종 제품은 사용자의 관점을 반영해야 한다는 점. 사용자의 관점을 모델링하기 가장 최적화되고 범용화 된 모델링 패러다임이 객체지향.

사용자 모델에 포함된 개념과 규칙(그림에서 도메인 모델 속 개념과 관계)은 거의 변경되지 않는다. 따라서, 개념과 규칙을 바탕으로 코드를 작성하면 향후 변경에 용이하다.
Use-Case Diagram
사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있다
UML 2.0의 Communication Diagram
OOAD 중, 설계 단계에서 사용 - Use Case 분석 이후, Sequence Diagram과 같이 병행
코드는 세 가지 관점을 모두 제공해야 한다.
- 개념 관점 - 실제 세계에서의 개념과 가깝게 생각하는 것(도메인 개념과 규칙)
- 소프트웨어와 도메인의 간격이 좁을수록 요구자의 변경 사항을 수용하기 용이함
- 명세 관점 - 코드가 수행해야 할 기능과 요구 사항을 다루는 관점
- 인터페이스. 해당 객체들이 도메인에 최대한 맞게 행동하는 것
- 구현 관점 - 코드의 작성 및 동작 방식을 다루는 관점
- 클래스 내부 구현. 캡슐화 등이 잘 되어 있는지
'책 > 객체지향의 사실과 오해' 카테고리의 다른 글
5장 Part2. 인터페이스 (0) | 2025.01.01 |
---|---|
5장 Part1. 책임과 메시지 (1) | 2025.01.01 |
4장. 역할, 책임, 협력 (0) | 2025.01.01 |
3장. 타입과 추상화 (0) | 2025.01.01 |
2장. 이상한 나라의 객체 (2) | 2025.01.01 |