Program Against Abstractions

Program Against Abstractions

Program Against Abstractions(추상화에 대하여 프로그래밍하라) 는 소프트웨어 아키텍처 및 설계에서 핵심 원칙 중 하나로, 구체적인 구현체가 아닌 추상화 계층 (인터페이스, 추상 클래스 등) 에 의존해 코드를 작성하는 것을 의미한다. 이 원칙은 시스템의 결합도를 낮추고, 변화에 유연하게 대응할 수 있도록 하며, 유지보수와 테스트, 확장성을 크게 향상시킨다. 객체지향 설계의 DIP(의존성 역전 원칙) 와도 밀접하게 연관되어 있다.

핵심 개념

Program Against Abstractions란 코드를 작성할 때 구체적인 구현체가 아니라, 인터페이스나 추상 클래스 등 추상화 계층에 의존하도록 설계하는 것이다.

Program Against Abstractions의 핵심 개념들:

1. 추상화 (Abstraction): 구현 세부사항을 숨기고 본질적인 특성만을 노출하는 개념
2. 구체화 (Concretion): 실제 구현을 포함한 구체적인 클래스나 모듈
3. 의존성 역전 (Dependency Inversion): 고수준 모듈이 저수준 모듈에 의존하지 않고 추상화에 의존하는 원칙
4. 인터페이스 (Interface): 구현을 강제하는 계약을 정의하는 추상화 도구
5. 느슨한 결합 (Loose Coupling): 컴포넌트 간의 의존성을 최소화하는 설계 방식

배경

역사적 배경:

• 1990 년대 객체지향 프로그래밍의 발전과 함께 등장
• Robert C. Martin(Uncle Bob) 이 SOLID 원칙의 일부로 체계화
• 소프트웨어 복잡성 증가에 따른 유지보수성 문제 해결을 위해 발달

등장 배경:

• 전통적인 하향식 설계에서 발생하는 강한 결합 문제
• 코드 변경 시 연쇄적인 수정이 필요한 상황
• 테스트 가능성과 재사용성의 필요성 증대

목적 및 필요성

주요 목적:

1. 유연성 확보: 구현체 변경 시 클라이언트 코드 수정 최소화
2. 확장성 향상: 새로운 구현체 추가 시 기존 코드 영향 최소화
3. 테스트 용이성: Mock 객체를 활용한 단위 테스트 가능
4. 재사용성 증대: 다양한 구현체와 함께 사용 가능한 코드 작성

필요성:

• 대규모 소프트웨어 시스템의 복잡성 관리
• 지속적인 요구사항 변경에 대응
• 팀 개발 환경에서의 모듈 독립성 확보
• 소프트웨어 품질 및 유지보수성 향상

주요 기능 및 역할

1. 의존성 관리: 컴포넌트 간 의존성을 추상화 계층으로 관리
2. 변경 격리: 구현 변경이 다른 컴포넌트에 미치는 영향 차단
3. 인터페이스 정의: 명확한 계약을 통한 컴포넌트 간 상호작용 정의
4. 확장성 제공: 새로운 기능 추가 시 기존 코드 변경 최소화

핵심 원칙

1. 추상화 의존 원칙: 구체적인 클래스가 아닌 추상화에 의존
2. 인터페이스 분리 원칙: 클라이언트가 사용하지 않는 메서드에 의존하지 않음
3. 대체 가능성 원칙: 추상화를 구현한 모든 객체는 상호 교체 가능
4. 단일 책임 원칙: 각 인터페이스는 하나의 명확한 책임만 가짐

주요 원리

graph TD
    A[클라이언트 코드] --> B[추상화 계층]
    B --> C[구현체 A]
    B --> D[구현체 B]
    B --> E[구현체 C]
    
    F[고수준 모듈] --> G[인터페이스]
    H[저수준 모듈] --> G
    
    style B fill:#e1f5fe
    style G fill:#e1f5fe

핵심 원리:

1. 의존성 역전: 고수준과 저수준 모듈 모두 추상화에 의존
2. 추상화 안정성: 추상화는 구체화보다 안정적
3. 계약 우선: 구현보다 인터페이스 계약을 우선시
4. 느슨한 결합: 컴포넌트 간 직접적인 의존성 제거

