創建型模式：主要實現單實例模式，簡單工廠模式，工廠方法模式
結構型模式：主要實現適配器模式，橋接模式
創建型模式：
對類的實例化過程進行了抽象，能夠將軟件模塊中對象的創建和對象的使用分離。爲了軟件的結構更加清晰，外界模塊中的對象只需要知道他們共同的接口，而不清楚具體對象的實現細節，使整個系統的設計更加符合單一職責原則。
創建型模式在創建了什麼，由誰創建，何時創建等方面都爲軟件設計者提供了儘可能答得靈活性。
- 簡單工廠模式
模式結構：
簡單工廠模式包含如下角色：
工廠角色
產品角色
具體產品角色
簡單工廠模式屬於類創建型模式，在簡單工廠模式中根據自變量的不同產生不同的實例。
實現代碼：
#include <iostream>
#include <memory>
using namespace std ;
//簡單工廠模式
class fruit {
public :
fruit() {
}
virtual ~fruit() {};
virtual void operation() = 0;
} ;
class apple : public fruit{
public :
apple() {}
~apple() {}
void operation() {
cout << "我是一個蘋果！" << endl ;
}
} ;
class grape : public fruit {
public :
grape() {
}
~grape() {
}
void operation() {
cout << "我是一個葡萄！" << endl ;
}
} ;
class factory {
public :
static shared_ptr<fruit> getPerson(int permission) {
if(permission == 0) {
//此處不能是實例化一個對象並返回，意思是例如 返回值改成person 這裏boss bos; return bos
//只能以引用的形式返回
shared_ptr<apple>per =shared_ptr<apple>(new apple);
return per ;
}
else {
shared_ptr<grape>per =shared_ptr<grape>(new grape);
return per ;
}
}
} ;
int main() {
cout << "生產水果...." << endl ;
shared_ptr<fruit> bos = factory :: getPerson(0) ;
bos->operation() ;
shared_ptr<fruit> emp = factory :: getPerson(1) ;
emp->operation() ;
return 0;
}
其中蘋果和葡萄屬於水果的子類，在工廠類中根據傳進來的參數不同，生產不同的水果。
簡單工廠模式的優缺點：
工廠類號有必要的判斷邏輯，可以決定在什麼時候創建哪一個產品類，客戶端可以免除直接創建工廠產品的對象的責任，而僅僅消費產品，簡單工廠通過這種做法實現了對責任的分割，它提供了專門的工廠類用於創建對象。
由於工廠類集成了所有產品的創建邏輯，一旦不能正常工作，整個系統都受到影響。
系統擴展困難，一旦添加產品就不得不修改工廠邏輯，在產品較多的時候，可能造成工廠邏輯過於複雜，不利於維護和擴展。
使用環境：
- 工廠方法模式
模式結構：
每個要生產的產品都由專門的工廠來生產。
工廠方法模式是簡單工廠模式的進一步推廣和抽象，由於使用了面向對象的多態性，工廠方法模式保持了簡單工廠的優點，克服了缺點，在工廠方法模式中，核心的工廠類不在負責所有產品的創建，而是將具體創建的職責交給子類去做，這個核心類僅僅負責給出具體工廠必須實現的接口，而不是負責那個產品類被實例化這種細節，這使得工廠方法模式可以允許系統在不修改工廠角色的情況下引進新產品。
模式結構：
抽象產品
具體產品
抽象工廠
具體工廠
代碼舉例：
#include <iostream>
#include <memory>
using namespace std ;
//工廠方法模式
class tv ;
class changhong_tv ;
class haier_tv ;
class tv_factory ;
class changhong_factory ;
class tv {
public :
tv() {}
virtual ~tv() {} ;
virtual void play()= 0 ;
} ;
class haier_tv : public tv{
public :
haier_tv() {}
~haier_tv() {}
void play() {
cout << "我是海爾電視" << endl ;
}
} ;
class changhong_tv : public tv {
public :
changhong_tv() {}
~changhong_tv() {}
void play() {
cout << "我是長虹電視" << endl ;
}
} ;
class tv_factory {
public :
tv_factory() {}
virtual ~tv_factory() {}
virtual shared_ptr<tv> produce() = 0;
} ;
class haier_factory : public tv_factory {
public :
shared_ptr<tv> produce() {
cout << "生產海爾電視機" << endl ;
shared_ptr<haier_tv> haier = shared_ptr<haier_tv>(new haier_tv) ;
return haier ;
}
} ;
class changhong_factory : public tv_factory {
public :
shared_ptr<tv> produce() {
cout << "生產長虹電視機" << endl ;
shared_ptr<changhong_tv> ctv = shared_ptr<changhong_tv>(new changhong_tv) ;
return ctv ;
}
} ;
int main() {
shared_ptr<tv_factory>tf = shared_ptr<haier_factory>(new haier_factory) ;
shared_ptr<tv> htv = tf->produce() ;
htv->play() ;
tf = shared_ptr<changhong_factory>(new changhong_factory) ;
shared_ptr<tv> ctv = tf->produce() ;
ctv->play() ;
return 0;
}
工廠方法模式模式的優缺點：
在工廠方法模式中，工廠方法用來創建客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被實例化這一細節，用戶只需要關心所需產品對應的工廠，無需關心創建細節，甚至無需知道具體產品類的類名。
基於工廠角色和產品角色的多態性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定創建何種產品對象，而如何創建這個對象的細節則完全封裝在具體工廠內部。工廠方法模式之所以又被稱爲多態工廠模式，就正是因爲所有的具體工廠類都具有同一抽象父類。
使用工廠方法模式的另一個優點是在系統中加入新產品時，無需修改抽象工廠和抽象產品提供的接口，無需修改客戶端，也無需修改其他的具體工廠和具體產品，而只要添加一個具體工廠和具體產品就可以了，這樣，系統的可擴展性也就變得非常好，完全符合“開閉原則”。
在添加新產品時，需要編寫新的具體產品類，而且還要提供與之對應的具體工廠類，系統中類的個數將成對增加，在一定程度上增加了系統的複雜度，有更多的類需要編譯和運行，會給系統帶來一些額外的開銷。
由於考慮到系統的可擴展性，需要引入抽象層，在客戶端代碼中均使用抽象層進行定義，增加了系統的抽象性和理解難度，且在實現時可能需要用到DOM、反射等技術，增加了系統的實現難度。
- 單例模式
如何保證一個類只有一個實例並且這個實例易於被訪問呢？定義一個全局變量可以確保對象隨時都可以被訪問，但不能防止我們實例化多個對象。
一個更好的解決辦法是讓類自身負責保存它的惟一實例。這個類可以保證沒有其他實例被創建，並且它可以提供一個訪問該實例的方法。這就是單例模式的模式動機。
單例模式的目的是保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。單例模式包含的角色只有一個，就是單例類——Singleton。單例類擁有一個私有構造函數，確保用戶無法通過new關鍵字直接實例化它。除此之外，該模式中包含一個靜態私有成員變量與靜態公有的工廠方法，該工廠方法負責檢驗實例的存在性並實例化自己，然後存儲在靜態成員變量中，以確保只有一個實例被創建。
餓漢式單例類在自己被加載時就將自己實例化。單從資源利用效率角度來講，這個比懶漢式單例類稍差些。從速度和反應時間角度來講，則比懶漢式單例類稍好些。
懶漢式單例類在實例化時，必須處理好在多個線程同時首次引用此類時的訪問限制問題，特別是當單例類作爲資源控制器，在實例化時必然涉及資源初始化，而資源初始化很有可能耗費大量時間，這意味着出現多線程同時首次引用此類的機率變得較大，需要通過同步化機制進行控制。
#include <iostream>
#include <memory>
using namespace std ;
//懶漢模式
//單例類的責任過重，在一定程度上違背了單一職責原則
//因爲單例類即充當了工廠角色，提供了工廠方法，同時又充當了
//產品角色，包含一些業務方法，將產品的創建和產品的本身功能融合
//在一起
class AA {
public :
static shared_ptr<AA> get_instance() {
if(aa == nullptr) {
aa = shared_ptr<AA>(new AA) ;
}
return aa ;
}
void print() {
cout<< "我就是單實例" << endl ;
}
~AA() {}
private :
AA() {}
static shared_ptr<AA> aa ;
} ;
shared_ptr<AA> AA :: aa = nullptr ;
int main()
{
shared_ptr<AA>aa = AA::get_instance() ;
aa->print() ;
return 0;
}
結構型模式
結構型模式(Structural Pattern)描述如何將類或者對象結合在一起形成更大的結構，就像搭積木，可以通過簡單積木的組合形成複雜的、功能更爲強大的結構。
結構型模式可以分爲類結構型模式和對象結構型模式：
類結構型模式關心類的組合，由多個類可以組合成一個更大的系統，在類結構型模式中一般只存在繼承關係和實現關係。
對象結構型模式關心類與對象的組合，通過關聯關係使得在一個類中定義另一個類的實例對象，然後通過該對象調用其方法。根據“合成複用原則”，在系統中儘量使用關聯關係來替代繼承關係，因此大部分結構型模式都是對象結構型模式。
- 適配器模式
在軟件開發中採用類似於電源適配器的設計和編碼技巧被稱爲適配器模式。
通常情況下，客戶端可以通過目標類的接口訪問它所提供的服務。有時，現有的類可以滿足客戶類的功能需要，但是它所提供的接口不一定是客戶類所期望的，這可能是因爲現有類中方法名與目標類中定義的方法名不一致等原因所導致的。
在這種情況下，現有的接口需要轉化爲客戶類期望的接口，這樣保證了對現有類的重用。如果不進行這樣的轉化，客戶類就不能利用現有類所提供的功能，適配器模式可以完成這樣的轉化。
在適配器模式中可以定義一個包裝類，包裝不兼容接口的對象，這個包裝類指的就是適配器(Adapter)，它所包裝的對象就是適配者(Adaptee)，即被適配的類。
適配器提供客戶類需要的接口，適配器的實現就是把客戶類的請求轉化爲對適配者的相應接口的調用。也就是說：當客戶類調用適配器的方法時，在適配器類的內部將調用適配者類的方法，而這個過程對客戶類是透明的，客戶類並不直接訪問適配者類。因此，適配器可以使由於接口不兼容而不能交互的類可以一起工作。這就是適配器模式的模式動機。
適配器模式包含如下角色：
Target：目標抽象類
Adapter：適配器類
Adaptee：適配者類
Client：客戶類
實現代碼：
#pragma once
#include <iostream>
#include <memory>
using namespace std ;
class adaptee ;
class target ;
class adapter ;
class adaptee {
public :
adaptee() {
cout << "創建了適配器" << endl ;
}
~adaptee() {}
void specific_request() {
cout << "我是適配器接口" << endl ;
}
} ;
class target {
public :
target() {}
virtual ~target() {}
virtual void request() = 0;
} ;
class adapter :public target{
public :
adapter():adt(nullptr) {}
~adapter() {}
void set_adaptee(shared_ptr<adaptee>adt) { this->adt = adt;}
void request() ;
private :
shared_ptr<adaptee> adt ;
};
#include "shi_pei_qi.h"
void adapter::request() {
shared_ptr<adaptee>adt(new adaptee) ;
if(adt ==nullptr) {
cout << "還沒註冊適配器" << endl ;
return ;
}
adt->specific_request() ;
}
int main() {
//創建一個父類
shared_ptr<target>tar(new adapter) ;
tar->request() ;
return 0;
}
多個適配器和和適配類
#pragma once
#include <vector>
#include <iostream>
#include <memory>
#include <string>
using namespace std ;
//加密適配器
class NewCipher ;
class Caesar ;
class DataOperator ;
class CipherAdapter ;
class NewCipherAdapter ;
class Target {
} ;
class DataOperator {
public :
DataOperator() {}
virtual ~DataOperator() {}
virtual string doEncrypt(int key, string ps) {return "" ;};
void setPassword(string pass) { password = pass ;}
string getPassword() { return password ;}
private :
string password ;
} ;
//原來的加密適配器
class CipherAdapter : public DataOperator{
public :
void setCeasar(shared_ptr<Caesar>cs) {
cae = cs ;
}
CipherAdapter() {}
string doEncrypt(int key, string ps) ;
private :
shared_ptr<Caesar> cae ;
} ;
class Caesar {
public :
string doEncrypt(int key, string ps) {
cout << "舊的加密適配器" << endl ;
cout << key << " " << ps << endl ;
return to_string(key)+"------->" +ps ;
}
} ;
//新的加密適配器
class NewCipherAdapter : public DataOperator{
public :
NewCipherAdapter() {}
string doEncrypt(int key, string ps) ;
private :
shared_ptr<NewCipher> nc ;
} ;
class NewCipher {
public :
string doEncrypt(int key, string ps) {
cout << "新的適配器" << endl ;
cout << key << " " << ps << endl ;
return to_string(key)+"============>"+ps ;
}
} ;
//舊的加密適配器系統
string CipherAdapter:: doEncrypt(int key, string ps) {
cae = make_shared<Caesar>() ;
string keys = cae->doEncrypt(key, ps) ;
return keys ;
}
string NewCipherAdapter:: doEncrypt(int key, string ps) {
nc = make_shared<NewCipher>() ;
string keys = nc->doEncrypt(key, ps) ;
return keys ;
}
int main() {
shared_ptr<DataOperator> dd = make_shared<CipherAdapter>() ;
//爲target類設置密碼
dd->setPassword("hello") ;
//使用原來的適配器
string res = dd->doEncrypt(123, dd->getPassword()) ;
cout << "舊的加密結果!\n" << res << endl ;
dd = make_shared<NewCipherAdapter>() ;
dd->setPassword("hello") ;
res = dd->doEncrypt(123, dd->getPassword()) ;
cout << "新的加密結果!" << endl ;
cout << res << endl ;
return 0;
}
模式優缺點
類適配器模式還具有如下優點：
由於適配器類是適配者類的子類，因此可以在適配器類中置換一些適配者的方法，使得適配器的靈活性更強。
類適配器模式的缺點如下：
Java不支持多重繼承的語言，一次最多隻能適配一個適配者類，而且目標抽象類只能爲抽象類，不能爲具體類，其使用有一定的侷限性，不能將一個適配者類和它的子類都適配到目標接口。
在以下情況下可以使用適配器模式：
系統需要使用現有的類，而這些類的接口不符合系統的需要。
想要建立一個可以重複使用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。
- 橋接模式
橋接模式(Bridge Pattern)：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。它是一種對象結構型模式，又稱爲柄體(Handle and Body)模式或接口(Interface)模式。
代碼實現：
#pragma once
#include <iostream>
#include <memory>
using namespace std ;
class RefinedAbstration ;
class Abstraction ;
class Implement ;
//接口
class Implement {
public :
Implement() {}
virtual ~Implement() {} ;
virtual void operationImpl() =0 ;
};
//實現接口A
class ConcretImplementorA : public Implement {
public :
void operationImpl() {
cout << "具體實現A" << endl ;
}
} ;
//實現接口B
class ConcretImplementorB : public Implement {
public :
void operationImpl() {
cout << "具體實現B" << endl ;
}
} ;
//抽象類
class Abstraction {
public :
Abstraction() {}
virtual ~Abstraction() {}
virtual void operation() = 0 ;
void getConcretImp(int flag) ;
protected :
shared_ptr<Implement> impl ;
};
//子類
class RefinedAbstration:public Abstraction{
public :
void operation() {
cout << "具體類調用具體實現的操作!" << endl ;
impl->operationImpl() ;
}
} ;
#include "bagage.h"
void Abstraction:: getConcretImp(int flag) {
if(flag == 1) {
impl = make_shared<ConcretImplementorA>() ;
}
else {
impl = make_shared<ConcretImplementorB>() ;
}
}
int main() {
shared_ptr<Abstraction> abs = make_shared<RefinedAbstration>() ;
abs->getConcretImp(1) ;
abs->operation() ;
abs->getConcretImp(2) ;
abs->operation() ;
}
多個畫筆可以對應不同種顏色：
實例代碼：
#pragma once
#include <iostream>
#include <memory>
using namespace std ;
class SmallPen ;
class BigPen ;
class MiddlePen ;
class Color ;
class Pen {
public :
Pen() {}
virtual ~Pen() {}
void getPenColor(int flag) ;
virtual void draw() = 0;
protected :
shared_ptr<Color>col ;
} ;
class SmallPen : public Pen {
public:
void draw() ;
} ;
class BigPen : public Pen {
public:
void draw() ;
};
class MiddlePen : public Pen {
public :
void draw() ;
};
class Color {
public :
Color() {}
virtual ~Color(){}
virtual void bepaint() = 0;
};
class Red : public Color {
public :
void bepaint() {
cout << "紅筆" << endl ;
}
};
class Blue : public Color{
public :
void bepaint() {
cout << "藍筆" << endl ;
}
} ;
class Black : public Color{
public :
void bepaint() {
cout << "黑筆" << endl ;
}
} ;
#include "mao_bi.h"
void Pen :: getPenColor(int flag) {
switch(flag) {
case 1:
col = make_shared<Red>() ;
break ;
case 2:
col = make_shared<Blue>() ;
break ;
default :
col = make_shared<Black>() ;
break ;
}
}
void SmallPen :: draw() {
cout << "小筆" << endl ;
col->bepaint() ;
}
void BigPen :: draw() {
cout << "粗筆" << endl ;
col->bepaint() ;
}
void MiddlePen:: draw() {
cout << "中性筆" << endl ;
col->bepaint() ;
}
int main() {
shared_ptr<Pen> pen = make_shared<SmallPen>() ;
pen->getPenColor(1) ;
pen->draw() ;
pen->getPenColor(1) ;
pen->draw() ;
shared_ptr<Pen> pen1 = make_shared<MiddlePen>() ;
pen1->getPenColor(1) ;
pen1->draw() ;
pen1->getPenColor(3) ;
pen1->draw() ;
shared_ptr<Pen> pen2 = make_shared<BigPen>() ;
pen2->getPenColor(2) ;
pen2->draw() ;
pen2->getPenColor(1) ;
pen2->draw() ;
return 0;
}
橋接模式的缺點
橋接模式的引入會增加系統的理解與設計難度，由於聚合關聯關係建立在抽象層，要求開發者針對抽象進行設計與編程。
橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用範圍具有一定的侷限性。
模式適用環境
在以下情況下可以使用橋接模式：
如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承聯繫，通過橋接模式可以使它們在抽象層建立一個關聯關係。
抽象化角色和實現化角色可以以繼承的方式獨立擴展而互不影響，在程序運行時可以動態將一個抽象化子類的對象和一個實現化子類的對象進行組合，即系統需要對抽象化角色和實現化角色進行動態耦合。
一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展。
雖然在系統中使用繼承是沒有問題的，但是由於抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。
對於那些不希望使用繼承或因爲多層次繼承導致系統類的個數急劇增加的系統，橋接模式尤爲適用。