객체 지향 프로그래밍 (Object-Oriented Programming)

객체 지향 프로그래밍 (Object-Oriented Programming)

객체 지향 프로그래밍 (OOP) 은 소프트웨어 개발에서 현실 세계의 객체를 모델링하여 클래스를 정의하고, 이를 기반으로 객체를 생성하여 프로그램을 구성하는 방식이다. 데이터와 메서드를 묶어 객체 (Object) 로 구성하고, 이를 분류하는 설계 단위인 클래스 (Class) 를 통해 시스템을 구현한다.

이론적 기반은 1960~70 년대 Simula 와 Smalltalk 이며, 주요 특징은 캡슐화, 추상화, 상속, 다형성이다. 이러한 원칙을 통해 코드 재사용성과 유지 보수성을 극대화하며, SOLID 및 GRASP 같은 설계 원칙과 디자인 패턴에 기반한 견고한 아키텍처를 구현할 수 있다. 그러나 과도한 계층화는 복잡도를 증가시키며, 퍼포먼스와 학습 난이도에서 단점이 발생할 수 있다.

핵심 개념

1. 객체 (Object) 와 클래스 (Class)

   • 클래스 (Class): 객체를 생성하기 위한 청사진으로, 속성과 메서드를 정의한다.
   • 객체 (Object): 클래스의 인스턴스로, 실제 데이터를 가지며 동작을 수행한다.
   • 인스턴스 (Instance): 특정 클래스로부터 생성된 객체

2. 4 대 특징 (Pillar of OOP)

   • 캡슐화 (Encapsulation): 데이터와 메서드를 하나의 단위로 묶고, 외부로부터의 직접 접근을 제한하여 데이터 보호를 강화한다.
   • 상속 (Inheritance): 기존 클래스의 특성을 새로운 클래스가 물려받아 코드의 재사용성을 높인다.
   • 다형성 (Polymorphism): 동일한 인터페이스를 통해 다양한 형태의 동작을 구현하여 유연성을 제공한다.
   • 추상화 (Abstraction): 복잡한 시스템에서 핵심적인 부분만을 노출하여 사용자가 필요한 정보에만 집중할 수 있도록 한다.

3. 메시지 패싱 (Message Passing)

   • 객체 간 상호작용의 기본 메커니즘
   • 메서드 호출을 통한 객체 간 통신

실무 구현 요소

도구 · 환경 (IDE · 플러그인)

모델링 & 설계 산출물

1. 객체 모델링–도메인 개체·행위를 명사·동사로 추출 → 속성·메서드 결정
2. 클래스 설계–공통 특성 일반화, 책임 분리, 경계 정의
3. 메시지 전달–동기·비동기 호출, 이벤트 퍼블리시, CQRS 명령·쿼리 구분
4. 관계 설계–상속 (IS-A), 집합 (HAS-A), 의존 (Uses-A), 컴포지트 구조
5. 다이어그램 산출물–클래스·시퀀스·상태·패키지 뷰로 4 + 1 관점 충족

설계 원칙 · 패턴

코드 레벨 구현 기법

런타임 메커니즘

의존성 관리 & 제어 흐름

품질 체계 & 지원 인프라

• 정적 분석: SonarQube, PMD–코드 스멜, 보안 취약점 탐지
• 커버리지: JaCoCo, Istanbul–분기·라인·조건 커버리지 지표
• 메트릭 대시보드: Cyclomatic Complexity·Maintainability Index 로 리스크 모니터
• CI 파이프라인: PR 단계에서 린트·테스트·빌드 자동화, 머지 기준 명시

배경

객체 지향 프로그래밍은 1960 년대 시뮬라 (Simula) 언어에서 시작되어 1970 년대 스몰토크 (Smalltalk) 에서 체계화되었다. 기존의 절차적 프로그래밍의 한계를 극복하기 위해 등장했으며, 복잡성 증가와 소프트웨어 재사용 필요성이 주요 동인이었다.

