졍's 기술 블로그

생성 패턴

-. Factory Pattern: 객체의 생성 동작을 별도의 Class로 분리해 처리하거나 별도의 Method를 호출해 처리

-. Singleton Pattern: 선언된 Class로 복수 객체를 생성할 수 없도록 제한하며, 제한된 단일 객체는 공유와 충돌 방지

-. Factory Method Pattern: Factory Pattern에 추상화를 결합해 객체의 생성과 사용을 분리하는 방식으로, 선언된 Class의 객체를 직접 Code로 생성하지 않고 별도로 준비한 추상 Method에 생성 위임

-. Abstract Factory Pattern: Factory Method Pattern 보다 좀 더 큰 그룹 단위 객체를 생성/관리하는 방식으로 Factory에 Interface를 활용해 객체를 생성함으로써 Factory를 Factory의 군(Family)으로 변경

-. Builder Pattern: 추상 Factory Pattern을 확장한 Pattern으로 복잡한 구조의 복합 객체를 생성하기 위한 단계를 정의하고 각 단계 별 수행 동작을 변경하면서 Builder Pattern으로 생성

-. Prototype Pattern: 새로운 객체를 생성하지 않고 기존의 객체를 복제하는 방식으로 자원을 절약하는 Pattern

1. Class

: 객체지향 프로그래밍(OOP, Object Oriented Programming)의 핵심 개념으로, Data와 Data를 조작하는 함수를 하나의 논리적 단위로 묶는 사용자 정의 Data Type

1.1 주요 구성요소

-. Member Variant(멤버 변수): Class 내에서 Data를 저장하기 위한 변수로 객체의 속성을 나타냄

-. Member Function(멤버 함수): Class 내의 Data(Member Variant)를 조작하거나 동작을 정의하는 함수

-. Access Specifier(접근 제한자): Class Member의 접근 권한 제어

   -. public: 외부에서 접근 가능

   -. private: Class 내부에서만 접근 가능

   -. protected: 파생 Class에서 접근 가능

-. Constructor(생성자): 객체 생성 시 자동으로 호출되는 함수로 Member Variant를 자동으로 초기화 하거나 객체 초기 설정에 사용

-. Destructor(소멸자): 객체가 소멸할 때 자동으로 호출되는 함수로 자원 해제 등에 사용

1.2 Class의 특징

-. Inheritance(상속): 기존 Class(부모 Class)의 속성과 가능을 다른 Class(자식 Class)가 물려받아 Code의 재사용성을 높임

-. Polymorphism(다형성): 같은 이름의 함수가 다른 동작을 수행할 수 있음

   e.g., 함수 Over loading, 가상함수, ...

-. Encapsulation(캡슐화): Data와 함수를 하나로 묶고 외부에서 직접 접근 제한

-. Abstraction(추상화): 실제 Code를 개발하기 전에 구체적인 내용은 배제하고 개략적인 정보만 선언하는 것으로 추상적 개념과 실제 Code를 분리하는 효과가 있어 향후 개발 중인 Code를 예정하고 선언만으로 주변 가능을 작성할 수 있다는 장점이 있음

#include <iostream>
using namesapce std;

class Hello{
public:
	Hello(){ cout << "Constructor called" << endl; }
    ~Hello(){ cout << "Destructor called" << endl; }
    void greeting(){ cout << "Hello" << endl; }
};

2. 객체(Object)

: 객체를 설계할 때는 어떤 유형의 객체를 생성할 지 미리 정의하는 것이 중요

2.1. new keyword

객체를 생성하는 예약어로 Compile, Interpreter 과정에서 선언된 Class에 따른 객체(Instance)를 생성하고 이를 Memory에 할당

선언된 Class를 기반으로 객체를 생성하는 Instance화 작업을 수행하며 객체 간에 강력한 의존 관계를 갖는 구조적 문제 발생

-> 생성 패턴을 이용해 해당 문제를 해결할 수 있으며, 특히 Factory Pattern은 객체 생성을 별개의 Class로 구축해 위임 처리

[참고] Compile vs Interpreter

2.2 객체 생성

1) Stack 기반 객체 생성: 객체가 Stack Memory에 생성되어 Scope를 벗어나면 객체가 자동으로 소멸되어 명시적으로 소멸자를 호출하거나 Memory를 해제할 필요 없음

#include <iostream>
using namespace std;

class Hello{
public:
    Hello(){ cout << "Constructor called" << endl; }
    ~Hello(){ cout << "Destructor called" << endl; }
    void greeting(){ cout << "Hello" << endl; }
};

