2학년 디자인 패턴 Structural Patterns

서지현·2021년 11월 30일
2학년 디자인패턴
0

디자인패턴

목록 보기
2/3

Adapter

  • 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 한다

  • 예시

  • UML

  • Target class(existing system)

    • client가 사용하고 있다
    • Request() 인터페이스 있다

  • Adaptee class(additional system)

    • specificRequest()

  • Adapter class

    • Target class를 수정하지 않아도 된다 -> additional service 가능
    • Target, Adaptee를 상속해서 두 클래스의 정보를 가질 수 있다

  • client -> Adapter(Request) -> Adaptee(SpecificReqest)

  • c++만 다중 상속 가능

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

class Target {
public:
	virtual void Request() {
		cout << "Existing Service" << endl;
	}
};

class Adaptee {
public:
	void SpecificRequest() {
		cout << "Added Service" << endl;
	}
};

class Adapter : public Target {
private:
	Adaptee* adaptee_;
public:
	Adapter(Adaptee* adaptee) : adaptee_(adaptee) {}
	void Request() {
		this->adaptee_->SpecificRequest();
	}
};

int main() {
	Target* target = new Target;
	target->Request();
	Adaptee* adaptee = new Adaptee;
	Adapter* adapter = new Adapter(adaptee);
	adapter->Request();
	return 0;
}
  • 장점 : 단일 책임의 원칙, existing class 수정없이 다른 기능을 추가할 수 있다
  • 단점 : additional 서비스 클래스가 많을 수록 복잡해 진다.
    -> 주로 existing class가 이미 충분히 커서 수정하기 힘든 경우 사용한다

Bridge

  • 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴이다

  • 예시

  • type1 : existing class

  • 상속을 사용하지 않는다

  • UML

  • Abstraction 클래스와 Implementor 클래스가 서로 상속관계가 아니다

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

class Implementation {
public:
	virtual void print() = 0;
};

class Abstraction {
protected:
	Implementation* implementation_;
public:
	Abstraction(Implementation* implementation) : implementation_(implementation) { }
	virtual void Operation() {
		cout << "Caffeine: ";
		this->implementation_->print();
	}
};

class ExtendedAbstraction : public Abstraction {
public:
	ExtendedAbstraction(Implementation* implementation) : Abstraction(implementation) { }
	void Operation() {
		cout << "Decaf: ";
		this->implementation_->print();
	}
};

class ConcreteImplementationA : public Implementation {
public:
	void print() {
		cout << "Hot" << endl;
	}
};

class ConcreteImplementationB : public Implementation {
public:
	void print() {
		cout << "Iced" << endl;
	}
};

int main() {
	Implementation* implementation = new ConcreteImplementationA;
	Abstraction* abstraction = new Abstraction(implementation);
	abstraction->Operation();

	implementation = new ConcreteImplementationB;
	abstraction = new ExtendedAbstraction(implementation);
	abstraction->Operation();
	return 0;
}
  • 찬성 : platform(implementation)-independent 클래스를 만들수 있다, 단일 책임의 원칙
  • 단점 : 패턴을 추가 할 경우 더 복잡해질 수 있다

composite

  • 객체들의 관계를 트리 구조로 구성하여 부분 - 전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다

  • 예시

  • 재귀패턴의 형태를 가짐

  • UML

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

class Component {
protected:
	Component* parent_;
public:
	void SetParent(Component* parent) {
		this->parent_ = parent;
	}
	Component* GetParent() const {
		return this->parent_;
	}
	virtual void Add(Component* component) {}
	virtual bool IsComposite() {
		return false;
	}
	virtual string Operation() = 0;
};

class Leaf : public Component {
public:
	string Operation() {
		return "Leaf";
	}
};

class Composite : public Component {
protected:
	list<Component*> children_;
public:
	void Add(Component* component) {
		this->children_.push_back(component);
		component->SetParent(this);
	}
	bool IsComposite() {
		return true;
	}
	string Operation() {
		std::string result;
		for (Component* c : children_) {
			if (c == children_.back()) result += c->Operation();
			else result += c->Operation() + "+";
		}
		return "Branch(" + result + ")";
	}
};

