Architect 공부 5일차 - 객체지향 설계 원칙

앞전에 OOAD를 통해 분석/설계 방법을 배웠다면, 이제는 설계의 품질을 올리는 과정이다.

좋은 설계의 정답은 없으나, Best Practive는 존재한다.

 

ㅁ 좋은 객체지향 설계를 위한 원칙들

 

1) DRY 원칙

Don't Repeat Yourself

- 같은 코드를 가리키는 이름은 오직 하나여야 한다.

 

2) KISS 원칙

Keep It Simple and Stupid

- 코드를 단순하고 인간이 읽기 쉽게

-- 보통의 메소드를 보면 10줄이 넘어가지 않는다.

 

3) Solid 원칙

 

SOLID

SRP : 단일 클래스가 하나의 책임과 역할만. 여러개의 responsibilite가 있으면 쪼개라

 

OCP : 변경이 최소화되어야한다.

 

LSP : 상속된클래스는 부모클래스를 대체할 수 있어야한다.

 

DIP : 높은 수준의 모듈은 낮은 수준의 모듈에 디펜던시를 가져서는 안된다. 
       디펜던시 뿐만아니라 onwership도 포함.사용하는 패키지로 오너십

 

ISP : 인터페이스가 커지면, 사용자들은 사용하지 않더라도 인터페이스에 종속됨. -> 여러개로 나눌 필요성

※postPayment() operation이 변경될때, Roaster Application은 사용하지 않음에도, 종속관계라 Recompile 필요. 

 

4) GRASP

 

GRASP: General Principles in Assigning Responsibilities

OOAD 과정에서 클래스에 responsibility를 부여하는 설계원칙.

 

Modularity : 좋은 설계란, 시스템을 모듈로 나누고 그에 맞는 Reponsibility가 부여되어있는것

측정 방법으로는 1) Coupling(결합성) 과 2) Cohesion(응집성) 측정

1) Coupling : 디펜던시가 낮으수록 좋다 → 변경의 자유로움과 영향도가 적음 ( loosely coupled )

 

2) Cohesion : 모듈 하나에 대해 평가, 얼마나 연관성 있게 모여있는지 (이해가 쉽고, 재사용이 용이함 )

 

GRASP 9가지 원칙

 

1) Information Expert : responsiblity 부여에 대한 근거 중 Information을 갖고 있는 오브젝트가 타당할 확률이 높다.

 

2) Creator : 특정 인스턴스 생성의 responsiblity를 누가 가질 것인가?

                   아래 조건을 충족할수록 타당함

 

3) Controller : UI Layer에서 넘어온 request를 누가 먼저 받을지에 대한 것

3-1) 시스템 전체를 대표하는 Entity를 두어서 전부 처리하던가

3-2) 유즈케이스, 세션 담당 객체를 만들어서 받던가

 

4) Low Coupling : 굳이 불필요한 Coupling 을 낮추는 방향으로. ( 변경 영향도 ↓ )
                             Global Object는 커플링 상관이 적음

 

5) High Cohension : 높은 응집률을 가지도록 부여

 

6) Pure Fabrication : 기존 오브젝트(도메인 단계에서 나온 오브젝트)에 responsiblity를 부여하기보다는, 디자인단계에서 새로 만들어서 부여

 

7) Polymorphsim : 특정 타입마다 다른 Behavior. 클래스가 많아지고 직관적 이해가 어려워질수는 있음

 

8) Indirection : 중재할 수 있는 객체를 두어, 커플링을 회피

 

9) Protected Variations(PV) : stable한 interface를 만들어서 resoponsibility를 부여