int main(void){
    Hello helloObj; // Stack 기반 객체 생성
    helloObj.greeting(); // Member 함수 호출
    return 0; // Program 종료 시 helloObj의 소멸자가 자동 호출
}

Output

Constructor called
Hello
Destructor called

2) Heap 기반 객체 생성: 객체가 Heap Memory에 생성되어 delete 연산자를 사용해 명시적으로 Memory를 해제하지 않으면 Memory 누수 발생 가능

#include <iostream>
using namespace std;

class Hello{
public:
    Hello(){ cout << "Constructor called" << endl; }
    ~Hello(){ cout << "Destructor called" << endl; }
    void greeting(){ cout << "Hello" << endl; }
};

int main(void){
    Hello* helloObj = new Hello(); // Heap 기반 객체 생성
    helloObj->greeting(); // Member 함수 호출
    delete helloObj; // 객체 소멸(Memory 해제)
    return 0;
}

Output

Constructor called
Hello
Destructor called

3. 의존성

3.1 객체 지향

: 부여된 책임 간의 관계를 설정하고 상호 동작을 수행하는 것

* 관계(Relationship): 객체 간 동작을 위해 접근하는 것으로 개별 객체는 요구되는 역할을 수행하기 위한 책임이 부여됨

   1) 객체의 관계 성립 -> 객체 간 상호작용 발생

   2) 문제 해결을 위해 책임감 있는 객체는 각각의 Sub 책임을 가진 다른 객체에 소속된 문제 해결 위임

      -> 이 때 객체 간 대화(Message)를 주고 받으며 객체의 고유 기능 실행

3.2 의존성(Dependency)

: SW 개발에서 한 Component(또는 객체)가 다른 Component에 의존하는 관계로, 한 Class가 자신의 작업을 수행하기 위해 다른 Class나 외부 Resource에 접근하거나 사용하는 경우 두 Class 사이에 의존성이 있다고 함

-> 의존성이 많으면 System이 복잡해지고 유지보수가 어려워질 수 있으므로, 필연적일 수 있으나 관리 및 최적화 하는 것이 중요

3.2.1 직접 의존성: 한 Class가 다른 객체를 직접 생성하거나 사용하는 경우

#include <iostream>
using namespace std;

class Engine{
public:
    void start(){ cout << "Engine started" << endl; }
};

class Car{
private:
    Engine engine; // Car Class가 Engine에 의존
    
public:
    void startCar(){
        engine.start(); // Engine 객체 사용
        cout << "Car is ready to drive" << endl;
    }
};

int main(){
    Car car;
    car.startCar();
    return 0;
}

Output

Engine started
Car is ready to drive

3.2.2 의존성이 많은 Code의 문제점

-. 높은 결합도(Coupling)

   : Class 내에서 Class 이름을 직접 지정해 객체를 생성하는 경우로, Class 간 결합도가 많으면 하나의 변경이 다른 Class에도 영향을 줄 가능성 커짐

   -> 강력한 객체의 결합 Code는 향후 유연한 Code 확장을 방해하고 변경과 수정을 어렵게 만드는 원인

-. 재사용성 저하

   : 특정 Class가 다른 Class에 강하게 의존하면 독립적으로 재사용하기 어려워짐

-. Test 어려움

   : 의존성이 강한 Class는 단위 Test(Unit Test)를 수행하기 어려워질 수 있음

3.2.3 의존성 관리 방법

   1) 의존성 주입(Dependency Injection, DI)

   : 객체가 필요한 의존성(다른 객체)을 직접 생성하지 않고 외부에서 주입 받는 설계 방식으로, 의존성 주입이 발생하면 객체는 일반이 아닌 복합 객체 형태의 모습을 갖게 됨

#include <iostream>
using namespace std;

class Engine{
public:
    void start(){ cout << "Engine started" << endl; }
};

class Car{
private:
    Engine* engine; // Pointer로 객체 참조
public:
    // 생성자 초기화 리스트로 Car Class 생성자에서 Engine 객체의 Pointer e를 전달 받아 멤버 변수 
    // engine에 초기화(Car 객체 생성 시 Engine 객체 전달 필요)
    Car(Engine* e): engine(e){} // 의존성 주입
    
    void startCar(){
        engine->start(); // Engine 객체 사용
        cout << "Car is ready to drive" << endl;
    }
};

int main(){
    Engine engine; // Engine 객체 생성
    Car car(&engine); // 의존성 주입
    car.startCar();
    return 0;
}

Output

Engine started
Car is ready to drive

[참고] 생성자 초기화 리스트(Syntax for Initializer List)

