设计者模式

最新推荐文章于 2022-08-29 22:49:31 发布

Shiny.cpp

最新推荐文章于 2022-08-29 22:49:31 发布

阅读量274

点赞数

本文链接：https://blog.csdn.net/lxn18392641463/article/details/73927423

版权

设计模式的六大原则：

设计模式六大原则（1）：单一职责原则

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。、

设计模式六大原则（2）：里氏替换原则

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：所有引用基类的地方必须能透明地使用其子类的对象。

问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

设计模式六大原则（3）：依赖倒置原则

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

设计模式六大原则（4）：接口隔离原则

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

设计模式六大原则（5）：迪米特法则

定义：一个对象应该对其他对象保持最少的了解。

问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：尽量降低类与类之间的耦合。

设计模式六大原则（6）：开闭原则

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

Singleton单件模式：只能有一个实列；

//Singleton.h

#ifndef _SINGLETON_H
#define _SINGLETON_H

#include<iostream>
using namespace std;

class Singleton
{
public:
	//静态的接口，可以直接使用类名调用就不需要对象调用//
	static Singleton* Instance();
protected:
	//不能实列化一个对象//
	Singleton();
private:
	//指向实列的对象//
	static Singleton* _instance;
};
#endif

//Singleton.cpp

#include"Singleton.h"

Singleton* Singleton::_instance=0;
Singleton::Singleton()
{
	cout<<"Singleton..."<<endl;
}
Singleton* Singleton::Instance()
{

    //适用于单线程，如果是多线程的话依然会有很多对象被实列化出来//
	if(_instance == 0)
	{
		_instance = new Singleton();
	}
	return _instance;
	
}

#if 1
#include"Singleton.h"
#include<iostream>
using namespace std;

int main()
{
	Singleton s;
	s.Instance ();
	Singleton *sng = Singleton::Instance();
	return 0;
}
#endif

上述代码只适合单线程模式，如果是多线程，则考虑以下2点：

1、判断if(_instance == 0)否，如果不等于就不进行同步；

2、if(_instance == 0)

{

同步的时候依然需要判决if(_instance == 0)

如果是，就不进行创建实列，否则就开始创建实列；

}

（二）Factory模式

/*工厂模式的实现案例*/

#include<iostream>

usingnamespace std;

#include<string.h>

//抽象角色

classFruit

{

public:

virtualvoid getFruit() = 0;//所有实例的公共接口

};

//具体产品类

classApple : public Fruit

{

public:

virtualvoid getFruit()

{

cout <<"Get apple!" << endl;

}

};

classBanana : public Fruit

{

public:

virtualvoid getFruit()

{

cout <<"Get Banana!" << endl;

}

};

classOrange : public Fruit

{

public:

virtualvoid getFruit()

{

cout <<"Get Orange!" << endl;

}

};

//抽象工厂类

classAbFactory

{

public:

virtual Fruit*Create() = 0;

};

//具体工厂类

classBananaFac : public AbFactory

{

public:

virtual Fruit*Create()

{

returnnew Banana();

}

};

classAppleFac : public AbFactory

{

public:

virtual Fruit*Create()

{

returnnew Apple();

}

};

intmain()

{

AbFactory *fac =NULL;

Fruit *f =NULL;

fac =new BananaFac();

f = fac->Create();

f->getFruit();

delete fac;

delete f;

return0;

}

（三）AbstractFactory模式

AbstractFactory模式是用来解决这类问题：要创建一组相关或者相互依赖的对象提供一个；创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

抽象工厂是针对很多产品，这些产品的等级不同，即抽象工厂面对的问题是多产品等级结构的系统设计，首先理解产品族，等级结构；

产品族：是指位于不同产品等级结构中，结构功能相关联的产品；

等级结构：相同等级结构不同产品构成，我所理解的是不同的具体抽象工厂来升级产品的等级；