객체 지향 프로그래밍의 발전 과정:

1. 초기 등장 (1960 년대)

   • 시뮬라 67: 노르웨이 컴퓨팅 센터에서 개발된 최초의 객체 지향 언어
   • 클래스 개념의 도입으로 현대 OOP 의 기반 마련

2. 발전기 (1970-80 년대)

   • 스몰토크: 순수 객체 지향 언어의 완성
   • C++: C 언어에 객체 지향 개념을 추가
   • 에이다: 미 국방성에서 개발한 대규모 시스템용 언어

3. 성숙기 (1990 년대 이후)

   • 자바: 플랫폼 독립성과 객체 지향성의 조화
   • C#, Python, Ruby: 현대적 객체 지향 언어들의 등장

목적 및 필요성

주요 목적:

1. 복잡성 관리: 대규모 소프트웨어의 복잡성 제어
2. 재사용성 향상: 코드와 설계의 재활용 극대화
3. 유지보수성: 변경과 확장이 용이한 구조 제공
4. 모듈성: 독립적인 모듈 단위로 개발 가능

필요성:

• 소프트웨어 규모의 급속한 증가
• 개발 및 유지보수 비용 절감 요구
• 팀 단위 개발의 효율성 향상
• 소프트웨어 품질 및 신뢰성 향상

주요 기능 및 역할

객체 지향 프로그래밍의 주요 기능은 현실 세계의 복잡한 문제를 객체 간의 상호작용으로 모델링하여 해결하는 것이다. 각 객체는 명확한 책임을 가지며, 메시지를 통해 협력하여 시스템 전체의 목표를 달성한다.

핵심 원칙

SOLID 원칙:

• 단일 책임 원칙 (Single Responsibility Principle): 클래스는 하나의 책임만 가져야 한다.
• 개방 - 폐쇄 원칙 (Open-Closed Principle): 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
• 리스코프 치환 원칙 (Liskov Substitution Principle): 자식 클래스는 부모 클래스의 기능을 대체할 수 있어야 한다.
• 인터페이스 분리 원칙 (Interface Segregation Principle): 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
• 의존 역전 원칙 (Dependency Inversion Principle): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.

특징

상속 (Inheritance)

정의: 기존 (부모, Super) 클래스의 속성과 기능 (메서드) 을 새로운 (자식, Sub) 클래스가 물려받아 재사용하고, 필요에 따라 확장할 수 있게 해주는 객체지향 프로그래밍의 핵심 개념이다.

주요 목적:

• 코드의 재사용성과 확장성
• 유지보수성 향상.
  공통 기능을 부모 클래스에 정의하고, 자식 클래스에서 추가 기능이나 수정이 필요할 때만 오버라이딩 (재정의) 하여 사용.

종류:

예시: 자동차 (Car) 클래스를 부모로 하여 BMW, Benz, Genesis 등 다양한 차종의 자식 클래스를 만들고, 공통 속성 (바퀴 수, 엔진 등) 은 부모에, 각 차종의 특성은 자식 클래스에 구현.
키워드 예시:
- Python: class Child(Parent):
- Java: class Child extends Parent
장점:

• 코드 중복 제거
• 일관성 유지
• 변경 용이성 (부모 클래스만 수정해도 모든 자식 클래스에 반영).
  주의 사항:
• 잘못 사용하면 강한 결합도를 유발하여 유지보수를 어렵게 함 → 필요 시 컴포지션으로 대체 고려

다형성 (Polymorphism)

정의: 다형성은 하나의 인터페이스 (메서드, 클래스 등) 로 여러 형태의 동작을 구현할 수 있는 능력. 즉, 동일한 메시지 (메서드 호출) 에 대해 객체에 따라 서로 다르게 반응할 수 있다.

주요 목적: 유연한 코드 구조, 인터페이스 기반 설계, 코드 재사용성 향상.

종류:

• 컴파일 타임 다형성 (오버로딩, Overloading): 같은 이름의 메서드를 매개변수의 타입이나 개수로 구분하여 여러 개 정의.
• 런타임 다형성 (오버라이딩, Overriding): 부모 클래스의 메서드를 자식 클래스에서 재정의하여, 실행 시점에 실제 객체의 타입에 따라 동작이 결정.

예시: Animal 이라는 부모 클래스의 makeSound() 메서드를 Dog, Cat 등 자식 클래스에서 각각 다르게 구현. Animal 타입의 변수로 여러 동물 객체를 다룰 수 있음.

캡슐화 (Encapsulation)

정의: 캡슐화는 객체의 속성과 메서드를 하나의 단위 (클래스) 로 묶고, 외부에서 내부 구현 (데이터, 상태) 에 직접 접근하지 못하도록 은닉하는 원칙이다.

주요 목적:

• 정보 은닉 (Information Hiding)
• 의도하지 않은 접근이나 변경 방지
• 객체의 무결성 보장.

방법:

• 멤버 변수 (속성) 는 보통 private 으로 선언하고, 외부에서는 public 메서드 (getter/setter) 로만 접근하게 한다.

패턴 적용 예시:

• DTO (Data Transfer Object)
• 접근자 (getter)/설정자 (setter)

장점:

• 오류 발생 범위 축소
• 유지보수성 향상
• 객체의 일관성 유지.

추상화 (Abstraction)

정의: 추상화는 복잡한 현실 세계의 엔티티에서 핵심적인 속성과 동작만을 모델링하여, 불필요한 세부사항은 감추는 개념.

주요 목적:

• 복잡성 감소
• 코드의 단순화
• 재사용성 및 유연성 향상.

구현 방법: 추상 클래스 (abstract class), 인터페이스 (interface) 등을 사용해 공통 동작의 틀만 정의하고, 구체적 구현은 하위 클래스에서 담당.

예시: Animal 이라는 추상 클래스에 makeSound() 라는 추상 메서드만 정의하고, Cat, Dog 등에서 구체적으로 구현.

장점:

• 코드 품질 및 유지보수성 향상
• 다양한 객체를 일관된 방식으로 다룰 수 있음.

주요 원리와 작동 원리

주요 원리

객체 지향 프로그래밍은 클래스와 객체를 중심으로 동작한다. 클래스는 객체를 생성하기 위한 틀이며 복잡한 현실을 단순화하여 계층 구조로 설계한다. 객체는 클래스의 인스턴스로서 실제 데이터를 가지고 동작한다. 객체들은 메시지를 주고받으며 상호작용하며, 이러한 구조를 통해 프로그램이 실행된다.

1. 메시지 전달 메커니즘

   sequenceDiagram
       participant A as 객체 A
       participant B as 객체 B
       A->>B: 메시지 전송
       B-->>B: 메서드 실행
       B->>A: 결과 반환
   

2. 상속 계층 구조

   graph TD
       A[상위 클래스] --> B[하위 클래스 1]
       A --> C[하위 클래스 2]
       B --> D[하위 클래스 1-1]
       C --> E[하위 클래스 2-1]
   

3. 다형성 실현 메커니즘

   • 컴파일 타임 다형성: 메서드 오버로딩
   • 런타임 다형성: 메서드 오버라이딩과 동적 바인딩

작동 원리

객체 생성 - 소멸 전 공통 Life-Cycle 흐름

sequenceDiagram
    autonumber
    participant Client
    participant Class
    participant Heap
    participant Obj
    Client->>Class: new / 생성 요청
    Class->>Heap: 메모리 할당
    Heap-->>Class: 주소 반환
    Class->>Obj: 생성자(ctor) 호출
    Obj-->>Class: 필드 초기화 완료
    Class-->>Client: 객체 참조(레퍼런스)
    Client->>Obj: 메서드 호출
    Obj-->>Client: 결과 반환

포인트: 할당 → 생성자 → 사용 → 소멸 은 모든 OOP 언어에서 동일하지만 소멸 시점과 방법은 언어·런타임이 다르게 보장한다.