Car(Engine* e){
    engine = e; // 생성자 내부에서 객체 초기화
}

   2) Interface 사용

   : Class 간 결합도를 줄이기 위해 Interface를 사용해 의존성을 느슨하게 만듦

   -> C++에서는 Interface를 직접적으로 지원하지 않지만 순수가상함수(Pure Virtual Function)를 가진 Class를 통해 Interface 구현

#include <iostream>
using namespace std;

// Interface 정의
class IEngine{
public:
    virtual void start() = 0; // 순수가상함수(Interface)
    virtual ~IEngine(){} // 가상 소멸자
{;

// Engine Class: IEngine Interface 구현
class Engine: public IEngine{
public:
    void start() override{
        cout << "Standard Engine started" << endl;
    }
};

// Electric Engine Class: IEngine Interface 구현
class Electric Engine: public IEngine{
public:
    void start() override{
        cout << "Electric Engine started silently" << endl;
    }
};

// Car Class
class Car{
private:
    IEngine* engine; // IEngine Interface 참조
public:
    Car(IEngine* e): engine(e){} // 의존성 주입
    void startCar(){
        engine->start(); // IEngine의 start() 호출
        cout << "Car is ready to drive" << endl;
    }
};

int main(){
    Engine standardEngine; // Standard Engine 객체 생성
    ElectricEngine electricEngine; // Electric Engine 객체 생성
    Car car1(&standardEngine); // Standard Engine 주입
    car1.startCar();
    Car car2(&electricEngine); // Electric Engine 주입
    car2.startCar();
    return 0;
}

Output

Standard Engine started
Car is ready to drive
Electric Engine started
Car is ready to drive

   3) 의존성 역전 원칙(DIP, Dependency Inversion Principle)

   : 고수준 Module은 저수준 Module에 의존하지 않고 모두 추상화에 의존해야 함

   4) DI Framework 사용

   : Google Guide와 같은 DI Framework 사용

3.3 복합 객체

하나의 객체가 다른 객체를 포함하거나 참조하는 구조로, 종속적이고 연관 관계를 가짐

1) 포함관계 (Composition)

: 강한 관계로 객체가 다른 객체를 직접 포함하며, 포함된 객체는 전체 객체와 생명주기 공유

#include <iostram>
using namespace std;

// Korean Class
class Korean{
public:
    string text() const { return "안녕하세요"; }
};

// Hello Class (포함관계)
class Hello{
private:
    Korean korean; // Korean 객체 직접 포함 (포함관계)
public:
    Hello(){}
    // greeting Method
    string greeting() const { return korean.text(); }
};

int main(){
    Hello hello; // Hello 객체 생성 (Hello 객체 생성되면서 Korean 객체도 함께 생성됨)
    cout << hello.greeting() << endl;
    return 0;
}

Output

안녕하세요

2) 집합 관계 (Aggregation)

: 느슨한 관계로, 객체가 다른 객체를 참조하거나 포인터로 소유하며 포함된 객체는 독집적으로 생성 및 소멸되어 생명주기를 공유하지 않음

#include <iostream>
#include <memory>
using namespace std;

class Korean{
public:
    string text() const { return "안녕하세요"; }
}

class Hello{
private:
    shared_ptr<Korean> korean; // Korean 객체 참조 (집합 관계)
public:
    Hello(shared_ptr<Korean> obj): korean(obj) {} // 외부에서 Korean 객체 전달 받음
    string greeting() const { return korean -> text(); )
};

int main(){
    shared_ptr<Korean> koreanObj = make_shared<Korean>(); // Korean 객체를 독립적으로 생성
    Hello hello(koreanObj); // Korean 객체를 Hello 객체에 전달(생명주기를 공유하지 않음)
    cout << hello.greeting() << endl;
    return 0;
}

Output

안녕하세요

3.3.2 복합객체의 장단점

1) 장점

   -. 모듈화: 전체와 부분으로 나누어 설계하면 Code의 재사용성과 유지보수성 증가

   -. 확장성: 객체를 구성하는 부분 객체를 교체하거나 확장하기 용이

   -. 캡슐화: 복합 객체 내부의 세부 사항을 숨기고 외부에는 필요한 동작만 제공

2) 단점

   -. 의존성 증가: 복합객체와 구성요소 간의 강한 의존성으로 인해 변경이 전체에 영향을 줄 수 있음

   -. 복잡성 증가: 객체 간의 관계를 설계하고 관리하는 데 추가적인 노력 필요

4 생성 패턴(Creational Pattern)

4.1 new keyword