int main() {
	Component *c0 = new Composite;
	Component* l1 = new Leaf;
	Component* c1 = new Composite;

	c0->Add(l1);
	c0->Add(c1);

	cout << c0->Operation() << endl;

	return 0;
}

Decorator

  • 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브 클래스 대신 쓸 수 있는 유연한 대안이 될 수 있다.

  • 예시

  • UML

  • ConcreteComponent : basic object

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

class Component {
public:
	virtual string Operation() = 0;
};
class ConcreteComponent : public Component {
public:
	string Operation() {
		return "Coffee";
	}
};

class Decorator : public Component {
protected:
	Component* component_;
public:
	Decorator(Component* component) : component_(component) { }
	string Operation() {
		return this->component_->Operation();
	}
};

class ConcreteDecoratorA : public Decorator {
public:
	ConcreteDecoratorA(Component* component) : Decorator(component) { }
	string Operation() {
		return "syrup1 + ("	+ Decorator::Operation()+ ")";
	}
};

class ConcreteDecoratorB : public Decorator {
public:
	ConcreteDecoratorB(Component* component) : Decorator(component) {
	}
	string Operation() {
		return "syrup2 + ("	+ Decorator::Operation()+ ")";
	}
};

int main() {
	Component* coffee = new ConcreteComponent;
	coffee = new ConcreteDecoratorA(coffee); //syrup1 added
	coffee = new ConcreteDecoratorA(coffee); //syrup1 added
	coffee = new ConcreteDecoratorB(coffee); //syrup2 added
	coffee = new ConcreteDecoratorB(coffee); //syrup2 added
	coffee = new ConcreteDecoratorB(coffee); //syrup2 added
	cout << "RESULT: " << coffee->Operation();
	return 0;
}
  • 장점
    • 새 하위 클래스를 만들지 않고도 객체의 동작을 확장할 수 있다
    • 런타임에 객체에 책임을 추가하거나 제거할 수 있습니다
    • 객체를 여러개로 묶음으로써 여러 행돌을 결합할 수 있습니다.
    • 단일책임의 원칙
  • 단점
    • 래퍼 스택중에서 특정 래퍼를 제거하기 어렵습니다.
    • decorator 동작이 decorator스택의 순서에 의존하지 않는 방식으로 decorator를 구현하기 어렵습니다.

Facade

  • 하위 시스템을 사용하기 쉽게 만드는 상위 수준 인터페이스를 정의합니다.

  • 예시

  • UML

#include<iostream>
#include <list> 
#include<string>
using namespace std;

class Subsystem1 {
public:
	string init() { return "Subsystem1: Init!\n"; }
	string run() { return "Subsystem1: On!\n"; }
};
class Subsystem2 {
public:
	string init() { return "Subsystem2: Init!\n"; }
	string run() { return "Subsystem2: On!\n"; }
};

class Facade{
protected:
	Subsystem1* subsystem1_;
	Subsystem2* subsystem2_;
public:
	Facade(Subsystem1* subsystem1, Subsystem2* subsystem2) {
		this->subsystem1_ = new Subsystem1();
		this->subsystem2_ = new Subsystem2();
	}
	string Operation() {
		string result = "Initializing subsystems:\n";
		result += this->subsystem1_-> init();
		result += this->subsystem2_-> init();
		result += "Ready to use: \n";
		result += this->subsystem1_->run();
		result += this->subsystem2_->run();
		return result;
	}
};

int main() {
	Subsystem1* subsystem1 = new Subsystem1;
	Subsystem2* subsystem2 = new Subsystem2;
	Facade* facade = new Facade(subsystem1, subsystem2);
	cout << facade->Operation();
	return 0;
}

장점 : 서브 시스템의 복잡성으로부터 코드를 분리할 수 있다
단점 : 앱의 모든 클래스에 결합된 god 객체가 될 수 있다.

Flyweight

  • 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하며 사용하도록 하여 메모리 사용량을 최소화하는 패턴

  • 예시

  • UML

#include<iostream>
#include <list> 
#include<string>
#include<unordered_map>
using namespace std;