공통 단계 & 개념

언어별 Life-Cycle 세부

객체 소멸 시퀀스

sequenceDiagram
    autonumber
    participant GC/Scope
    participant Obj
    participant Memory
    note over GC/Scope: (a) GC 언어 – 루트<br>그래프에서 분리<br>(b) C++ – 블록 종료
    GC/Scope-->>Obj: 파괴 트리거<br>(Finalize/Destructor)
    Obj-->>Memory: 자원 해제<br>(파일, 메모리, 락)
    Memory-->>GC/Scope: 영역 반환

• 생성 단계는 언어마다 거의 동일하지만, 소멸 타이밍은
  • C++: Deterministic (스코프 기반)  
  • Java/Python/.NET: GC 비결정적
• 실무에서는 RAII / using / with 로 " 시점이 예측되는 " 자원 해제를 강제해야 한다.
• 리플렉션·DI 컨테이너 등 런타임 기술은 생성 - 소멸 훅(프록시·AOP) 을 활용. 단 관심사 (로깅·트랜잭션) 삽입이 가능하지만 남용하면 성능·추적성이 떨어지므로 계층 - 모듈 경계에서만 사용한다.

구조 및 아키텍처

객체 지향 프로그래밍의 구조는 다음과 같은 계층적 구조를 갖는다:

graph TD
    A[시스템] --> B[패키지/네임스페이스]
    B --> C[클래스]
    C --> D[객체/인스턴스]
    D --> E[메서드]
    D --> F[속성/필드]
    C --> G[상속 관계]
    C --> H[인터페이스]
    H --> I[구현]

구성 요소

구현 기법

장점

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

실무 적용 예시

활용 사례

사례 1: 게임 개발 엔진

상황: RPG 게임에서 캐릭터, 무기, 아이템, 행동 (Action) 을 설계

시스템 구성:

• Character 클래스: 체력, 공격 메서드 등 동작
• Weapon/Item 클래스: 장착 효과, 사용 메서드
• Action 인터페이스 + 전략 패턴으로 공격/회피 전략 분리
• DI: 게임 초기화 시 전략 인스턴스 주입

워크플로우:

1. 캐릭터 생성 시 공격 전략 DI 주입
2. 전투 시 character.attack() 호출 → 전략에 따라 다르게 동작
3. 무기 교체 시 전략 인스턴스만 변경 → 유연한 행동 전환

차이점: 절차형 접근에서는 if/else 기반 공격 분기 필요 → 로직 복잡도 증가

구현 예시:

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

from abc import ABC, abstractmethod

# --- 전략 패턴 인터페이스 정의 ---
class AttackStrategy(ABC):
    @abstractmethod
    def attack(self, target):
        pass

# --- 구체적인 전략 구현 ---
class SwordAttack(AttackStrategy):
    def attack(self, target):
        print(f"🗡️ Sword slash hits {target}!")

class BowAttack(AttackStrategy):
    def attack(self, target):
        print(f"🏹 Arrow shot hits {target}!")

# --- 캐릭터 클래스: 전략을 DI 받음 ---
class Character:
    def __init__(self, name: str, strategy: AttackStrategy):
        self.name = name
        self.hp = 100
        self.strategy = strategy  # 전략 주입 (DI)

    def attack(self, target: str):
        print(f"{self.name} prepares to attack…")
        self.strategy.attack(target)

    def change_strategy(self, new_strategy: AttackStrategy):
        print(f"{self.name} changes strategy!")
        self.strategy = new_strategy

# --- 무기 클래스 (전략 교체 목적) ---
class Weapon:
    def __init__(self, name: str, strategy: AttackStrategy):
        self.name = name
        self.strategy = strategy

