설계 원칙 SOLID

이전 글에서 설명 한 적 있으니 간단히 이름만 읊고 넘어가자

• SRP: Single responsibility principle
  단일 책임 원칙
• OCP: Open/closed principle
  개방 폐쇄 원칙
• LSP: Liskov substitution principle
  리스코프 치환 원칙
• ISP: Interface segregation principle
  인터페이스 분리 원칙
• DIP: Dependency inversion principle
  의존성 역전 원칙

GRASP 패턴

General Responsibility Assignment Software Pattern

일반적인 책임 할당을 위한 소프트웨어 패턴

객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리한 것

5 가지의 기본 패턴과 4가지의 추가 패턴이 있다

1. 정보 담당자 Information Expert

• 객체를 정보 담당자로 만들어라 (객체에 담긴 정보는 객체 자신이 처리하라)
• 정보 담당자(객체)에게 책임을 부여하고 메시지(Interface)로 접근하게 하라

객체를 캡슐화 하여 객체의 정보를 은닉하라

📌 여기서 '정보' 란, 데이터와 다르다는 사실에 주의하라. 책임을 수행하는 객체가 정보를 '알고' 있다고 해서 그 정보를 '저장' 하고 있을 필요는 없다. 객체는 해당 정보를 제공할 수 있는 다른 객체를 알고 있거나 필요한 정보를 계산해서 제공할 수도 있다.

2. 낮은 결합도 Low Coupling

설계 결정을 평가할 때 적용할 수 있는 평가 원리다

• 설계의 전체적인 결합도를 낮게 유지하여 상호 의존도를 낮춰라
• 객체 간의 결합이 없을 수는 없다. 낮게 유지하려 노력해라
• 현재의 책임 할당을 검토하거나 여러 설계 대안들이 있을 때 낮은 결합도를 유지할 수 있는 설계를 선택하라

3. 높은 응집도 High Cohesion

이것도 설계 결정을 평가할 때 적용할 수 있는 평가 원리이다

• 한 객체를 변경할 때 변경의 요소들을 모아, 높은 응집도를 유지하라
• SRP 를 준수하라

4. 창조자 Creator

객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침이다

객체 A 를 생성해야 할 때, 아래 조건을 최대한 많이 만족하는 B 에게 객체 생성 책임을 할당하라

• B 가 A 객체를 포함하거나 참조한다
• B 가 A 객체를 기록한다
• B 가 A 객체를 긴밀하게 사용한다
• B 가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다(이 경우 B 는 A 에 대한 정보 담당자다)

이미 개념적으로 결합되어 있는 객체에게 생성 책임을 할당해도 설계의 전체적인 결합도에 영향을 미치지 않는다

5. 관리자 Controller

• 모듈 혹은 서브 시스템에서 사용자의 요청을 처리할 서브 시스템 관리자를 만들어라
• 다른 모듈에서 해당 모듈의 관리자만 알면 해당 기능을 문제없이 이용할 수 있게 하라

관리자 내부의 변경이 외부의 다른 모듈들에게 영향이 없도록 하라

관리자가 가진 정보를 외부로 노출시키지 마라

6. 다형성 Polymorphism

대체 가능한 소프트웨어 구성 요소를 생산하는 방법

• 다형성을 활용하여 조건문을 최소화 하라

7. 순수 허구 Pure Fabrication

정보 담당자 Information Expert 패턴을 적용하여 객체를 설계했다. 그럼 데이터베이스에 입력하는 동작은 어떤 객체가 수행해야 하는가

만약 각각의 데이터가 자신을 데이터베이스에 저장한다면 저장 로직과 엔티티 사이의 결합도는 높아지고 응집도는 낮아진다

• 공통적인 기능을 제공하는 책임을 한 곳으로 모아서 가상의 서브 시스템을 만들어라

8. 우회 Indirection

두 개의 객체 간의 직접적인 커플링을 피하기 위한 패턴

• 두 객체 사이에 다른 매개체를 통해 전달하라

9. 보호된 변경 Protected Variations

설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화 하라

• 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라

GoF Gang of Four

패턴의 요소

이 책에서는 총 24 가지 패턴을 설명한다

• 이름 pattern name
  디자인 패턴은 각각 고유의 이름을 갖고 있다
• 문제 problem
  각 패턴은 문제 해결을 고려해야 하는 시점을 암시한다
• 해법 solution
  객체 요소간 관계를 정리하고 패턴은 객체들을 추상화하는 과정을 소개한다
• 결과 consequence
  디자인 패턴이 모든 문제를 해결 할 수는 없다. 꼭 필요한 경우를 생각해서 적절히 분배하여 사용해야 한다

유지보수

유지보수적 측면에서 디자인 패턴 사용을 고려해 볼 수 있다

소프트웨어의 수명

유지 보수성이 좋아진다

방어적 설계

변경 가능한 디자인으로 설계 해야 한다

소프트웨어는 방어적 설계를 위해 지속적으로 코드를 개선하는 리팩토링 작업을 실시한다

정리

디자인 패턴과 처리 성능을 별개의 문제

디자인 패턴에서는 코드의 가독성과 유지 보수를 위해 객체의 메서드를 분리하며 호출도 자주 발생한다

패턴을 너무 많이 사용하면 잦은 메서드 호출로 인해 성능이 저하될 수 있다