추상 팩토리 패턴(Abstract Factory Pattern)연관성이 있는 제품군(객체 집합)이 여러개 있을 경우 이들을 묶어 추상화하고, 팩토리 클래스에서 집합으로 묶인 제품군을 생성하는 생성 패턴의 일종ㅡ> 복잡하게 분류되는 제품군들을 관리하고 확장하는데 용이ex) 갤럭시 스마트폰 + 갤럭시 탭 + 갤럭시 워치 vs. 아이폰 + 아이패드 + 애플 워치 와 같은 제품군을 생성 가능추상 팩토리 패턴 구조AbstractFactory : 최상위 공장 클래스. 인터페이스에 해당하며 여러개의 제품들을 생성하는 여러 메소드들을 추상화ConcreteFactory : 서브 공장 클래스. 타입에 맞는 제품을 반환하도록 메소드들을 재정의AbstractProduct : 각 타입의 제품들을 추상화한 인터페이스Concret..

팩토리 메서드 패턴(Factory Method Pattern)객체 생성을 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성하게 하는 생성 디자인 패턴ㅡ> 클라이언트에서 직접 new 연산자로 객체를 생성하지 않고, 제품 객체의 생성을 도맡아 하는 공장 클래스를 만들고 이를 상속하는 서브 공장 클래스의 메서드에서는 여러가지 제품 객체 생성을 각각 책임지는 형태+ 객체 생성에 필요한 과정을 템플릿처럼 미리 구성해놓고 객체 생성에 관한 전처리, 후처리를 통해 생성 과정을 다양하게 처리해 객체를 유연하게 결정할 수 있음ㅡ> 객체간의 결합도를 낮춰 유지보수의 효율성 향상팩토리 메서드 패턴 구조 Dialog : 최상위 공장 클래스 ㅡ> 팩토리 메서드를 추상화하여 서브 클래스에서 객체를 생성하도록 함객체 생성 ..

싱글톤 패턴싱글톤 패턴을 따르는 클래스는 클래스에서 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 단 하나이고, 최초 생성 이후 호출된 생성자는 최초의 생성자가 생성한 객체를 반환주로 프로그램 내에서 하나만 생성해 공유해야 하는 객체가 존재할 때 사용싱글톤 패턴의 장점메모리 사용 : 한개의 인스턴스만 고정 메모리 영역에 생성 ㅡ> 추후 해당 객체 접근 시 메모리 낭비 방지속도 : 이미 생성된 인스턴스를 사용 ㅡ>  속도가 빠름데이터 공유 : 전역으로 사용되는 인스턴스 ㅡ> 여러 클래스에서 데이터 공유 가능 ㅡ> But, 동시성 문제 유의싱글톤 패턴 코드싱글 캐릭터 게임#include using namespace std;class Character {private: static Charact..

디자인 패턴개발 시 반복적으로 등장하는 문제를 해결하기 위한 일반화 된 솔루션객체 지향 4대 특성(캡슐화, 상속, 추상화, 다형성)과 SOLID원칙을 기반으로 구현* 장점 : 코드 유지보수 효율성 향상디자인 패턴 분류생성 패턴(Creational Patterns) : 새로운 것을 만들어내는 방법과 관련된 패턴구조 패턴(Structual Patterns) : 여러 부품을 어떻게 조립하고 연결하는지에 대한 패턴행동 패턴(Behavioral Patterns) : 부품이 서로 어떻게 상호작용하는지에 대한 패턴생성 패턴싱글톤(Singleton) : 하나의 클래스 인스턴스를 전역에서 접근 가능하게 하여 해당 인스턴스가 단 한번 생성되도록 보장하는 패턴팩토리 메서드(Factory Method) : 객체를 생성하기 위..

DIP(Dependency Inversion Principle)고수준 모듈은 저수준 모듈에 의존하지 않고 둘다 추상화에 의존해야 한다는 원칙고수준 모듈 : 다른 클래스나 모듈을 사용하는 사용자 역할저수준 모듈 : 구체적인 작업을 처리하는 세부사항이 담긴 클래스이전 ISP(인터페이스 분리 원칙)에서 다루었던 것과 비슷하게 고수준 모듈이 저수준 모듈에 의존하지 않도록 추상화(인터페이스화)에 의존하도록 설계를 해야 한다는 말이다.코드 예제DIP가 적용되지 않은 코드#include using namespace std;class Monitor{public: void display(const string& data) { //출력 }};class Keyboard{public: string GetIn..