: 선언된 Class를 기반으로 객체를 생성하는 Instance화를 수행하며 객체 간에 강력한 의존 관계를 갖는 구조적 문제 발생

4.2 생성 패턴(Creational Pattern)

: 객체 생성을 위임해 별개의 Class로 분리하고 Program 내에서 객체 생성이 필요한 경우 분리 설계된 Factory 객체에 생성을 위임함으로써 느슨한 결합 관계로 변경

* 공장(Factory): Design Pattern에서 객체를 생성하고 캡슐화해 위임하는 것

5 Factory Pattern

: 객체 생성 로직을 캡슐화해 Client Code가 직접 객체의 생성 방법을 알 필요 없도록 하는 Design Pattern

즉, 객체를 생성하는 공장을 만드는 Pattern으로 객체 생성을 위한 Interface를 제공하면서 실제 생성 작업은 Sub-Class나 Factory Class에서 수행해 느슨한 결합 관계로 변경

-. 장점: 개발 과정에서 Class의 이름이 변경되어도 Code를 일일히 수정하지 않고 Factory 객체를 통해 쉽게 변경 가능(유연성과 확장성 개선)

-. 단점: 객체 생성을 위임하는 데 별도의 Class가 필요

   -> 단순 팩토리로 이 단점 보완 가능

5.1 느슨한 결합

: 객체 생성은 객체 간 결합 관계를 발생시키고, 객체 간에 의존성 부여

-> Factory Pattern에서는 Code에서 직접 Class의 이름을 지정해 객체를 생성하지 않으며, 별도의 객체에 필요한 객체를 생성하도록 책임을 위임하는 과정에서 중복 코드 정리

#include <iostream>
#include <memory>
using namespace std;

// 1 제품 Class 정의 (Korean & English)
class Language{
public:
    // 객체의 불필요한 변경을 방지하고, Code의 안정성과 최적화를 향상시키기 위해 상수(const) 사용
    virtual string text() const = 0; // 순수가상함수
    virtual ~Language(){} // 가상소멸자
};

class Korean: public Language{
public:
    string text() const override { return "안녕하세요"; }
};

class English: public Language{
public:
    string text() const override { return "Hello"; }
};

// 2 Factory Class 정의
class Factory{
public:
    static unique_ptr<Language> getInstance(const string& type){
        cout << "Factory: 객체를 생성합니다" << endl;
        
        if(type == "ko") return make_unique<Korean>(); // 스마트포인터를 사용해 객체 반환
        else if(type == "en") return make_unique<English>();
        return nullptr; // 잘못된 type이면 nullptr 반환
    }
};

[참고] Static Method

class Logger{
public: // 객체 없이 호출 가능
    static void log(const string& message){
        cout << "[LOG]: " << message << endl;
    }
};

int main(){
    Logger::log("Program이 시작되었습니다");
}

class Singleton{
private:
    static unique_ptr<Singleton> instance; // 정적변수
    Singleton(){} // 생성자 Private으로 숨김
public:
    static Singleton& getInstance(){ // 정적 Method
        if(!instance) instance = make_unique<Singleton>();
        return *instance;
    }
    
    void showMessage(){ cout << "Singleton 객체입니다" << endl; }
};

// 정적변수 초기화
unique_ptr<Singleton> Singleton::instance = nullptr;

int main(){
    Singleton& s1 = Singleton::getInstance();
    Singleton& s2 = Singleton::getInstance();
    s1.showMessage();
    cout << (&s1 == &s2) << endl;
}

Singleton 객체입니다
1

[참고] 스마트 포인터(Smart Pointer)

#include <iostream>
#include <memory>

class Test{
public:
    Test(){ std::cout << "Test created" << endl; }
    ~Test(){ std::cout << "Test destroyed" << endl; }
};

int main(){
    std::unique_ptr<Test> ptr = std::make_unique<Test>();
    return 0; // ptr이 범위를 벗어나면 Test 객체를 자동으로 파괴
}

Test created
Test destroyed

#include <iostream>
#include <memory>

class Test{
public:
    Test{ std::cout << "Test created" << endl; }
    ~Test{ std::cout << "Test destroyed" << endl; }
};

int main(){
    std::shared_ptr<Test> ptr1 = std::make_shared<Test>();
    std::shared_ptr<Test> ptr2 = std::make_shared<Test>();
    
    // ptr1과 ptr2가 Test 객체 공유
    std::cout << "Use count: " << ptr1.use_count() << endl; // 참조 카운트
    return 0;
}

Test created
Use count: 2
Test destroyed

5.2 동적 팩토리(Dynamic Factory) Pattern

