GRASP Design Principles
- General Responsibility Assignment Software Patterns(GRASP)
- 객체지향 소프트웨어 디자인에서 사용되는 기본적이고 범용적인 원칙들을 패턴 형태로 제시
GRASP Design
- 객체지향 프로그램 디자인에서는 책임을 할당하는 것이 매우 중요(변경 가능성과 재사용성을 위함)
- 책임을 할당하는 중요성
- 객체가 수행해야 하는 작업과 역할은 디자인의 핵심 부분이며 이를 올바르게 할당해야함
- 디자인 방향 제공
- 책임 할당은 클래스에 어떤 역할을 부여할 것인지 객체 간 상호 작용을 어떻게 정의할 것인지에 대한 방향 ㅈ공
- 객체와 책임 식별
- 객체와 그들이 수행해야 하는 책임을 식별하는 것은 소프트웨어 디자인의 출발점
- 클래스 결정
- 클래스는 객체의 템플릿이고 공통된 책임집합을 갖는다, 클래스를 결정할때 각각 다른 객체가 어떤 책임을 갖는지 고려해야 함
- 책임을 할당하는 중요성
Responsibilities and Methods
- Responsibility : 책임은 클래스의 계약 또는 의미이고 이를 메서드를 사용하여 구현해야함, 메서드는 단독이나 다른 메서드, 객체와 협력하여 동작
- 책임은 두 가지 유형으로 나눌 수 있음
- Doing Responsibility
- 클래스가 직접 수행하는 작업
- 클래스가 스스로 작업을 수행하거나 다른 객체에 작업을 요청, 다른 객체의 활동을 조정하는 등의 동작을 포함
- 클래스가 실제로 무언가를 수행하는 역할
- Knowing Responsibility
- 클래스가 정보를 알고 있는 역할
- 자체 데이터, 관련된 객체에 대한 정보, 계산된 값을 알고 있는 경우 등
- 클래스가 정보를 제공하거나 검색하는 역할
- Doing Responsibility
자동차 클래스의 운전이라는 책임은 doing responsibility이고 자동차 클래스가 직접 운전을 수행 연료 레벨 확인이라는 책임은 knowing responsibility이며 자동차 클래스가 자체적으로 연료 레벨을 알려주거나 다른 객체로 연료 레벨 정보를 제공
GRASP Patterns
- Low Coupling
- High Cohesion
- Expert
- Creator
- Controller
- Don’t talk to Stranger
Low Coupling
- 결합 : 다른 클래스에 대한 지식을 가지고 있는지 다른 클래스에 의존하는지를 측정하는 지표
- 결합의 측정
- 하나의 클래스나 모듈이 다른 클래스, 모듀렝 얼마나 의존하거나 연결되어 있는지
- 높은 결합도의 문제점
- 연결된 클래스의 변경이 다른 클래스의 변경을 강제할 수 있음
- 개별 클래스를 이해하거나 테스트하기 어렵게 만들 수 있음
- 재사용성의 저하
- 원칙
- 낮은 결합도를 유지하기 위해 책임을 할당할 떄 고려 해야함
- 결합의 측정
High Cohesion
- 응집도 : 클래스 내부의 책임들이 얼마나 관련되어 있고 집중되어 있는지
- 응집도 측정
- 하나의 클래스가 관련된 책임을 가지고 있는 정도 응집도가 높으면 클래스의 책임이 서로 관련되어 있고 중점적, 응집도가 낮으면 클래스의 책임이 서로 관련 없거나 다양한 작업을 수행
- 낮은 응집도의 문제점
- 클래스가 관련 없는 작업을 수행하거나 너무 많은 작업을 처리할 떄 응집도가 낮음
- 이러한 클래스는 이해하기 어렵고, 재사용 및 유지보수에 불리
- 변경에 대한 민감성이 높아지며 코드가 복잡해짐
- 원칙
- 복잡성을 관리하기 위해 책임을 할당할 때 응집도를 높게 유지해야함
- 목적을 명확하게 정의(이것도 응집도를 높이는 방법 중 하나임)
- 쉬운 이해와 유지 관리
- 코드 재사용
- 결합도를 최소화 할 수 있음(결합도와 응집성은 다른 것)
결합성과 응집도
- 응집도 측정
Expert
- expert 패턴 : 책임을 할당하는 데 사용되는 패턴 중 하나, 어떤 클래스에게 책임을 할당할 때 정보 전문가(expert 클래스)에게 그 책임을 할당하는 원칙
- 원칙
- 필요한 정보를 가지고 있는 클래스에게 책임을 할당, expert클래스가 정보를 모두 알기 떄문에 expert클래스가 책임을 할당 받음
- expert클래스는 모든 정보를 가지고 있음, 경우에 따라 다른 클래스와 협력하여 책임을 수행
- 이점
- 캡슐화 유지
- 책임을 할당하는 클래스가 자신의 정보를 사용하므로 클래스가 자체 데이터에 접근하고 조작하기 떄문에 캡슐화 유지
- 낮은 결합도
- 클래스 간의 존속성을 피하므로 결합도가 낮아짐
- 행동 분산
- 특정 행동이 필요한 정보를 가지고 있는 클래스로 분산, 클래스의 코드 이해 및 유지관리에 용이
- 높은 응집도
- 클래스의 책임을 정보와 관련성에 따라 할당하므로 응집도가 높음
- 캡슐화 유지
주문 처리 시스템에서 주문을 취소하는 책임은 주문 정보를 가지고 있는 주문 클래스가 expert역할을 할 수 있음
Expert 패턴에서 책임을 할당하는 클래스가 정보와 관련된 작업을 적절하게 할 수 있으며, 객체간의 협력을 효율적으로 관리 할 수 있음
Creator
- 클래스 간의 생성 관계를 결정하고 어떤 클래스가 다른 클래스의 인스턴스를 생성할 책임을 가질 수 있는지 결정
- 객체 간 연관 및 상호 작용에 기반한 생성자 결정
- 클래스 간의 생성자 역할을 결정할 때 객체 간의 연관과 상호 작용을 고려해서 어떤 클래스가 다른 클래스의 인스턴스를 생성해야 하는지 결정
- 클래스 B가 클래스 A의 인스턴스 생성 책임을 가질 때의 조건
- 클래스 B가 클래스 A의 객체를 집계(aggregates)하거나 포함(contains)하거나 기록(records)하거나 밀접하게 사용(closely uses)하는 경우, 클래스 B에게 클래스 A의 인스턴스를 생성하는 책임을 할당할 수 있음
- 또한, 클래스 B가 클래스 A의 인스턴스를 생성할 때 필요한 초기화 데이터를 가지고 있는 경우, 클래스 B는 클래스 A를 생성하는 전문가(Expert)로 간주됨
- 객체 간 연관 및 상호 작용에 기반한 생성자 결정
Controller
- 외부 이벤트와 내부 이벤트 간의 결합을 관리하기 위한 필요성이 있음
- 해결방향 : controller라는 개체를 만들어 외부 이벤트를 받고 해당 이벤트를 적절한 내부 이벤트 핸들링 개체로 전달하는 책임을 부여
- contoller의 역할
- 시스템 전체를 나타내는 객체
- 시스템 전체의 이벤트 처리와 관련된 외부 이벤트 소스와 내부 이벤트 핸들러간의 관계를 담당
- 유스 케이스를 나타내는 객체
- 특정 유스 케이스에 대한 시퀀스 또는 작업을 처리하는 데 사용
- 시스템 전체를 나타내는 객체
- Solution(이벤트 처리를 다루는 책임에 따른 클래스 할당)
- 전체 시스템을 나타내는 클래스
- 시스템 전체의 이벤트 처리 및 관리를 담당하는 클래스, 시스템의 외부 이벤트를 내부 이벤트 핸들링 객체로 조율
- 전체 비즈니스 또는 조직을 나타내는 클래스
- 조직 전반의 이벤트 처리를 관리하는 클래스, 시스템의 핵심 비즈니스 로직을 제어
- 실제 세계에서 활동 중인 것을 나타내는 클래스
- 실제 세계에서 활동중인 역할 또는 개체를 나타내는 클래스로 해당 역할의 이벤트 처리를 담당
- 유스 케이스의 모든 시스템 이벤트를 처리하는 인공 핸들러 클래스
- 시스템 이벤트 처리를 담당하는 클래스(실질적 핸들러)
- 전체 시스템을 나타내는 클래스
- 이점
- 컨트롤러 클래스의 재사용
- 컨트롤러 클래스는 시스템, 비즈니스 로직을 캡슐화, 이는 재사용 가능
- 유스 케이스 관리
- 활동 순서 제어
- 컨트롤러 클래스의 재사용
Don’t talk to Stranger
- 클래스 간의 직접적인 상호 작용을 피하고 간접적인 통신을 통해 결합도를 낮추는 방법
- 두 개의 클래스가 필수적이지 않다면 직접적으로 상호 작용하면 안 됨, 한 클래스가 다른 클래스의 메서드를 직접 호출하는 대신 중간계층의 다른 클래스를 통해 호출 해야함
- 효과
- 전체적인 결합도를 낮추는 효과
KMU SW