GRASP vs. SOLID

GRASP vs. SOLID

GRASP 와 SOLID 는 상호 보완적인 객체지향 설계 원칙으로, GRASP 는 " 누가 무엇을 해야 하는가 " 에 대한 구체적인 책임 할당 패턴을 제공하고, SOLID 는 " 어떻게 설계해야 하는가 " 에 대한 포괄적인 설계 원칙을 제시한다. 두 원칙 모두 낮은 결합도, 높은 응집도, 확장성, 유지보수성을 목표로 하며, 현대 소프트웨어 개발에서 필수적인 설계 가이드라인이다.

핵심 개념

GRASP vs. SOLID 비교

GRASP 와 SOLID 는 객체지향 설계에서 서로 다른 측면을 강조한다. GRASP 는 객체에 책임을 어떻게 할당할지를 중심으로 하며, SOLID 는 클래스 설계의 원칙을 통해 코드의 유연성과 유지보수성을 강조한다.

배경 및 목적

특징 비교

핵심 원칙

구현 기법 비교

서로에 대한 강점과 약점

구조 및 아키텍처

GRASP 구조

graph TD
    A[GRASP Patterns] --> B[Information Expert]
    A --> C[Creator]
    A --> D[Controller]
    A --> E[Low Coupling]
    A --> F[High Cohesion]
    A --> G[Polymorphism]
    A --> H[Pure Fabrication]
    A --> I[Indirection]
    A --> J[Protected Variations]
    
    B --> K[클래스 책임 할당]
    C --> K
    D --> L[시스템 이벤트 처리]
    E --> M[의존성 관리]
    F --> M
    G --> N[행위 변화 관리]
    H --> O[도메인 외부 클래스]
    I --> P[간접 참조]
    J --> Q[변화 보호]

SOLID 구조

graph TD
    A[SOLID Principles] --> B[SRP - Single Responsibility]
    A --> C[OCP - Open/Closed]
    A --> D[LSP - Liskov Substitution]
    A --> E[ISP - Interface Segregation]
    A --> F[DIP - Dependency Inversion]
    
    B --> G[단일 변경 이유]
    C --> H[확장 가능, 수정 제한]
    D --> I[서브타입 대체 가능성]
    E --> J[인터페이스 분리]
    F --> K[추상화 의존]
    
    G --> L[유지보수성]
    H --> L
    I --> L
    J --> L
    K --> L

주요 원리 및 작동 원리

GRASP 작동 원리

sequenceDiagram
    participant Client
    participant Controller
    participant Expert
    participant Creator
    
    Client->>Controller: 시스템 이벤트
    Controller->>Expert: 책임 위임
    Expert->>Creator: 객체 생성 요청
    Creator->>Expert: 새 객체 반환
    Expert->>Controller: 처리 결과
    Controller->>Client: 응답

SOLID 작동 원리

graph LR
    A[요구사항 변경] --> B{SRP 검증}
    B -->|OK| C{OCP 적용}
    B -->|위반| D[클래스 분리]
    C -->|확장 가능| E{LSP 검증}
    C -->|수정 필요| F[추상화 도입]
    E -->|대체 가능| G{ISP 적용}
    E -->|위반| H[상속 구조 수정]
    G -->|인터페이스 적절| I{DIP 적용}
    G -->|비대함| J[인터페이스 분리]
    I -->|추상화 의존| K[설계 완료]
    I -->|구체화 의존| L[의존성 역전]

실무 적용 예시

활용 사례

사례 1: 온라인 쇼핑몰 시스템

시나리오: 대규모 온라인 쇼핑몰의 주문 처리 시스템을 설계하는 상황

주요 요구사항:

• 다양한 결제 방식 지원 (신용카드, 계좌이체, 포인트)
• 실시간 재고 관리
• 주문 상태 추적
• 배송 업체별 연동
• 할인 정책 적용

시스템 구성

• GRASP 적용 시스템: Controller 패턴을 통해 주문 처리 로직을 담당하는 객체를 정의하고, Creator 패턴을 통해 주문 객체를 생성하는 책임을 정의한다.

classDiagram
    class OrderController {
        +processOrder(orderData)
        +cancelOrder(orderId)
    }
    
    class Order {
        -orderId: String
        -items: List<OrderItem>
        +calculateTotal(): Money
        +applyDiscount(policy): void
    }
    
    class PaymentProcessor {
        +processPayment(amount, method): boolean
    }
    
    class InventoryManager {
        +checkStock(productId): int
        +reserveStock(productId, quantity): boolean
    }
    
    OrderController --> Order : creates
    Order --> PaymentProcessor : uses
    Order --> InventoryManager : checks