# --- 예제 시나리오 실행 ---
if __name__ == "__main__":
    # 캐릭터 생성 시 전략 주입 (초기 DI)
    hero = Character("Archer", BowAttack())
    hero.attack("Goblin")  # 결과: Arrow shot hits Goblin!

    # 무기 교체 → 전략 교체
    sword = Weapon("Excalibur", SwordAttack())
    hero.change_strategy(sword.strategy)
    hero.attack("Orc")  # 결과: Sword slash hits Orc!

사례 2: 은행 계좌 관리 시스템

시스템 구성:

graph TB
    subgraph "프레젠테이션 계층"
        A[웹 UI]
        B[모바일 UI]
        C[ATM 인터페이스]
    end
    
    subgraph "비즈니스 계층"
        D[계좌 서비스]
        E[거래 서비스]
        F[고객 서비스]
        G[인증 서비스]
    end
    
    subgraph "도메인 계층"
        H[Account]
        I[Customer]
        J[Transaction]
        K[SecurityPolicy]
    end
    
    subgraph "데이터 계층"
        L[AccountRepository]
        M[CustomerRepository]
        N[TransactionRepository]
        O[Database]
    end
    
    A --> D
    B --> D
    C --> D
    D --> H
    E --> J
    F --> I
    G --> K
    H --> L
    I --> M
    J --> N
    L --> O
    M --> O
    N --> O

워크플로우:

sequenceDiagram
    participant U as 사용자
    participant UI as 사용자 인터페이스
    participant AS as 계좌 서비스
    participant A as Account 객체
    participant TR as TransactionRepository
    participant DB as 데이터베이스
    
    U->>UI: 송금 요청
    UI->>AS: transferMoney()
    AS->>A: withdraw(amount)
    A->>A: validateBalance()
    A->>TR: saveTransaction()
    TR->>DB: INSERT transaction
    DB-->>TR: 성공 응답
    TR-->>A: 저장 완료
    A-->>AS: 출금 완료
    AS->>A: deposit(amount, targetAccount)
    A->>TR: saveTransaction()
    TR->>DB: INSERT transaction
    DB-->>TR: 성공 응답
    A-->>AS: 입금 완료
    AS-->>UI: 송금 결과
    UI-->>U: 완료 메시지

전통적 절차적 접근법과의 차이:

• 절차적: 함수 중심의 순차적 처리
• 객체지향: 객체 간 협력을 통한 문제 해결
• 장점: 도메인 지식의 직접적 표현, 변경 영향 최소화

구현 예시:

  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
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

from abc import ABC, abstractmethod
from datetime import datetime
from typing import List, Optional

# 추상 클래스 정의
class Account(ABC):
    """계좌 추상 클래스"""
    def __init__(self, account_number: str, owner: str, initial_balance: float = 0):
        self._account_number = account_number  # 캡슐화: private 속성
        self._owner = owner
        self._balance = initial_balance
        self._transactions: List['Transaction'] = []
    
    @property
    def account_number(self) -> str:
        """계좌번호 조회 (읽기 전용)"""
        return self._account_number
    
    @property 
    def balance(self) -> float:
        """잔액 조회"""
        return self._balance
    
    def deposit(self, amount: float) -> bool:
        """입금 처리"""
        if amount <= 0:
            raise ValueError("입금액은 0보다 커야 합니다")
        
        self._balance += amount
        self._add_transaction("DEPOSIT", amount)
        return True
    
    @abstractmethod
    def withdraw(self, amount: float) -> bool:
        """출금 처리 (추상 메서드)"""
        pass
    
    def _add_transaction(self, transaction_type: str, amount: float):
        """거래 내역 추가"""
        transaction = Transaction(transaction_type, amount, self._balance)
        self._transactions.append(transaction)