//product.h
#ifndef _PRODUCT_H
#define _PRODUCT_H
class AbstractProductA
{
public:
	virtual ~AbstractProductA();
protected:
	AbstractProductA();
private:
};
class AbstractProductB
{
public:
	virtual ~AbstractProductB();
protected:
	AbstractProductB();
private:
};
class ProductA1:public AbstractProductA
{
public:
	ProductA1();
	~ProductA1();
protected:
private:
};
class ProductA2:public AbstractProductA
{
public:
	ProductA2();
	~ProductA2();
protected:
private:
};
class ProductB1:public AbstractProductB
{
public:
	ProductB1();
	~ProductB1();
protected:
private:
};
class ProductB2:public AbstractProductB
{
public:
	ProductB2();
	~ProductB2();
protected:
private:
};
#endif
//product.cpp
#include<iostream>
using namespace std;
#include"Product.h"
AbstractProductA::AbstractProductA()
{
	cout<<"AbstractProductA"<<endl;
}
AbstractProductA::~AbstractProductA()
{}
AbstractProductB::AbstractProductB()
{
	cout<<"AbstractProductB"<<endl;
}
AbstractProductB::~AbstractProductB()
{}
ProductA1::ProductA1()
{
	cout<<"ProductA1.."<<endl;
}
ProductA1::~ProductA1()
{}
ProductA2::ProductA2()
{
	cout<<"ProductA2.."<<endl;
}
ProductA2::~ProductA2()
{}
ProductB1::ProductB1()
{
	cout<<"ProductB1.."<<endl;
}
ProductB1::~ProductB1()
{}
ProductB2::ProductB2()
{
	cout<<"ProductB2.."<<endl;
}
ProductB2::~ProductB2()
{}
//AbstractFactory.h
#ifndef _ABSTRACTFACTORY_H_
#define _ABSTRACTFACTORY_H_
class AbstractProductA;
class AbstractProductB;
class AbstractFactory
{
public:
	virtual ~AbstractFactory();
	virtual AbstractProductA* CreateProductA()=0;
	virtual AbstractProductB* CreateProductB()=0;
protected:
	AbstractFactory();
private:
};
class ConcreteFactory1:public AbstractFactory
{
public:ConcreteFactory1();
	   ~ConcreteFactory1();
	   AbstractProductA *CreateProductA();
	   AbstractProductB* CreateProductB();
protected:
private:
};
class ConcreteFactory2:public AbstractFactory
{
public:
	ConcreteFactory2();
	~ConcreteFactory2();	
	AbstractProductA* CreateProductA();
	AbstractProductB* CreateProductB();
protected:
private:
};
#endif
//AbstractFactory.cpp
#include"AbstractFactor.h"
#include"Product.h"
#include<iostream>
using namespace std;
AbstractFactory::AbstractFactory()
{
	cout<<"AbstractFactory"<<endl;
}
AbstractFactory::~AbstractFactory()
{
}
ConcreteFactory1::ConcreteFactory1()
{
	cout<<"ConcreteFactory1"<<endl;
}
ConcreteFactory1::~ConcreteFactory1()
{}
AbstractProductA* ConcreteFactory1::CreateProductA()
{
	return new ProductA1();
}
AbstractProductB* ConcreteFactory1::CreateProductB()
{
	return new ProductB1();
}
ConcreteFactory2::ConcreteFactory2()
{
	cout<<"ConcreteFactory2"<<endl;
}
ConcreteFactory2::~ConcreteFactory2()
{
}
AbstractProductA* ConcreteFactory2::CreateProductA()
{
	return new ProductA2();
}

AbstractProductB* ConcreteFactory2::CreateProductB()
{
	return new ProductB2();
}
//main.cpp
#if 0
#include"AbstractFactor.h"
#include<iostream>
using namespace std;
int main()
{
	AbstractFactory *cf1 = new ConcreteFactory1();
	cf1->CreateProductA();
	cf1->CreateProductB ();
	AbstractFactory * cf2 = new ConcreteFactory2();
	cf2->CreateProductA();
	cf2->CreateProductB();
	return 0;
}
#endif

优缺点：
1 工厂类有个极大的问题。例如，如果以后增加了CreateC的函数，那么在所有类（基类和子类）都需要添加这个函数，即使这个函数生产出来的东西只是有个很小的变化----看来，如果基类开始不确定定义好的话，后续会有较大的改动。而且更深层次的意思是，如果要创建哪怕只有tcpsocket和其他不同的东西，都需要重新定义一个子类（意思是2个子类中，只有tcpsocket创建不一样，其他都一样，就这么简单的不同，都会需要重新定义一个子类）
2 一个工厂，每个产品都需要定义一个创建函数
如 NetServerFactory（抽象工厂）--->创建NetServer（具体工厂）---->创建CreateTCPSocket（具体产品）。多个产品有多个这样的create函数（又被称为工厂函数），太麻烦了，不如Create（enum socketType）来解决....

Shiny.cpp

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
设计者模式

设计模式的六大原则：设计模式六大原则（1）：单一职责原则设计模式六大原则（2）：里氏替换原则设计模式六大原则（3）：依赖倒置原则设计模式六大原则（4）：接口隔离原则设计模式六大原则（5）：迪米特法则设计模式六大原则（6）：开闭原则设计模式六大原则（1）：单一职责原则定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责
复制链接

扫一扫