设计模式~~

Sh1Yu6

于 2020-02-22 09:00:28 发布

阅读量175

点赞数

本文链接：https://blog.csdn.net/weixin_44277901/article/details/104438742

版权

一、原则

1. 依赖倒置原则

高层模块不应该依赖于底层模块, 二者应该依赖于抽象
抽象不应该依赖于实现细节, 实现细节应该依赖于抽象
即底层实现的变化, 不应该导致接口出现变化.
例子: 抽象出一个图形接口, 然后其他类(方形, 圆形)实现这个接口.
shape draw area
square 实现draw area
circle 实现draw area
如果有新的形状, 也只需要实现draw area即可

2. 开放封闭原则

对扩展开放, 对更改封闭
类模块应该是可扩展的, 但是不可修改
例子类似上例

3. 单一职责原则

一个类应该仅有一个引起它变化的原因
变化的方向隐含着类的责任

4. Liskov替换原则

子类必须能够替换他们的基类(is-a)
继承表达抽象类型

5. 接口隔离原则

不应该强迫客户程序依赖他们不用的方法
接口应该小而完备

6. 优先使用对象组合, 而不是类继承

7. 封装变化点

使用封装来创建对象之间的分界层, 让设计者可以再分界一侧进行修改, 而不会对另一侧产生不良的影响.从而实现层次间的松耦合.

8. 针对接口编程, 而不是针对实现编程

不将变量类型声明为某个特定的具体类, 而是声明为某个接口
客户程序无需获知对象的具体类型, 只需要知道对象所具有的接口
减少系统中各部分的依赖关系, 从而实现"高内聚, 松耦合"的类型设计方案

二、组件协作模式

现代软件专业分工之后的第一个结果是"框架与应用程序的划分", "组件协作"模式通过晚期绑定, 来实现框架与应用程序之间的松耦合, 是两个之间协作时常用的模式.
模板模式(Template Method)
策略模式(Strategy)
观察者模式(Observer/Event)
模板和策略的区别: 模板实现了大部分的代码, 只有小部分需要变化, 策略的不同算法之间代码冗余小. 模板针对一套算法, 策略针对多套算法.

1. 模板模式(Template Method)

     在软件构建过程中, 对于某一项任务, 它常常有稳定的整体操作结构, 但是各个子步骤有很多改变的需求, 或者由于固有的原因而无法和任务的整体结构同时实现.
     定义一个操作中的算法的骨架, 而将一些步骤延迟到子类中, 模板模式使得子类可以不改变一个算法的结构即可以重定义该算法的某些特定步骤.
     比如, C++的sort, 默认是从小到大排序, 当程序员在使用的时候可以传一个仿函数, 来改变排序规则.
     不要调用我, 让我来调用你

2. 策略模式(Strategy)

某些对象使用的算法可能多种多样, 如果这些算法都编码到对象中, 将会使对象变得异常复杂, 而且有时候支持不使用的算法也是一种性能负担…
定义一系列算法, 把他们一个个封装起来, 并且使它们可互相替换(变化). 该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展, 子类化);
父类为纯虚类, 而子类实现纯虚函数.这样就用扩展替代了修改
客户程序再根据调用不同的子类, 实现变化.

enum TaxBase{
	CN_Tax;
	US_Tax;
	DE_Tax;
};

class SalesOrder{
	TaxBase tax;
public:
	double CalculatyeTax(){ // 如果添加新的tax, 又要修改这个函数
		if(tax == CNxxxx){
		}else if(tax == USxxx){
		}else if(tax == DExxx){
		}
	}
};


//策略模式

class TaxStrategy{
public:
	virtual double calculate(const Context& context) = 0;
	virtual ~TaxStrategy(){}
}

class CNTax: public TAXStrategy{
public:
	virtual double calculate(const Context& context){
	};
};

class SalesOrder{
	TaxStrategy* strategy;
public:
	 SalesOrder(StrategyFactory* strategyFactory){
	 	this-.strategy = strategyFactory->NewStrategy();
	 }
	 ~SalesOrder(){
	 	delete this->strategy;
	 }
	 double calculateTax(){
	 	Context context;
	 	double val = strategy->calculate(context);
	 }
};

3. 观察者(Observer)

我们需要为某些对象建立一种"通知依赖关系", -----一个对象(目标对象)的状态发生变化, 所有的依赖对象(观察者对象)都将得到通知. 如果这样的依赖过于紧密, 将使软件不能很好低抵御变化

三、单一职责

四、对象创建

通过"对象创建"模式绕开new, 来避免对象创建过程中所导致的紧耦合(依赖工具类), 从而支持对象创建的稳定. 是接口抽象之后的第一步工作.

1. 工厂方法(Factory Method)

在软件系统中, 经常面临创建对象的工作, 由于需求的变化, 需要创建的对象的具体类型经常变化.
定义一个用于创建对象的接口, 让子类决定实例化哪个类.

class Base(){
};
class A: public Base{
};
class B: public Base{
};
class Factory{
public:
	virtual Base* CreateObject() = 0;
};
class AFactory:public Factory{
	Base* CreateObject(){
		return new A();
	}
};
class BFactory:public Factory{
	Base* CreateObject(){
		return new B();
	}
};
class Use{
	Factory* mFactory;
public:
	Use(Factory* factory):mFactory(factory){
	}
	void use1(){
		Base* base = mFactory->CreateObject();
	} 
};

2. 抽象工厂(Abstract Factory)

五、对象性能

面向对象很好的解决了"抽象"的问题, 但是必不可免的要付出一定的代价.

1. 单例模式(Singleton)

     保证某些类只有一个实例, 才能确保它们的逻辑正确性, 以及良好的效率.
     饿汉模式: 类加载的时候就初始化.
     懒汉模式:类第一次被使用的时候才初始化.

class Singleton{
	private:	// 构造函数必须设置成私有, 这样才不能被调用, 如果不创建的化, 系统会自动创建.
		Singleton();
		Singleton(const Singleton& rhs);
	public:
		static Singleton* getInstance();
		static Singleton* mInstance;
}
Singleton* Singleton::mInstance = nullptr;

//非线程安全
Singleton* Singleton::getInstance(){
	if(mInstance == nullptr){
		mInstance = new Singleton();
	}
	return mInstance;
}

//线程安全

//单锁, 代价过高, 每次都要锁和解锁
Singleton* Singleton::getInstance(){
	lock
	if(mInstance == nullptr){
		mInstance = new Singleton();
	}
	unlock
	return mInstance;
}

//双检查锁, 分配了之后, 就不会再加锁了, 双检查是因为避免进入if之后, 锁之前, 又有别的线程进来, 那就会多执行new 
//内存读写reorder不安全, reorder, 编译器优化之后, 指令不一定按我们想象的顺序执行
//先分配内存, 此时, mInstance不是nullptr, 但是还没有调用构造器, 而另一个线程调用发现不是nullptr, 直接返回, 就会出现问题
Singleton* Singleton::getInstance(){

	if(mInstance == nullptr){
		lock
		if(mInstance == nullptr){
			mInstance = new Singleton();
		}
		unlopck
	}

	return mInstance;
}