struct SharedState
{
	string type_, color_;
	SharedState(const string& type, const string& color)
		: type_(type), color_(color) { }
	friend ostream& operator<<(ostream& os, const SharedState& ss)
	{
		return os << "[ " << ss.type_ << " , " << ss.color_ << " ]";
	}
};
struct UniqueState
{
	string price_;
	UniqueState(const string& price) : price_(price) { }
	friend ostream& operator<<(std::ostream& os, const UniqueState& us)
	{
		return os << "[ " << us.price_ << " ]";
	}
};

class Flyweight
{
private:
	SharedState* shared_state_;
public:
	Flyweight(const SharedState* shared_state) : shared_state_(new SharedState(*shared_state)) { }
	Flyweight(const Flyweight& other) : shared_state_(new SharedState(*other.shared_state_)) { }
	SharedState* shared_state() const { return shared_state_; }
	void Operation(const UniqueState& unique_state) const
	{
		cout << "Flyweight: Displaying shared (" << *shared_state_
			<< ") and unique (" << unique_state << ") state." << endl;
	}
};

class FlyweightFactory
{
private:
	unordered_map<string, Flyweight> flyweights_;
	string GetKey(const SharedState& ss) const { return ss.type_ + "_" + ss.color_; }
public:
	FlyweightFactory(std::initializer_list<SharedState> share_states)
	{
		for (const SharedState& ss : share_states)
			this->flyweights_.insert(make_pair<string, Flyweight>(this->GetKey(ss), Flyweight(&ss)));
	}
	Flyweight GetFlyweight(const SharedState& shared_state)
	{
		string key = this->GetKey(shared_state);
		if (this->flyweights_.find(key) == this->flyweights_.end())
			this->flyweights_.insert(make_pair(key, Flyweight(&shared_state)));
		return this->flyweights_.at(key);
	}
	void ListFlyweights() const
	{
		size_t count = this->flyweights_.size();
		for (pair<string, Flyweight> pair : this->flyweights_) cout << pair.first << "\n";
	}
};

void AddItem(
	FlyweightFactory& ff, const string& price,
	const string& type, const string& color)
{
	cout << "Adding an item to DB." << endl;;
	const Flyweight& flyweight = ff.GetFlyweight({ type, color });
	flyweight.Operation({ price });
}

int main()
{
	FlyweightFactory* factory = new FlyweightFactory({ {"Americano", "black" }, { "Mocha", "white" } });
	factory->ListFlyweights();
	AddItem(*factory, "5000", "Americano", "black");
	AddItem(*factory, "6000", "Mocha", "white");
	AddItem(*factory, "4000", "Espresso", "black");
	factory->ListFlyweights();
	return 0;
}
  • 장점 : 프로그램에 유사한 객체가 많다고 가정하면 많은 RAM을 절약할 수 있다
  • 단점 : 코드가 훨씬 복잡해진다

Proxy

  • 프록시는 다른 무언가와 이어지는 인터페이스의 역할을 하는 클래스이다.

  • 예시

  • UML

#include<iostream>
#include <list> 
#include<string>
using namespace std;

class Subject {
public:
	virtual void Request() const = 0;
};
class RealSubject : public Subject {
public:
	void Request() const {
		cout << "Handling Request." << endl;
	}
};

class Proxy : public Subject {
private:
	RealSubject* real_subject_;
	bool CheckAccess() const {
		cout << "Proxy: Checking Access" << endl;
		return true;
	}
public:
	Proxy(RealSubject* real_subject) : real_subject_(new RealSubject(*real_subject)) { }
	void Request() const override {
		if (this->CheckAccess()) {
			cout << "Proxy: Access Granted" << endl;
			this->real_subject_->Request();
		}
	}
};

int main() {
	RealSubject* real_subject = new RealSubject;
	Proxy* proxy = new Proxy(real_subject);
	proxy->Request();
	return 0;
}

  • 장점

    • client가 알지 못하는 상태에서 서비스 객체를 제어할 수 있다
    • 서비스 객체의 수명 주기를 관리할 수 있다.

  • 단점

    • 서비스응답이 늦어질 수 있다.
profile
서지현
안녕하세요
이전 포스트

2학년 디자인패턴 Create Patterns

다음 포스트

2학년 디자인패턴 Behavioral Patterns

0개의 댓글

관련 채용 정보