: 분리된 Factory Class의 객체를 통해 필요로 하는 모든 객체의 생성 위임

-> Code 자체에서 생성되는 강력한 의존 관계를 분리하고 느슨한 의존 관계로 변경

// 3 Hello Class 정의
class Hello{
public:
    string greeting(const string& type){
        unique_ptr<Language> lang = Factory::getInstance(type); // Factory를 호출해 객체 생성
        if(lang){ return lang->text() }
        return "유효하지 않은 타입입니다";
    }
};

전체 Code

#include <iostream>
#include <memory>
using namespace std;

// 1 제품 Class 정의 (Korean & English)
class Language{
public:
    // 객체의 불필요한 변경을 방지하고, Code의 안정성과 최적화를 향상시키기 위해 상수(const) 사용
    virtual string text() const = 0; // 순수가상함수
    virtual ~Language(){} // 가상소멸자
};

class Korean: public Language{
public:
    string text() const override { return "안녕하세요"; }
};

class English: public Language{
public:
    string text() const override { return "Hello"; }
};

// 2 Factory Class 정의
class Factory{
public:
    static unique_ptr<Language> getInstance(const string& type){
        cout << "Factory: 객체를 생성합니다" << endl;
        
        if(type == "ko") return make_unique<Korean>(); // 스마트포인터를 사용해 객체 반환
        else if(type == "en") return make_unique<English>();
        return nullptr; // 잘못된 type이면 nullptr 반환
    }
};

// 3 Hello Class 정의
class Hello{
public:
    string greeting(const string& type){
        unique_ptr<Language> lang = Factory::getInstance(type); // Factory를 호출해 객체 생성
        if(lang){ return lang->text() }
        return "유효하지 않은 타입입니다";
    }
};

// 4 Main 함수(Client Code)
int main(){
    Hello hello;
    cout << hello.greeting("ko") << endl;
    cout << hello.greeting("en") << endl;
    cout << hello.greeting("fr") << endl;
    return 0;
}

Output

Factory: 객체를 생성해 반환합니다
안녕하세요
Factory: 객체를 생성해 반환합니다
Hello
Factory: 객체를 생성해 반환합니다
유효하지 않은 타입입니다

5.3 단순 팩토리(Simple Factory) Pattern = 정적 팩토리(Static Factory) Pattern

: Factory Pattern의 특징과 처리 로직을 간략하게 작성한 것으로 별개의 Factory Pattern 객체를 생성하는 것이 아닌 자신의 객체에 필요한 객체를 생성하는 전용 Method 추가

즉, 객체 생성 로직이 단일함수에 캡슐화

#include <iostream>
#include <memory>
using namespace std;

// Korean Class 정의
class Korean{
public:
    string text() const{ return "안녕하세요"; }
};

// Hello Class 정의
class Hello{
public:
    // greeting Method
    string greeting() const{
        // Factory Method 호출해 Korean 객체 생성
        unique_ptr<Korean> ko = factory();
        return ko->text();
    }
    
    // Factory Method (정적 Method)
    static snique_ptr<Korean> factory(){
        return make_unique<Korean>() // C++에서는 동적 객체를 반환할 때 스마트 포인터를 사용하는
                                     // 것이 메모리 관리 측면에서 안전
    }
};

// main 함수
int main(){
    Hello hello;
    cout << hello.greeting() << endl;
    return 0;
}

Output

안녕하세요

-. 장점: 객체 생성 과정이 복잡하지 않은 경우 추가 Class 파일을 생성하지 않고도 Factory Pattern 적용 가능

6 정리

Factory Pattern
: 객체 생성 시 확장과 수정을 쉽게 하기 위한 설계 방법으로 객체 생성 과정을 분리해 처리하기 때문에 객체 생성 과정에서 발생하는 new keyword의 문제점을 해결하고 느슨한 객체 생성 관리
다양한 Class의 객체 생성을 쉽게 처리하며 생성하는 객체를 정의할 수 없거나 변경이 있는 경우 객체 생성을 매우 유용하게 관리 가능
-> Factory Pattern이 Proxy Pattern과 결합하면 객체 생성을 위임받을 때 권한에 따라 접근하는 것을 제어할 수 있으며, 특정 객체 생성에서 보안 또는 권한 등의 처리가 필요할 때 응용 가능
[ Problem ] 객체지향개발에서 객체 간 의존성은 객체를 생성할 때마다 발생하며 Code에서 직접 생성한 객체는 의존성이 강력해 유지보수와 수정이 어려움
[ Solve ] 의존 관계가 강력한 결합 관계를 느슨한 결합 관계로 변경
[ 장점 ] 객체 생성을 다른 객체에 위임함으로써 내부적 결합을 제거하고 동적으로 객체 관리 가능
            객체 생성 처리를 동적으로 위임하므로 향후 Class가 추가되거나 변경돼도 Code를 쉽게 수정 가능