작동 원리

sequenceDiagram
    participant Client as 클라이언트
    participant Interface as 인터페이스
    participant Implementation as 구현체
    
    Client->>Interface: 메서드 호출
    Interface->>Implementation: 실제 구현 실행
    Implementation-->>Interface: 결과 반환
    Interface-->>Client: 결과 전달

작동 메커니즘:

1. 인터페이스 정의: 필요한 기능을 추상 메서드로 정의
2. 구현체 작성: 인터페이스를 구현하는 구체적인 클래스 작성
3. 의존성 주입: 클라이언트에 인터페이스 타입으로 구현체 제공
4. 런타임 바인딩: 실행 시점에 실제 구현체 메서드 호출

작동 원리 및 구조

• 클라이언트 (사용자) 는 인터페이스 (추상화) 에 의존.
• 실제 구현체는 인터페이스를 구현 (implements) 하여 제공.
• 클라이언트는 구현체의 세부사항을 몰라도 인터페이스를 통해 기능 사용.

classDiagram
    class IService {
        <<interface>>
        +execute() : Result
        +validate() : boolean
    }
    
    class ServiceA {
        +execute() : Result
        +validate() : boolean
    }
    
    class ServiceB {
        +execute() : Result
        +validate() : boolean
    }
    
    class Client {
        -service : IService
        +Client(service: IService)
        +performAction() : void
    }
    
    IService <|-- ServiceA
    IService <|-- ServiceB
    Client --> IService

구현 기법

인터페이스 기반 설계

정의: 모든 의존성을 인터페이스로 정의하는 기법
구성: 인터페이스 + 구현체 + 클라이언트
목적: 강한 결합 제거 및 유연성 확보

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 인터페이스 정의
from abc import ABC, abstractmethod

class IPaymentProcessor(ABC):
    @abstractmethod
    def process_payment(self, amount: float, payment_info: dict) -> bool:
        pass

# 구현체들
class CreditCardProcessor(IPaymentProcessor):
    def process_payment(self, amount: float, payment_info: dict) -> bool:
        # 신용카드 결제 로직
        return True

class PayPalProcessor(IPaymentProcessor):
    def process_payment(self, amount: float, payment_info: dict) -> bool:
        # PayPal 결제 로직
        return True

# 클라이언트
class OrderService:
    def __init__(self, payment_processor: IPaymentProcessor):
        self._payment_processor = payment_processor
    
    def complete_order(self, order_amount: float, payment_info: dict):
        return self._payment_processor.process_payment(order_amount, payment_info)

의존성 주입 (Dependency Injection)

정의: 외부에서 의존성을 주입하는 기법
구성: 생성자 주입, 세터 주입, 인터페이스 주입
목적: 객체 생성과 사용의 분리

시스템 구성:

graph LR
    A[DI Container] --> B[Service Registration]
    A --> C[Dependency Resolution]
    A --> D[Lifecycle Management]
    
    E[Constructor Injection] --> F[Client Object]
    G[Interface] --> F
    H[Implementation] --> G

전략 패턴 (Strategy Pattern)

정의: 알고리즘을 캡슐화하고 교체 가능하게 만드는 패턴
구성: Context + Strategy Interface + Concrete Strategies
목적: 런타임에 알고리즘 변경 가능

시나리오: 다양한 할인 정책을 적용하는 쇼핑몰 시스템

장점과 단점

도전 과제

분류에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1: 전자상거래 플랫폼의 주문 처리 시스템

시나리오: 대형 온라인 쇼핑몰에서 다양한 결제 방식 (신용카드, PayPal, 가상계좌, 암호화폐) 과 배송 방식 (일반배송, 택배, 드론배송) 을 지원하는 주문 처리 시스템을 구축

시스템 구성:

graph TB
    subgraph "클라이언트 계층"
        A[OrderController]
    end
    
    subgraph "서비스 계층"
        B[OrderService]
    end
    
    subgraph "추상화 계층"
        C[IPaymentProcessor]
        D[IShippingService]
        E[IInventoryService]
    end
    
    subgraph "구현 계층"
        F[CreditCardProcessor]
        G[PayPalProcessor]
        H[StandardShipping]
        I[ExpressShipping]
        J[DatabaseInventory]
        K[CacheInventory]
    end
    
    A --> B
    B --> C
    B --> D
    B --> E
    C --> F
    C --> G
    D --> H
    D --> I
    E --> J
    E --> K

Workflow:

sequenceDiagram
    participant Customer as 고객
    participant OrderController as 주문컨트롤러
    participant OrderService as 주문서비스
    participant PaymentProcessor as 결제처리기
    participant ShippingService as 배송서비스
    participant InventoryService as 재고서비스
    
    Customer->>OrderController: 주문 요청
    OrderController->>OrderService: processOrder()
    OrderService->>InventoryService: checkAvailability()
    InventoryService-->>OrderService: 재고 확인 결과
    OrderService->>PaymentProcessor: processPayment()
    PaymentProcessor-->>OrderService: 결제 결과
    OrderService->>ShippingService: arrangeShipping()
    ShippingService-->>OrderService: 배송 안내
    OrderService-->>OrderController: 주문 완료 결과
    OrderController-->>Customer: 주문 확인

역할 및 책임:

1. OrderService: 주문 비즈니스 로직 조율, 추상화된 인터페이스만 사용
2. IPaymentProcessor: 결제 처리 추상화, 다양한 결제 방식 지원
3. IShippingService: 배송 서비스 추상화, 배송 방식 선택 유연성
4. IInventoryService: 재고 관리 추상화, 다양한 데이터 소스 지원

구현 코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class OrderService:
    def __init__(self, 
                 payment_processor: IPaymentProcessor,
                 shipping_service: IShippingService,
                 inventory_service: IInventoryService):
        self._payment_processor = payment_processor
        self._shipping_service = shipping_service
        self._inventory_service = inventory_service
    
    def process_order(self, order: Order) -> OrderResult:
        # 재고 확인
        if not self._inventory_service.check_availability(order.items):
            return OrderResult.insufficient_inventory()
        
        # 결제 처리
        payment_result = self._payment_processor.process_payment(
            order.total_amount, order.payment_info)
        if not payment_result.success:
            return OrderResult.payment_failed(payment_result.error)
        
        # 배송 준비
        shipping_result = self._shipping_service.arrange_shipping(
            order.shipping_address, order.items)
        
        return OrderResult.success(payment_result, shipping_result)

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주목할 내용 정리

하위 주제로 분류한 추가 학습 내용

관련 분야별 추가 학습 내용

주제와 관련하여 추가로 알아야 하거나 학습해야 할 내용들

용어 정리

참고 및 출처

원칙 및 개념

• Program Against Abstractions - Roadmap.sh
• Abstraction principle (Wikipedia)
• Dependency inversion principle - Wikipedia
• Interface segregation principle - Wikipedia
• SOLID: The First 5 Principles of Object Oriented Design - DigitalOcean
• Chapter 5: Design Principles – Software Engineering: A Modern Approach
• What Are Abstractions in Software Engineering with Examples - The Valuable Dev
• 6 Software Design Principles Used by Successful Engineers - Swimm

DIP 및 인터페이스 설계

• Dependency Inversion Principle - Embedded Artistry
• Understanding Interfaces and Dependency Inversion - GoForGoldman
• Interface Segregation Principle in Java - Baeldung
• Dependency Inversion Principle Explained - Stackify
• Interface Segregation with Code Examples - Stackify

아키텍처 및 프레임워크

• Martin Fowler - Inversion of Control Containers
• Spring Framework - Dependency Injection (공식 문서)
• Clean Architecture 설명서 - Uncle Bob
• 10 Software Architecture Patterns You Must Know About - Simform
• 14 Software Architecture Design Patterns to Know - Red Hat

기타 참고 블로그

• 의존성 역전 원칙과 포트-어댑터 아키텍처 - Javien 블로그
• 객체지향 설계 원칙(SOLID) - JTM 블로그