设计模式
设计模式是指在软件开发中,经过验证的,用于解决在特定环境下,重复出现的,特定问题的解决方案。
学习要素
找稳定点,和变化点,把变化点隔离出来。
先满足设计原则,慢慢迭代出设计模式。
设计原则
依赖倒置,开放封闭,面向接口,封装变化点,单一职责,里氏替换,接口隔离,组合由于继承
依赖倒置
高层模块不应该依赖于底层模块,两者都应该以来抽象。
抽象不应该以来具体的实现,具体的实现应该依赖于抽象。
开放封闭原则
一个类应该对扩展开放,对修改关闭。
在C++扩展时,尽量组合基类的指针,而不是基类的对象,因为指针可以指向多个内存空间,而且在声明时占用的内存更低。 两种扩展方式,组合基类的指针,继承基类虚函数的覆盖。
面向接口
不将变量类型声明为某个特定的具体类,而是声明为某个接口;
客户程序无需获取对象的具体类型,只需知道对象所具有的接口;
减少系统中各个部分的依赖关系,从而实现高内聚,低耦合的类型设计方案。
封装变化点
一个类应该仅有一个引起他变化的原因。
里氏替换
子类型必须能够替换掉他的父类型;主要出现在子类覆盖父类实现,原来使用父类型的程序可能出现错误,覆盖了父类的方法,却没实现父类的职责。
单一职责
一个类应该仅有一个引起他变化的原因。
组合优于继承
组合耦合度低,继承耦合度高。
模板方法
定义一些操作的算法骨架,而是将一些步骤延迟到子类当中。Template Method使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。
class zoneShow
{
public:
int type; //通过type去更新子流程的版本 当版本增多时版本会变得更复杂
void show()
{
//固定的表演流程
//控制子流程
if (show0())
{
playgame();
}
show2();
show3();
show4();
}
//接口隔离
private:
void playgame() {}
private:
bool show0()
{
return false;
}
void show2() {}
void show3() {}
void show4() {}
};
更新版本
#includeusing namespace std; class ZooShow { public: // 固定流程封装到这里 void Show() { Show0(); Show1(); Show2(); Show3(); } protected: // 子流程 使用protected保护起来 不被客户调用 但允许子类扩展 virtual void Show0(){ cout << "show0" << endl; } virtual void Show2(){ cout << "show2" << endl; } virtual void Show1() { } virtual void Show3() { } }; class ZooShowEx : public ZooShow { protected: virtual void Show1(){ cout << "show1" << endl; } virtual void Show3(){ cout << "show3" << endl; } virtual void Show4() { // } }; class ZooShowEx1 : public ZooShow { protected: virtual void Show0(){ cout << "show1" << endl; } virtual void Show2(){ cout << "show3" << endl; } }; class ZooShowEx2 : public ZooShow { protected: virtual void Show1(){ //声明为virtual 类型为和父类一样的protected cout << "show1" << endl; } virtual void Show2(){ cout << "show3" << endl; } }; int main () { ZooShow *zs = new ZooShowEx; //基类类型 子类方法 // ZooShow *zs1 = new ZooShowEx1; // ZooShow *zs2 = new ZooShowEx2; zs->Show(); return 0; }
本质
通过固定算法骨架约束子类的行为
观察者模式
背景
气象站发布气象资料给数据中心,数据中心经过处理,将气象信息更新到两个不同的显示终端。
变化点:
数据中心的处理方法,终端的数量也会变化。
稳定点:
气象站发布资料给数据中心。
正常的逻辑代码
class DisplayA
{
public:
void show(float temerature) {}
};
class DisplayB
{
public:
void show(float temerature) {}
};
class DisplayC
{
public:
void show(float temerature) {}
};
class WeatherData
{
};
class DataCenter
{
public:
float CalcTemperature()
{
WeatherData* data = GetWeatherData();//把气象数据封装成一个类
// ...
//此处是变化的
float temper;
return temper;
}
private:
WeatherData* GetWeatherData() {}
};
int main()
{
DataCenter* center = new DataCenter;
DisplayA* da = new DisplayA;
DisplayB* db = new DisplayB;
DisplayC* dc = new DisplayC;
float temper = center->CalcTemperature();
da->show(temper);
db->show(temper);
dc->show(temper);
return 0;
}
这样写有什么坏处呢?多个显示终端的show函数不统一,面向接口编程只是一个标准。并且这样写的依赖性较强,如果想显示数据首先需要在气象中心获取数据,然后在经过计算,计算之后的结果在发送给各个显示太。整个流程太过依赖。数据中心给计算中心发数据是间接性的,所以这样方法不合适。一个好的解决方案是,显示台,监视气象中心的变化,只要有新的数据了,就向数据中心获取数据。
#includeclass IDisplay { public: virtual void Show(float temperature) = 0; virtual ~IDisplay() {}; }; class DisplayA : public IDisplay { public: virtual void Show(float temperature) {} }; class DisplayB : public IDisplay { public: virtual void Show(float temperature) {} }; class WeatherData{}; class DataCenter { public: void Attach(IDisplay* ob) {}//增加显示站台 就是订阅 void Detach(IDisplay* ob) {}//删除显示站台 void Notify() { float temper = CalcTemperature(); for (auto iter = obs.begin(); iter != obs.end(); iter++) { (*iter)->Show(temper); } } private: virtual WeatherData* GetWeatherData();//声明为虚函数 virtual float CalcTemperature() { WeatherData* data = GetWeatherData(); // ... float temper; return temper; } private: std::vector obs; }; int main() { DataCenter* center = new DataCenter; IDisplay* da = new DisplayA(); IDisplay* db = new DisplayA(); //如果再有显示台增加就订阅 center->Attach(da); center->Attach(db); center->Notify(); center->Detach(db);//如果不在订阅了就删除 return 1; }
策略模式:
定义一系列算法,把它们一个一个封装起来,并且使他们相互替换。该模式使得算法可独立与其他的客户程序而变化。
背景
某商场节假日有固定的促销活动,为了增大促销力度,先提升国庆节促销活动规格。
如果一个程序只有稳定点,或者变化点不需要设计模式(脚本语言),
#includeusing namespace std; enum VacationEnum { VAC_Spring, VAC_QiXi, VAC_Wuyi, VAC_GuoQing, //VAC_ShengDan, }; class Promotion { public: VacationEnum vac; public: void activity() { if (vac == VAC_Spring) {} else if (vac == VAC_QiXi) {} else if (vac == VAC_Wuyi) {} else if (vac == VAC_GuoQing) {} } }; int main() { return 0; }
这样写,有什么坏处呢,我们知道活动是不变的,但活动的方式是改变的,
#includeusing namespace std; class Context {}; //面向接口编程,因为各个节日都有策略 变化点里面相同的东西 class ProStategy { public: virtual double CalcPro(const Context& ctx) = 0; virtual ~ProStategy() {}//父类的析构函数声明为virtual 为了释放子类的资源 }; class VAC_Spring :public ProStategy { virtual double CalcPro(const Context& ctx) {} }; class VAC_QiXi : public ProStategy { public: virtual double CalcPro(const Context& ctx) {} }; //两个七夕节日不同的版本 class VAC_QiXi1 : public VAC_QiXi { public: virtual double CalcPro(const Context& ctx) {} }; // cpp class VAC_Wuyi : public ProStategy { public: virtual double CalcPro(const Context& ctx) {} }; // cpp class VAC_GuoQing : public ProStategy { public: virtual double CalcPro(const Context& ctx) {} }; class VAC_Shengdan : public ProStategy { public: virtual double CalcPro(const Context& ctx) {} }; class Promotion // 稳定点 { public: Promotion(ProStategy* sss) : s(sss) {} ~Promotion() {} public: double CalcPromotion(const Context& ctx) { return s->CalcPro(ctx); //稳定点调用变化点 } private: ProStategy* s; //父类接收各种子类。 }; //如果有需要更新就添加一个类 int main() { Context ctx; ProStategy* vac_Spring = new VAC_Spring(); Promotion* promotion = new Promotion(vac_Spring);//父类接受各种子类 promotion->CalcPromotion(ctx); }