[ 단점 ] Factory Pattern을 사용하면 객체를 직접 생성하는 것과 달리 Factory 객체를 통해 호출하는 처리 과정이 한 단계 더 필요하므로, 이는 불필요한 호출 증가로 Program 성능 저하를 초래할 수 있음

Simple Factory Pattern (단순 팩토리 패턴)
: Method를 통해 객체 생성을 관리해 가장 간단하고 깔끔하게 Class의 객체를 생성하는 의존적인 연관관계 해소 가능

* 창발(Energence): 지속적인 관찰을 통해 특정한 패턴을 발견하는 것

1 객체지향

: 1980년대 부터 존재했던 소프트웨어 개발 방법론으로 큰 프로젝트 개발과 유지보수를 보다 쉽게 하기 위해 도입
e.g., 스몰토크, C++, JAVA, PHP

2 디자인 패턴(Design Pattern)

: 객체지향 구현 문제를 해결하기 위해 도입됐으며, 해결 방법을 재사용하는 것으로 객체지향 개발에서 디자인 패턴이 해결하는 주요 문제는 객체 간 관계와 소통 처리

3 SOLID 설계 원칙

: 유지보수성과 확장성을 극대화하기 위한 객체지향 설계 지침으로, C++에서는 다형성(Polymorphism), 추상 클래스(Abstract Class), 인터페이스 설계 등을 활용해 구현

* 다형성(Polymorphism)

3.1 SRP(Single Responsibility Principle, 단일 책임의 원칙)

: 하나의 클래스는 하나의 기능(책임)만 담당하며, 변경 이유도 하나여야 함

ERROR CASE
: 하나의 Class가 계산, 출력, 저장 등 여러 책임을 가짐

class Invoice{
public:
	void calculateTotal(){
    	// 계산 로직
    }
    
    void printInvoice(){
    	// 출력 로직
    }
    
    void saveToDatabase(){
    	// 저장 로직
    }
};

GOOD CASE

: 각각의 책임을 별도의 Class로 분리

class InvoiceCalculator{
public:
	void calculateTotal(){
    	// 계산 로직
    }
};

class InvoicePrinter{
public:
	void printInvoice(){
    	// 출력 로직
    }
};

class InvoiceRepository{
public:
	void saveToDatabase(){
    	// 저장 로직
    }
};

3.2 OCP(Open/Close Principle, 개방 폐쇄 원칙)

: 코드는 확장에 열려 있고 수정에는 닫혀있어야 하며, 새로운 기능을 추가할 때 기존 코드를 수정하지 않고 확장할 수 있도록 설계

ERROR CASE

: 도형의 종류가 늘어날 때 마다 calculateArea method 수정 필요

class Shape{
public:
	std::string type;
};

class AreaCalculator{
public:
	double calculateArea(const Shape& shape){
    	if(shape.type == "circle"){
        	// 원의 면적 계산
        } else if(shape.type == "rectangle"){
        	// 사각형의 면적 계산
        }
        return 0;
    }
};

GOOD CASE

: 다형성을 활용해 새로운 도형을 추가할 때 기존 코드를 수정하지 않음

class Shape{
public:
	virtual double calculateArea() const = 0; // 순수 가상함수
	virtual ~Shape() = default;
};

class Circle: public Shape{
public:
	double radius;
	Circle(double r): radius(r){}
	double calculateArea() const override{
		return 3.14 * radius * radius;
    }
};

class Rectangle: public Shape{
public:
	double width, height;
	Rectangle(double w, double h): width(w), height(h){}
	double calculateArea()const override{
		return width * height;
    }
};

void printArea(const Shape& shape){
	std::cout << "Area: " << shape.calculateArea() << std::endl;
}

[ 참고 ] 상속과 선언의 상관 관계

class Work{
public:
	virtual void work1(){ // 기본 구현 제공
    	std::cout << "Base work!" << std::endl;
    }
    virtual void work2() = 0;
};

class Human: public Work{
	// work1()을 선언 및 구현하지 않아도 Error 없음
    // work2()는 선언해주지 않으면 compile error 발생
    void work2() override{
    	std::cout << "I am working!" << std::endl;
    }
};

int main(){
	Human h;
    h.work1(); // 부모 Class의 work() 호출: "Base work!"
    h.work2(); // "I am working!"
    return 0;
}