ISP(Interface Segregation Principle)객체는 자신이 호출하지 않는 메서드에 의존하지 않아야 한다는 원칙상속할 객체의 규모가 불필요하게 너무 큼 ㅡ> 객체의 메서드를 작은 인터페이스로 나누어 구현 ㅡ> 각 객체가 필요한 인터페이스만을 상속하여 구현 ㅡ> 불필요한 메서드가 없이 필요한 메서드만 구현코드 예제ISP가 적용되지 않은 코드class IOMachine{public: IOMachine(){} void print(){ //기능 구현 } void scan(){ //기능 구현 }};print, scan을 하나의 클래스에 모두 구현하고 보니 이를 상속하게 될 클래스에서는 프린터 종류여도 scan() 기능을 가지고 있게 되거나 스캐너 종류가 pri..

LSP(Liskov Substitution Principle)부모 클래스를 호출하는 동작에서 자식 클래스가 부모 클래스를 완전히 대체할 수 있다는 원칙* 객체의 상속(다형성) ㅡ> 부모/자식 관계 형성 ㅡ> 자식 객체는 부모 객체의 특성을 가지면서 추가적 확장 가능ㅡ> 자식 객체의 확장 과정에서 부모 객체의 의의에서 어긋나지 않게 부모 객체의 방향성을 따르는 것이 바람직하다코드 예제LSP가 적용되지 않은 코드#include class Rectangle {public: virtual void setWidth(int w) { width = w; } virtual void setHeight(int h) { height = h; } int getWidth() const { return width..

OCP(Open Closed Principle)객체의 확장에는 개방적이고 객체의 수정에는 폐쇄적이어야 한다는 원칙기능의 변화, 확장 OK. But, 해당하는 객체만 수정 O, 해당 객체에 의존하는 객체들까지 수정 Xㅡ> 각 객체의 모듈화, 정보 은닉의 올바른 구현 추구 ㅡ> 객체 간의 의존성 최소화 ㅡ>  코드 변경에 따른 영향력 축소ㅡ> 결론적으로 코드 유지보수의 효율성 향상코드 예제OCP가 적용되지 않은 코드class PolygonManager {public: void drawPolygon(int shapeType) { if (shapeType == 1) { // 삼각형 그리기 } else if (shapeType == 2) { /..

SRP(Single Responsibility Principle)각 클래스는 하나의 책임을 가져야 한다는 원칙클래스의 역할과 책임을 명확히 분리 ㅡ> 책임 의존성 과중 지양 ㅡ> 변경이 필수적인 경우에만 해당하는 클래스만 수정코드 예제SRP가 적용되지 않은 코드#include #include using namespace std;class Student {public: void setName(const string& name) { this->name = name; } void displayDetails() { cout = 90) { cout = 80) { cout 해당 코드는 SRP가 적용되지 않은 코드ㅡ> Student 클래..

객체 지향 설계 5원칙 SOLID1. SRP(Single Responsibility Principle) : 단일 책임 원칙하나의 클래스는 하나의 책임만 가져야 한다!클래스를 변경하는 이유는 단 하나여야 한다. 수정 사항이 있을 때 그에 따른 영향이 적어야 한다.그렇지 않으면, 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 미치고 결과적으로 유지보수가 매우 비효율적이게 된다.* 책임 : SRP에서 이야기하는 책임은 기능을 생각하면 된다. 보통 하나의 클래스가 수행할 수 있는 기능(책임)이 여러 개라면 좋을 것 같지만, 이는 클래스 내부의 함수끼리 강한 결합을 가질 가능성이 높고 이로 인해 코드의 효율도 저하된다. 객체지향 설계의 핵심은 높은 응집도, 낮은 결합도이다. 결합도가 높아지면 새로운 추..