4장에서 데이터 중심 설계의 문제점을 살펴보았습니다.
이를 통해 객체지향 설계에서 가장 중요한 과정 중 하나는 객체에 올바른 책임을 할당하는 것임을 배웠습니다.
5장은 책임 중심 설계의 본질과,, 이를 실현하는 데 필요한 GRASP 패턴이 등장합니다.
책임 중심 설계의 기본 원리를 살펴보고, GRASP 패턴을 통해 객체 간 협력을 효과적으로 설계하는 방법을 학습합니다. 객체지향 설계의 본질을 다시 한번 이해할 수 있는 기회가 되었던 것 같습니다.
데이터 중심 설계와 책임 중심 설계의 차이
데이터 중심 설계는 객체의 책임보다는 데이터를 먼저 고려하는 방식이라고 했습니다.
겉보기에 간단해 보이지만, 이 방식은 캡슐화를 해치고, 객체 간의 결합도를 높이며, 설계를 복잡하게 만듭니다.
반대로 책임 중심 설계는 "이 객체가 어떤 행동을 해야 하는가?"라는 질문에서 출발합니다.
이렇게 설계하면 데이터 중심 설계와 반대로 객체 간의 관계를 단순화하고 유연성을 높일 수 있습니다.
이전에 학습했던 영화 예매 시스템을 복기해봅시다..
만약 데이터 중심 설계로 이 시스템을 만든다면, Movie 객체가 단순히 데이터를 저장하는 역할만 할 것이고, 책임 중심 설계에서는 동일한 객체가 요금을 계산하는 책임을 가집니다. 이러한 차이들이 최종적으로 설계의 품질을 크게 좌우합니다.
책임 중심 설계의 핵심
책임 중심 설계에서 가장 중요한 것은 책임을 올바르게 정의하고 분배하는 것입니다.
객체는 데이터를 단순히 저장하는 도구가 아니라, 협력 속에서 역할을 수행하는 존재입니다.
책임을 올바르게 정의하기 위해 앞 장에 이어서 생각해본 질문들입니다.
- 이 객체가 처리해야 할 주요 입력과 출력은 무엇인지?
- 이 객체가 어떤 메시지에 응답해야 할지?
- 이 객체는 협력 과정에서 어떤 역할을 수행해야 하는지?
이러한 보다 구체적인 질문을 통해, 설계가 더 명확해질 수 있을것이라고 생각합니다.
책임 주도 설계의 흐름
1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
2. 시스템 책임을 더 작은 책임으로 분할한다.
3. 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
4. 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
5. 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.
위의 흐름을 잘 익히고 있어야 하겠습니다.
흐름 사이에 구체적인 질문을 통해 자문한다면 보다 우수한 설계의 프로그램을 구현할 수 있지 않을까 합니다.
GRASP 패턴과 책임 중심 설계
저자는 책임 중심 설계를 효과적으로 구현하기 위해 GRASP 패턴을 제시했습니다. GRASP는 "General Responsibility Assignment Software Patterns"의 약자로, 객체의 책임을 정의하고 할당하는 데 필요한 설계 지침이라는 뜻입니다. 대표적인 GRASP 패턴은 아래와 같습니다:
- Information Expert (정보 전문가)
- 특정 작업을 수행하는 데 필요한 데이터를 가장 잘 알고 있는 객체가 그 책임을 맡는다.
- 예를 들어 Movie 객체가 요금을 계산하는 이유는 관련 데이터를 보유하고 있기 때문입니다.
- 특정 작업을 수행하는 데 필요한 데이터를 가장 잘 알고 있는 객체가 그 책임을 맡는다.
- Low Coupling (낮은 결합도)
- 객체 간 의존성을 최소화하여 시스템의 유연성을 높인다.
- 데이터 중심 설계에서는 모든 객체가 데이터를 공유하기 때문에 결합도가 높아지는 반면, 책임 중심 설계에서는 각 객체가 독립적으로 동작한다.
- High Cohesion (높은 응집도)
- 객체 내부의 요소들이 하나의 책임에 집중하도록 설계한다.
- Creator(생성자): 객체 생성의 책임을 가장 적합한 객체에 할당합니다. Creator 패턴은 객체 생성과 관련된 책임을 명확히 하여 설계의 일관성을 유지합니다.
- 생성할 객체와 강한 연관성을 가진 객체에 생성 책임 부여
- 생성 책임의 집중: 객체 생성의 책임을 특정 객체에 집중시킴으로써, 코드 중복을 방지하고 결합도를 줄입니다.
- Polymorphism(다형성): 변화하는 행동이나 알고리즘을 다형성을 통해 캡슐화하여 설계의 유연성을 높임.
- 같은 메시지, 다른 행동: 다형성은 여러 객체가 같은 메시지에 대해 서로 다른 동작을 수행하도록 허용.
- Protected Variations(보호 변이)
- 변화를 미리 예상하고, 설계의 취약점을 최소화하기 위해 보호 장치를 추가.
- 인터페이스를 통한 안정성 확보: 인터페이스나 추상화를 사용하여 변화의 영향을 최소화합니다.
개인적으로 낯선 개념이 많이 등장한 부분이었습니다.
유용하게 사용할 개념들인 것 같아 따로 정리해봤습니다.
코드의 구조가 도메인의 구조에 대한 통찰을 제공한다는 부분에서, 코드 설계는 단순한 구현을 넘어 도메인의 본질과 규칙을 드러내는 중요한 역할을 한다는것을 다시금 느꼈습니다.
코드를 통해 도메인 객체의 역할과 관계를 이해할 수 있다면, 시스템의 복잡한 요구사항을 명확히 파악하고 더 나은 설계를 도출할 수 있다는 점이 인상깊었습니다.
이번 장에서는 개인적으로 처음 접해보는 GRASP 패턴을 통해 책임을 명확히 정의하고 할당함으로써, 더 유연하고 유지보수성이 높은 설계를 실현할 수 있음을 배웠습니다. 특히 코드의 구조를 통해 도메인의 본질을 드러낼 수 있다는 점에서 설계의 중요성을 다시 한번 느꼈던 것 같습니다.
'OBJECT' 카테고리의 다른 글
| 오브젝트 챕터7<객체 분해> (3) | 2025.01.22 |
|---|---|
| 오브젝트 챕터6<메시지와 인터페이스> (2) | 2025.01.15 |
| 오브젝트 챕터4<설계 품질과 트레이드오프> (0) | 2025.01.04 |
| 오브젝트 챕터3<역할, 책임, 협력> (2) | 2024.12.27 |
| 오브젝트 챕터2<객체지향 프로그래밍> (2) | 2024.12.16 |