• SOLID 적용 시스템: SRP 를 적용하여 주문 처리 로직과 재고 관리 로직을 분리하고, DIP 를 적용하여 결제 처리 로직과 결제 수단 구현을 분리한다.

classDiagram
    class IPaymentMethod {
        <<interface>>
        +process(amount): boolean
    }
    
    class CreditCardPayment {
        +process(amount): boolean
    }
    
    class BankTransferPayment {
        +process(amount): boolean
    }
    
    class OrderService {
        -paymentMethod: IPaymentMethod
        +processOrder(order): void
    }
    
    class IDiscountPolicy {
        <<interface>>
        +calculate(order): Money
    }
    
    IPaymentMethod <|-- CreditCardPayment
    IPaymentMethod <|-- BankTransferPayment
    OrderService --> IPaymentMethod
    OrderService --> IDiscountPolicy

워크플로우

• GRASP 워크플로우

sequenceDiagram
    participant Client
    participant OrderController
    participant Order
    participant PaymentProcessor
    participant InventoryManager
    
    Client->>OrderController: 주문 요청
    OrderController->>Order: 주문 객체 생성 (Creator)
    Order->>InventoryManager: 재고 확인 (Information Expert)
    InventoryManager-->>Order: 재고 상태
    Order->>Order: 총액 계산 (Information Expert)
    Order->>PaymentProcessor: 결제 처리
    PaymentProcessor-->>Order: 결제 결과
    Order-->>OrderController: 주문 완료
    OrderController-->>Client: 응답

SOLID 워크플로우:

sequenceDiagram
    participant Client
    participant OrderService
    participant IPaymentMethod
    participant IDiscountPolicy
    participant Order
    
    Client->>OrderService: 주문 처리 요청
    OrderService->>IDiscountPolicy: 할인 계산 (DIP)
    IDiscountPolicy-->>OrderService: 할인 금액
    OrderService->>Order: 주문 객체 생성 (SRP)
    OrderService->>IPaymentMethod: 결제 처리 (DIP)
    IPaymentMethod-->>OrderService: 결제 결과
    OrderService-->>Client: 처리 완료

각각의 역할:

• GRASP 에서의 역할
  • Controller: OrderController 가 모든 주문 관련 시스템 이벤트 처리
  • Information Expert: Order 클래스가 주문 정보를 바탕으로 총액 계산
  • Creator: OrderController 가 Order 객체 생성 (주문 데이터를 가지고 있음)
  • Low Coupling: 각 클래스가 최소한의 의존성만 유지
• SOLID 에서의 역할
  • SRP: 각 클래스가 단일 책임 (주문 처리, 결제, 할인)
  • OCP: 새로운 결제 방식 추가 시 기존 코드 수정 없이 확장
  • DIP: OrderService 가 구체 클래스가 아닌 인터페이스에 의존

차이점 분석

실무에서 효과적으로 적용하기 위한 고려사항 및 권장사항

최적화하기 위한 고려사항

주요 문제점과 해결방안

주제와 관련하여 주목할 내용

추가 학습/조사 필요 내용

용어 정리

객체지향 설계 원칙 및 패턴

GRASP 패턴 세부 용어

설계 관련 일반 개념

설계 품질 및 메트릭

참고 및 출처

GRASP (General Responsibility Assignment Software Patterns)

• GRASP (object-oriented design) - Wikipedia
• GRASP Patterns Explained – Kamil Grzybek
• Object-Oriented Design with GRASP – Craig Larman
• GRASP 패턴 상세 설명 – Refactoring Guru
• GRASP Design Principles in OOAD – GeeksforGeeks
• GRASP vs SOLID 비교 – Medium
• GRASP vs SOLID 차이 – DEV.to

SOLID (Object-Oriented Design Principles)

• SOLID Principles - Wikipedia
• SOLID Principles Explained – Baeldung
• SOLID: The First 5 Principles – DigitalOcean
• The SOLID Principles Explained in Plain English – freeCodeCamp
• SOLID 원칙 상세 설명 – Refactoring Guru
• Martin Fowler – SOLID
• Design Patterns over SOLID and GRASP Principles in Real Projects – ResearchGate

공통/일반 객체지향 설계 원칙

• Design Principles in Software Engineering – GeeksforGeeks
• 객체지향 설계 원칙 - Dream Coding
• 객체지향 설계 패턴과 원칙 - DigitalOcean
• SOLID, GRASP, and Other Principles – DZone