3.3 LSP(Liskov Substitution Principle, 리스코프 치환 원칙)

: 자식 Class는 부모 Class의 역할을 대체할 수 있어야 하며, 부모 Class의 동작을 깨뜨리거나 위반하지 않는 설계 필요

ERROR CASE

: Penguin Class가 Bird의 역할을 대체하지 못함

class Bird{
public:
	virtual void fly(){
		std::cout << "I can fly!" << std::endl;
	}
};

class Penguin: public Bird{
public:
	void fly() override{
		throw std::logic_error("Penguin can't fly!");
	}
};

GOOD CASE

: Bird와 FlyingBird로 역할 분리

class Bird{
public:
	virtual void eat(){
    	std::cout << "I can eat!" << std::endl;
    }
    virtual ~Bird() = default; // 소멸자
};

class FlyingBird: public Bird{
public:
	virtual void fly(){
    	std::cout << "I can fly!" << std::endl;
    }
};

class Penguin: public Bird(){
public:
	void eat() override{
    	std::cout << "I am a penguin and I eat fish!" << std::endl;
    }
};

class Sparrow: public FlyingBird{
public:
	void fly() override{
    	std::cout << "I am a sparrow and I can fly!" << std::endl;
    }
};

[ 참고 ] 소멸자(Destructor)

3.4 ISP(Interface Segregation Principle, 인터페이스 분리의 원칙)

: Client는 자신이 사용하지 않는 Method에 의존하지 않아야 하며, 큰 Interface를 작고 구체적인 Interface로 분리

ERROR CASE

: 로봇은 eat() Method가 필요하지 않지만 Worker Interface 때문에 구현해야 함

class Worker{
public:
	virtual void work() = 0;
	virtual void eat() = 0;
};

class Robot: public Worker{
public:
	void work() override{
    	std::cout << "I am working!" << std::endl;
    }
    void eat() override{
    	// 로봇은 eat를 사용할 필요가 없음
    }
};

GOOD CASE

: Interface를 분리해 필요하지 않은 의존성 제거

class Workable{
public:
	virtual void work() = 0;
    virtual ~Workable() = default;
}

class Eatable{
public:
	virtual eat() = 0;
    virtual ~Eatable() = default;
};

class Human: public Workable, public Eatable{
public:
	void work() override{
    	std::cout << "I am working!" << std::endl;
    }
    void eat() override{
    	std::cout << "I am eating!" << std::endl;
    }
};

class Robot: public Workable{
public:
	void work() override{
    	std::cout << "I am working!" << std::endl;
    }
};

3.5 DIP(Dependency Inversion Principle, 의존관계 역전의 원칙)

: 상위 모듈은 하위 모듈에 의존해서는 안되며 둘 다 추상화에 의존해야 하며, 구체 Class 대신 Interface나 추상 Class에 의존하는 설계 지향

ERROR CASE

: Computer Class가 특정 구현(Keyboard, Monitor)에 의존

class Keyboard{};
class Monitor{};

class Computer{
private:
	Keyboard keyboard;
    Monitor monitor;
};

GOOD CASE

: Interface에 의존하도록 수정

class InputDevice{
public:
	virtual void input() = 0;
    virtual ~InputDevice() = default;
};

class DisplayDevice{
public:
	virtual void display() = 0;
    virtual ~DisplayDevice() = default;
};

class Keyboard: public InputDevice{
public:
	void input() override{
    	std::cout << "Keyboard Input" << std::endl;
    }
};

class Monitor: public DisplayDevice{
public:
	void display() override{
    	std::cout << "Monitor display" << std::endl;
    }
};

class Computer{
// private으로 선언해 캡슐화 함으로써 외부 코드가 inputDevice와 displayDevice 포인터에 직접 접근하거나 변경하지 못하도록 보호
private:
	InputDevice* inputDevice; // 순수가상함수로 정의된 Interface로, 실제로는 이를 구현한 자식 Class(Keyboard)가 할당됨
    DisplayDevice* displayDevice; // 순수가상함수로 정의된 Interface로, 실제로는 이를 구현한 자식 Class(Monitor)가 할당됨
    
public:
	// 생성자에서 두 개의 포인터 매개변수를 받아 초기화하고, 외부에서 장치 객체를 생성해 전달하므로 Computer Class는 특정 입력/출력 장치의 구현에 직접 의존하지 않음
	Computer(InputDevice* input, DisplayDevice* display): inputDevice(input), displayDevice(display){}
    void use(){
    	// inputDevice와 displayDevice의 동작을 호출하며 inputDevice와 displayDevice가 가리키는 구체적인 구현에 따라 use()의 동작이 달라짐
    	inputDevice->input();
        displayDevice->display();
    }
};

