GRASP Design (객체 지향 원칙)

General Responsibility Assignment Software Patterns(GRASP)

객체지향 디자인 원칙

어떤 Object가 어떤 Responsibility?

1. Identify the requirements
2. Create a domain model
3. Create design model(Add attributes and methods to the software classes)

GRASP: Assign responsibilities to collaboratingn objects

Responsibility = "A contract or obligation of a class"
Responsibiltly를 구현하기 위하여 클래스에 있는 여러 Method가 조합을 이룬다.

1. Knowing responsibility

• About (private encapsulated data, related objects,
  things it can derive or calculate)
• Domain 에서 Key concept이 Design 단계의 클래스를 만드는데 도움을 줌.
• ex) Sale is responsible for knowing its total

2. Doing Responsibility

• 수행과 관련되어 있다.
• 다른 객체를 초기화하거나 다른 객체를 Controlling or coordinating
• ex) Sale is responsible for creating SalesLineItems

---

Craig Larman's 9 principles

1. Modularity

• 디자인의 목표는 system을 module로 partition하고 responsibility를 부여하는 것.
• Modularity는 프로그래머가 한 순간에 다뤄야 하는 전체적인 복잡성을 줄인다.
  • (Seperation of Concerns, Information Hiding)
• Measure Modularity
  • coupling: 모듈들 간의 inter-dependencies (낮을 수록 좋음) loose coupling
    • attribute referencing
    • method referencing
    • subclass(direct or indirect)
    • implements
  • cohesion: 모듈 안의 element간의 연관성 (높을 수록 좋음)
    • Single Responsibility Principle(SRP)와 연관되어 있다.

Pattern

1.Creator Pattern

Who creates an A.

-  Assgin class B the responsibility to create an instance of class A, if one of these is true
-  **B contains or aggregates A**
-  B records A
- B closely uses A
-   B has the initializing data for A
-  Contradiction
-  family or similar classes 로 부터 생성될 때
-  recycled instances for performance reasons(Singleton
-  outsource object wiring (갈아 끼우기)
-  \_Sales\_가 \_SalesLineItem\_을 생성

2. Information Expert Pattern

        -   Assign a responsibility to the class that has the information needed to fulfill it.
        -   가장 자주 쓰이는 principle
        -   정보는 여러 객체에 흩어져있으므로 interact가 필요하므로 seperation of concern과 conflict  
            \*DataBase Logic을 처리하는 쿼리를 각각의 클래스가 모두 가지고 있다면 Information Expert Pattern이지만 low cohesion 발생.
        -   Who should be responsible for knowing the grand total of a sale?
        -   Sale클래스가 SalesLineItem에 대한 전체 금액을 알고 있는게 맞다.

3. Controller Pattern

   • UI Layer에서 벗어나서 system operation과 coordinate하기 위한 첫번째 객체는?
   • 두 가지 Option
     1. 전체 시스템에 대한 Controller (Facade Controlloer)
        단점: 점점 많아지면 Cohesion이 떨어짐
     2. Use case senario별로 Controller. (XXHandler)
   • UI에 application logic을 두지 않도록 만들어준다.
   • Use case의 상태에 따른 추론이 가능하다. MakePayment는 EndSale전에 실행되지 않음.

4. Low Coupling Pattern

   • How to reduce the impact of change?
   • 대안에 대해서 평가할 때 사용하는 principle.
   • Ex) MakePayment 메소드 호출이 되었을 때, Creator Pattern에 의하면 Register는 Payment를 Record하니까 Payment를 만들어야 한다. 그러나 Register와 Payment간의 관계가 만들어지므로 makePayment 요청을 Sale 객체에 위임하고 Sale에서 Payment를 만들 경우, 해당 Coupling을 없앨 수 있다.
   • stable global 한 객체는 high coupling이여도 상관없다. java.util
   • High coupling은 application의 object간의 문제.

5. Hgih Cohesion Pattern

6. Pure Fabrication Pattern

   • Who is responsible when you are desperate, and do not want to violate high cohesion and low coupling.
   • 도메인 모델에서 파악된 Concept이 아닌 responsiblity를 처리할 새로운 클래스 생성. DB쿼리 처리

7. Polymorphism Pattern

   • Who is responsible when behavior varies by type?
   • using polymorphic operations
   • Explicit Selection 보다 logic이 단순하다.
   • 대신 읽기 어렵고 클래스 수가 증가한다.
   • Agile에서는 과도하게 Variation을 하는 것은 좋지 않다.

8. Indirect Pattern

   • Direct coupling을 만들고 싶지 않을 때, 어떻게 responsibility를 부여할 것인가?
   • Sale에서 세금을 계산하는 경우에 외부의 TaxMasterSystem에 의해서 직접적으로 연결하는 대신에 adaptor 객체를 두고 두 Class 간의 통신을 돕는 역할을 할 수 있다.

9. Protected Variations Pattern

   • varation이 일어날 때, 다른 element에 impact를 줄이는 방법
   • Predicted variation이나 instability에 대하여 포인트를 한다.
   • OCP(Open close Principle): 기능 확장에 대해서는 열려있고 기존 코드 수정은 닫혀있다.
   • OCP는 PV와 동일한 방법이다.
   • C#에서 filed와 method에 대한 접근 방법이 동일하므로 protection도 동일하게 할 수 있다.

Objecct Design Examples with GRASP

Use Case Realization

Design Model에서 어떻게 use case가 실현되는지 objects의 collaborating을 통해 묘사한다.
UI Layer에서 Domain Layer로 넘어갈 때, Use case의 내용이 어떻게 domain layer에서 상호작용하는가?

• Key point: The system operaitons in the SSDs are used as the starting messages into the domain layer controller objects.

• Operation contract: use case realization은 use case text로부터 디자인될 수 있다. 만일 complex system operations의 경우라면 operation contracts를 쓰기도 한다.

Visibility

Visibility from obejct A to object B
* Parameter visibility: B is a parameter of a method of A, UML dependen cy
* Local visibiltiy: B is a local object in a method of A, UML dependency
* Attribute visibility: B is an attribute of A, UML association
* Global visibility: B is in some way globally visible, UML association

Mapping Designs to Code

• DCD(Domain Class Diagram)에서 Class Definition 생성
• Collection Classes in Code: Map, List, Array
• Order of Implementation: from least-coupled to most-coupled
• incoming arrow만 있을 경우, implemenation할 때, 다른 클래스를 쓸 필요 없다.