# 구체 클래스들 (상속)
class SavingsAccount(Account):
    """저축 계좌"""
    def __init__(self, account_number: str, owner: str, initial_balance: float = 0):
        super().__init__(account_number, owner, initial_balance)
        self._interest_rate = 0.02  # 2% 이자율
    
    def withdraw(self, amount: float) -> bool:
        """저축계좌 출금 (잔액 확인)"""
        if amount <= 0:
            raise ValueError("출금액은 0보다 커야 합니다")
        
        if self._balance < amount:
            return False  # 잔액 부족
        
        self._balance -= amount
        self._add_transaction("WITHDRAW", amount)
        return True
    
    def calculate_interest(self) -> float:
        """이자 계산"""
        return self._balance * self._interest_rate

class CheckingAccount(Account):
    """당좌 계좌 (마이너스 허용)"""
    def __init__(self, account_number: str, owner: str, initial_balance: float = 0, 
                 overdraft_limit: float = 1000):
        super().__init__(account_number, owner, initial_balance)
        self._overdraft_limit = overdraft_limit
    
    def withdraw(self, amount: float) -> bool:
        """당좌계좌 출금 (마이너스 한도 확인)"""
        if amount <= 0:
            raise ValueError("출금액은 0보다 커야 합니다")
        
        if (self._balance - amount) < -self._overdraft_limit:
            return False  # 한도 초과
        
        self._balance -= amount
        self._add_transaction("WITHDRAW", amount)
        return True

# 거래 내역 클래스
class Transaction:
    """거래 내역"""
    def __init__(self, transaction_type: str, amount: float, balance_after: float):
        self.transaction_type = transaction_type
        self.amount = amount
        self.balance_after = balance_after
        self.timestamp = datetime.now()
    
    def __str__(self) -> str:
        return f"{self.timestamp}: {self.transaction_type} {self.amount}, 잔액: {self.balance_after}"

# 은행 서비스 클래스 (컴포지션)
class BankService:
    """은행 서비스 관리"""
    def __init__(self):
        self._accounts: dict[str, Account] = {}
    
    def create_account(self, account_type: str, account_number: str, 
                      owner: str, initial_balance: float = 0) -> Account:
        """계좌 생성 (팩토리 패턴)"""
        if account_type == "SAVINGS":
            account = SavingsAccount(account_number, owner, initial_balance)
        elif account_type == "CHECKING":
            account = CheckingAccount(account_number, owner, initial_balance)
        else:
            raise ValueError("지원하지 않는 계좌 유형입니다")
        
        self._accounts[account_number] = account
        return account
    
    def get_account(self, account_number: str) -> Optional[Account]:
        """계좌 조회"""
        return self._accounts.get(account_number)
    
    def transfer(self, from_account: str, to_account: str, amount: float) -> bool:
        """계좌 이체"""
        source = self.get_account(from_account)
        target = self.get_account(to_account)
        
        if not source or not target:
            return False
        
        if source.withdraw(amount):
            target.deposit(amount)
            return True
        return False

# 사용 예시 (다형성 활용)
def demonstrate_polymorphism():
    """다형성 시연"""
    bank = BankService()
    
    # 다양한 타입의 계좌 생성
    savings = bank.create_account("SAVINGS", "SAV001", "김철수", 10000)
    checking = bank.create_account("CHECKING", "CHK001", "이영희", 5000)
    
    # 동일한 인터페이스로 다른 동작 수행 (다형성)
    accounts = [savings, checking]
    
    for account in accounts:
        print(f"계좌: {account.account_number}, 잔액: {account.balance}")
        account.deposit(1000)  # 모든 계좌 타입에서 동일하게 작동
        account.withdraw(500)   # 각 계좌 타입별로 다른 로직 실행
        print(f"처리 후 잔액: {account.balance}")

# 실행
if __name__ == "__main__":
    demonstrate_polymorphism()

실무 적용 시 고려사항

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

성능 분석 및 도구 활용

• 구조적 최적화: 설계 원칙 (SOLID), 책임 분리, 추상화 수준 조절
• 성능 최적화: 메모리, 호출, 객체 생명주기, 상태 관리 측면에서 Flyweight, DI, 객체 풀 활용
• 도구 기반 진단: 프로파일링 도구, 컴파일러 힌트, 테스트 자동화로 최적화 진행