int main(){
	Keyboard keyboard; // Keyboard 객체 생성
    Monitor monitor; // Monitor 객체 생성
    
    Computer computer(&keyboard, &monitor); // Computer 객체는 Keyboard와 Monitor 객체의 주소를 전달받아 초기화
    computer.use(); // 1) keyboard.input() 실행 -> "Keyboard input" 출력
                   //  2) monitor.display() 실행 -> "Monitor display" 출력
    return 0;
}

* 캡슐화

[ 참고 ] 객체 생성 시 Life Cycle

#include <iostream>
using namespace std;

class Parent{
public:
	Parent() {cout << "Parent Constructor" << endl;}
    ~Parent() {cout << "Parent Destructor" << endl;}
};

class Child: public Parent{
public:
	Child() {cout << "Child Constructor" << endl;}
    ~Child() {cout << "Child Destructor" << endl;}
};

int main(void){
	Parent* parentObj = new Parent(); // 부모 Class 객체 생성
    Child* childObj = new Child(); // 자식 Class 객체 생성
    delete parentObj; // 부모 객체 삭제(Child는 여전히 유효)
    child Obj -> ~Child(); // 수동으로 자식 객체 소멸
    return 0;
}

int main(){
	Parent* parentPtr = new Child(); // 부모 Pointer로 자식 객체 참조
    delete parentPtr; // 부모 포인터로 객체 삭제
    return 0;
}

class Parent{
public:
	Parent() {cout << "Parent Constructor" << endl;
    virtual ~Parent() {cout << "Parent Destructor" << endl;}
};

class Child: public Parent{
public:
	Child() {cout << "Child Constructor" << endl;
    ~Child() {cout << "Child Destructor" << endl;
};

int main(){
	Parent* parentPtr = new Child(); // 부모 Pointer로 자식 객체 참조
    delete parentPtr; // 부모 Pointer로 객체 삭제
    return 0;
}

4 GoF(Gang of Four)

: Erich Gamma, Richard Helm, Ralph Johnson, John Vissides의 저서인 'GoF의 디자인패턴'을 가리키는 용어로, 처음 소프트웨어 공학에서 사용되는 패턴을 정리한 사람들의 별칭

객체지향의 문제점을 분석해 24개의 패턴으로 분류

5 패턴의 요소

: 24개로 분리된 디자인 패턴은 공통된 4가지 요소를 가짐

5.1 이름(Pattern Name)

: 패턴 이름을 통해 피턴의 용도를 직관적으로 이해 가능

5.2 문제(Problem)

: 각 패턴은 해결하고자 하는 문제를 갖고 있으며, 이러한 문제들은 패턴 적용을 고려해야 하는 시점을 암시

5.3 해법(Solution)

: 문제점을 인식했다면 객체 요소 간 관계를 정리하고 객체들을 추상화 및 나열함으로써 해결 방법을 찾음

5.4 결과(Consequence)

: 디자인 패턴은 알려진 문제점들을 해결하는 데 효과적이지만 모든 코드에서 디자인 패턴이 유용하다고 볼 수는 없으므로 꼭 필요한 경우를 생각해 적절히 분배해 사용해야 함

6 디자인 패턴의 사용 목적

6.1 통일성

: 디자인 패턴은 개발 방법을 정의함으로써 보다 통일화된 코드를 작성할 수 있음

6.2 실체화(Reification)

: 구현(Implementation) 보다는 디자인을 의미하며, 구조만으로 패턴을 파악하는 것은 불가능하므로 의도를 파악하는 것이 중요

6.3 유지보수 및 방어적 설계

: 향후 추가되는 코드를 수정하기 쉽게 변경할 수 있도록 구현해야 하며, 오랫동안 문제 없이 유지보수를 하기 위해 변경 가능한 디자인(Design for change)으로 설계해야함

코드를 작성하면서 어떤 부분이 향후 수정될 것으로 예측된다면 해당 기능을 방어적으로 처리할 수 있도록 코드가 설계되어야 하며, 지속적인 리팩토링 작업을 수행해 주어야 함

디자인 패턴 vs 처리 성능
성능 최적화를 위해서는 많은 함수 호출과 객체 간 호출이 적을 수록 좋으나 디자인 패턴에서는 코드의 가독성과 유지보수를 위해 객체의 메소드를 분리하며 호출도 자주 발생하게 되므로 패턴을 너무 많이 사용하는 경우 잦은 메소드 호출로 인해 성능이 저하될 수 있음