GRASP: General Principles in Assigning Responsibilities 란?
객체 설계와 책임 할당의 9가지 원칙을 설명한다.
도메인 내에서 어떻게 하면 적절하게 모듈을 나누고 책임을 할당할지에 대한 설계 철학이라고 할 수 있다.
1. Creator
문제 인식 : 누가 객체 A를 생성할 책임을 가질 것인가?
해결책 : 아래의 조건을 만족하는 클래스가 그 책임을 가져갈 후보가 된다.
- A 객체를 포함하고 있다.(contain, aggregate)
- A 객체의 정보를 기록(Record)하고 있다.
- A 객체를 사용하고 있다.
- A 객체가 초기화에 필요한 정보를 가지고 있다.
예를들어 아래와 같은 관계인 경우 SmartPhoneFactory가 SmartPhone객체를 생성할 책임을 가지는 후보가 될 수 있다.
2. Imformation Expert Pattern
문제 인식 : 책임을 부여하기 위한 기본 원칙은 무엇인가?
해결책 : 어떤 처리를 하기 위해 가장 많은 정보를 가지고 있는 클래스가 그 책임을 가져간다.
예를들어 SmartPhoneFactory에서는 외부에서 Total Price요청에 대한 처리를 해야하기 때문에 전체 생상된 스마트폰의 가격을 구하는책임을 가져간다.
SmartPhone의 경우 기기의 Price요청에 대한 처리를 해야하기 때문에 getPrice를 통해 가격 정보를 처리할 책임을 가져간다.
3. Controller
문제 인식 : (UI가 있는 시스템에서) 누가 UI에서 발생하는 이벤트를 처리할 책임을 가질 것인가?
해결책 :
1. 시스템이 작은 경우에는 시스템 전체를 대표하는 하나의 컨트롤러를 만들고 책임을 부여 (facade controller)
2. 시스템이 큰 경우에는 use case에 따라 컨트롤러를 만들고 책임을 부여(use cases controller)
결론적으로 GUI에서는 어플리케이션 로직으로 부터 자유로워 진다.
4. Low Coupling
문제 인식 : 어떻게 하면 변화(수정)에서 파생하는 영향을 줄일 수 있을까.
해결책 : 클래스 간의 관계를 파악하고 불필요한 의존성을 줄인다.
예를 들어 그림1과 같이 PackageBox를 SmartPhoneFactory에서 관리한다고 가정해보자
그림1.
위와 같이 표현되는게 현실 세계에서는 논리적일 수도있다. 그러나 OOP설계에서 발생할 수 있는 문제점은
SmartPhoneFactory가 PackageBox와 커플링이 생겨서 PackageBox의 변화(수정)에 영향을 받는다는 점이다.
따라서 현실 세계에서는 조금 어색할 수 있지만 아래의 그림2와 같이 커플링을 줄이는 설계도 고려할 수 있다.
그림2.
5. High Cohesion
문제 인식 : 어떻게 하면 책임을 분산하여 객체의 응집도를 높일까.
해결책 : 객체가 너무 많은 일을 한다면 책임을 분산해본다. 또한 Low Coupling원칙을 지키면 자연스럽게 응집도도 높아질 수 있다.
6. Pure Fabrication
문제 인식 : Information Expert원칙을 지키면서 Low Coupling과 High Cohesion이 깨질 때
예를 들어 Information Expert원칙을 지키면서 책임을 부여 받은 객체에서 각자의 구현을 통해 DB를 사용하는경우
어떻게 보면 DB를 각자 구현하는게 Information Expert원칙을 지키는거이지만 Low Coupling과 High Cohesion이 깨지게 된다.
해결책 : 새로운 역할(DB등)을 부여해서 클래스를 만든다.
7. Polymorphism
문제 인식 : 분기문 없이 다양한 행동에 대한 책임을 어떻게 부여할 것인가.
해결책 : OOP에서 제공하는 다형성(polymorphism)을 이용하여 다양한 타입에 따라 다른 행동을 가능하게 한다.
아래의 예처럼 MobileMusicPlay인터페이스의 playMusic메소드의 다형성을 통해 각각의 클래스마다 다른 행동을 부여할 수 있다.
8. Indirection
문제 인식 : 어떻게 두 객체간의 직접적인 커플링 없이 책임을 부여할 수 있을까.
해결책 : A와 B 객체 사이에 중간객체를 둔다.
예를 들면 A객체(client)와 B객체(AndroidMusicPlayer)사이에 중간객체(MobileMusicPlayer)를 두어 직접적인 커플링을 없앨 수 있다.
Direct하게 커플링이 생긴경우
중간객체를 통해 직접적인 커플링을 없앰
9. Protected Variations
문제 인식 : 어떻게 변화에 대응할 것인가.
해결책 : SOLID의 OCP와 같은 원칙이며 변화가 발생했을 때 다른곳에 영향을 준다면 인터페이스를 활용한다.
'객체지향프로그래밍' 카테고리의 다른 글
[SOLID 원칙] 5. Dependency Inversion Principle 의존관계 역전 원칙 (0) | 2022.01.16 |
---|---|
[SOLID 원칙] 4. Interface Segregation Principle 인터페이스 분리 원칙 (0) | 2022.01.16 |
[SOLID 원칙] 3. Liskov Substitution Principle 리스코프 치환 원칙 (0) | 2022.01.09 |
[SOLID 원칙] 2. Open Closed Principle 개방-폐쇄 원칙 (0) | 2022.01.09 |
[SOLID 원칙] 1. Single Responsibility Principle 단일 책임 원칙 (0) | 2022.01.09 |