테스트 & DI 도입 전략

1. 유닛 테스트 전략 & 모킹 (Mock)

   • “Arrange, Act, Assert” 패턴 → 코드 가독성과 목적 명확화
   • Mock vs Stub vs Fake
     • 테스트에서 외부 의존 (ex: DB, 파일, 네트워크 등) 은 mock/stub 사용
     • 복잡한 비즈니스 로직은 실제 구현/통합 테스트로 확인하고, 단순한 로직은 mock 없이 pure function 형태 유지하는 것이 재설계 유연성에 유리
     • “Mock trainwreck” 방지: 너무 깊은 객체 모델 체인은 테스트 복잡도 증가
   • 모킹 베스트 프랙티스
     • 필요 최소한으로 모킹: 외부 의존만 모킹하고, 핵심 로직은 실제 객체로 테스트
     • Mock 설정 책임 최소화: 테스트가 mock 설정 세부에 의존하면 리팩토링 시 테스트가 자주 깨짐
     • 명명 규칙 준수: MethodName_StateUnderTest_ExpectedBehavior

2. DI(Dependency Injection) 적용 전략

   • 의존성 역전 원칙 (DIP): 하위 모듈이 아닌 상위 모듈도 추상화에 의존하도록 설계
   • DI 유형별 사용:
     • 생성자 주입 (Constructor Injection): 기본 의존성 주입 방식
     • 세터 주입 (Setter Injection): 선택적 의존성 시 사용
     • 메소드 주입 (Method Injection): 일시적 의존성에 적합
     • 인터페이스 주입 (Interface Injection): 클라이언트가 주입 메서드 구현
   • DI 를 이용한 테스트 구조
     • DI 기반 설계로 mock 주입 간편 → 테스트 격리성 확보
     • 모의 객체 (Mock) 또는 Fake 객체를 생성자/세터/메소드 주입 방식으로 주입

3. 유닛 테스트 + DI 모범 사례 요약

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

추가 학습 내용

• Spring Framework: DI, AOP, 트랜잭션 → SOLID + GoF 패턴 학습 필수
• Django: MTV 패턴, ORM → MVC 아키텍처 + 데이터 모델링
• 게임 개발: Unity 컴포넌트 시스템 → 객체 생성/소멸/전략 패턴 + 상태 관리
• 모바일 개발: Android Activity/Fragment → 생명주기 관리 + OOP 확장 패턴
• 금융/엔터프라이즈 시스템: DDD + Clean Architecture → 유지보수 중심 설계 전략 필수

용어 정리

참고 및 출처

객체 지향 프로그래밍 개념 및 기초

• 객체 지향 프로그래밍 - 위키백과
• Object-Oriented Programming - Wikipedia
• 객체 지향 프로그래밍의 4가지 특징
• 객체 지향 프로그래밍이란 - 티스토리
• 객체지향 프로그래밍(OOP) - 티스토리

설계 원칙 (SOLID)

• SOLID 원칙 - 위키백과
• SOLID Principles – DigitalOcean
• 객체 지향 개발 5원칙 - SOLID (gmlwjd 블로그)

디자인 패턴

• 디자인 패턴 설명 – Refactoring.Guru
• Java Design Patterns – Baeldung
• 디자인 패턴 개요 – Wikipedia

아키텍처 및 고급 설계

• Clean Architecture – Uncle Bob
• 객체 지향 프로그래밍의 이해와 실제 적용 사례 – F-Lab

언어별 OOP 자료

• Python OOP Guide – RealPython

메모리 및 성능 관리

• 가비지 컬렉션 개념 – Wikipedia

그 외 참고자료

• 모두의연구소 - OOP 입문자를 위한 친절한 가이드
• F-Lab - 객체 지향 프로그래밍의 원리와 장점
• MDN Web Docs - 객체 지향 프로그래밍
• Velog - OOP의 5원칙과 4가지 특성
• 나무위키 - 객체 지향 프로그래밍