设计模式精解GOF23种设计模式解析VS重写实现包含LinuxMakefile代码和原文档已插入本文档.docx
- 文档编号:15832853
- 上传时间:2023-07-08
- 格式:DOCX
- 页数:19
- 大小:1.45MB
设计模式精解GOF23种设计模式解析VS重写实现包含LinuxMakefile代码和原文档已插入本文档.docx
《设计模式精解GOF23种设计模式解析VS重写实现包含LinuxMakefile代码和原文档已插入本文档.docx》由会员分享,可在线阅读,更多相关《设计模式精解GOF23种设计模式解析VS重写实现包含LinuxMakefile代码和原文档已插入本文档.docx(19页珍藏版)》请在冰点文库上搜索。
设计模式精解GOF23种设计模式解析VS重写实现包含LinuxMakefile代码和原文档已插入本文档
设计模式笔记(C++)
一、创建型
Factory:
工厂
1、定义创建对象的接口,封装了对象的创建
2、使得具体化类的工作延迟到了子类中
3、Factory模式正如我在相应的文档中分析的是为一类对象提供创建接口或者延迟对象的创建到子类中实现。
AbstractFactory:
抽象工厂
1、创建一组相关或者相互依赖的对象
2、AbstractFactory模式是为创建一组(有多类)相关或者依赖的对象提供创建接口
3、AbstractFactory模式通常都是使用Factory模式实现(ConcreateFactroy)
Singleton:
单例
1、Singleton模式保证一个类仅有一个对象,并提供一个访问它的全局访问点。
2、全局变量不能防止实例化多个对象。
3、全局变量将使得对象在无论是否用到都要被创建。
Builder:
创建者
1、Builder模式的意图是非常容易理解、间接的:
将一个复杂对象的构建与它的表示分离,使用同样的构建过程可以创建不同的表示(在示例代码中可以通过传入不同的参数实现这一点)。
Builder模式和AbstractFactory模式在功能上很相似,因为都是创建大的复杂的对象,它们的区别是:
Builder模式强调的是一步步创建对象,并通过相同的创建过程可以获得不同的结果对象,一般来说Builder模式中对象不是直接返回的。
而在AbstractFactory模式中对象是直接返回的,AbstractFactory模式强调的是为创建多个相互依赖的对象提供一个同一的接口。
Prototype:
原型
1、Prototype模式通过复制原型(Prototype)而获得新对象创建的功能,这里Prototype本身就是“对象工厂”(因为能够生产对象),实际上Prototype模式和Builder模式、AbstractFactory模式都是通过一个类(对象实例)来专门负责对象的创建工作(工厂对象),它们之间的区别是:
Builder模式重在复杂对象的一步步创建(并不直接返回对象),AbstractFactory模式重在产生多个相互依赖的对象,而Prototype模式重在从自身复制自己创建新类。
二、结构型
Bridge:
桥梁
1、Bridge模式将抽象和实现分别独立实现
2、Bridge中设计模式中比较复杂和难理解的模式之一,也是OO开发与设计中经常会用到的模式之一。
使用组合(委托)的方式将抽象和实现彻底地解耦,这样的好处是抽象和实现可以分别独立地变化,系统的耦合性也得到了很好的降低。
3、使用Bridge模式和使用带来问题方式的解决方案的根本区别在于是通过继承还是通过组合的方式去实现一个功能需求。
Adapter:
适配器
1、Adapter模式的两种类别:
类模式和对象模式
2、类模式Adapter中,我们通过private继承Adaptee获得实现继承的效果,而通过public继承Target获得接口继承的效果。
3、在Adapter模式的两种模式中,有一个很重要的概念就是接口继承和实现继承的区别和联系。
接口继承和实现继承是面向对象领域的两个重要的概念,接口继承指的是通过继承,子类获得了父类的接口,而实现继承指的是通过继承子类获得父顺的实现(并不统共接口)
Decorator:
装饰者
1、Decorator提供了一种给类增加职责的方法,不是通过继承实现,而是通过组合。
2、Decorator模式除了采用组合的方式取得了比采用继承方式更好的效果,Decorator模式还给设计带来一种“即用即付”的方式来添加职责。
Composite:
组成、树
1、递归构建树状的组合结构
2、Composite模式通过和Decorator模式有着类似的结构图,但是Composite模式旨在构造类,而Decorator模式重在不生成子类即可给对象添加职责。
Decorator模式重在修饰,而Composite模式重在表示。
Flyweight:
享元
1、
2、
Flyweight模式中有一个类似Factory模式的对象构造工厂FlyweightFactory,当客户程序员(Client)需要一个对象的时候就会向FlayweigthFactory发出请求对象的消息GetFlyweigth()消息,FlyweightFactory拥有一个管理、存储对象的“仓库”(或者叫对象池,vector实现),GetFlyweight()消息会遍历对象池中的对象,如果已经存在则直接返回给Client,否则创建一个新的对象返回给Client。
当然可能也有不想被共享的对象(例如结构图中的UnshareConcreateFlyweight),但不在本模式的讲解范围,故在实现中不给出。
Facade:
外观
1、
2、
Facade模式在高层提供了一个统一的接口,解耦了系统。
设计模式中还有另一种模式Mediator也和Facade有类似的地方。
但是Mediator主要目的是对象间的访问的解耦。
Proxy:
代理
1、Proxy模式最大的好处就是实现了逻辑和实现的彻底解耦。
2、虚代理(VirtualProxy)
3、远程代理(RemotoProxy)
4、保护代理(ProtectionProxy)
5、智能指针(SmartPointer)
三、行为
Template:
模板
1、对于某一个业务逻辑(算法实现)在不同的对象中有不同的细节实现,但是逻辑(算法)的框架(或通用的应用算法)是相同的。
Template提供了这种情况的一个实现框架。
2、Template模式是采用继承的方式实现这一点:
将逻辑(算法)框架放在抽象基类中,并定义好细节接口,子类中细节。
3、Strategy(策略)模式解决的是和Template模式类似的问题,但是Strategy模式是将逻辑(算法)封装到一个类中,并采取组合(委托)的方式解决这个问题。
4、Template模式是很简单模式,但是也应用很广的模式。
如上面的分析稆实现中阐明的Template是采用继承方式实现算法的异构,其关键点就是通用算法封装在抽象基类中,并将不同的算法细节放到子类中实现。
Template模式获得一种反向控制结构效果,这也是面向对象系统的分析和设计中一个原则DIP(依赖倒置:
DependencyInversionPrinciples)。
其含义就是父类调用子类的操作(高层模块调用低层模块的操作),低层模块实现高层模块声明的接口。
这样控制权在父类(高层模块),低层模块反而要依赖高层模块。
Template模式实际上就是利用面向对象中多态的概念实现算法实现细节和高层的接口的松耦合。
可以看到Template模式采取的是继承方式实现这一点的,由于继承是一种强制约束性的条件,因此也给Template模式带来一些许多不方便的地方。
Strategy:
策略
1、Strategy模式和Template模式要解决的问题是相同(类似)的,都是为了给业务逻辑(算法)具体实现和抽象接口之间的解耦。
Strategy模式将逻辑(算法)封装到一个类(Context)里面,通过的方式将具体算法的实现在组合对象中实现,再通过委托的方式将抽象接口的实现委托给组合对象实现。
State模式也有类似的功能。
2、Strategy模式和Template模式实际是实现一个抽象接口的两种方式:
继承和组合之间的区别。
3、继承:
优点:
(1)易于修改和扩展那些被利用的实现
缺点:
(1)破坏了封装性,继承中父类的实现细节暴露给子类了
(2)“白盒”复用
(3)当父类的实现更改时,其所有子类将不得不随之改变
(4)从父类继承而来的实现在运行期间不能改变(编译期间就已经确定了)
4、组合
优点:
(1)“黑盒”复用,因为被包含对象的内部细节对外是不可见的
(2)封装性好
(3)实现和抽象的依赖性很小(组合对象和被组合对象之间的依赖性小)
(4)可以在运行其它动态定义实现(通过一个指向相同类型的指针,典型的是抽象类的指针)
缺点:
(1)系统中对象过多
5、面向对象的设计中的有一条很重要的原则就是:
优先使用(对象)组合,而非(类)继承(FavorCompositionOverInheritance)
6、Strategy模式和State模式也有相似之处,但是State模式注重的对象在不同的状态下不同的操作。
两者之间的区别就是State模式中具体实现类中有一个指向Context的引用,而Strategy模式则没有。
State:
状态
1、将State声明为Context的友元类(FriendClass),其作用是让State模式访问Context的protected接口ChangeState()
2、State及其子类中的操作都将Context*传入作为参数,其主要目的是State类可以通过这个指针调用Context中的方法(在本示例代码中没有体现)。
这也是State模式和Strategy模式的最大区别所在。
3、State和Strategy
相同:
它们都有一个Context类,都是通过委托(组合)给一个具有多个派生类的多态基类实现Context的算法逻辑。
区别:
State模式中派生类持有指向Context对象的引用,并通过这个引用调用Context中的方法,但在Strategy模式中就没有这种情况。
因此可以说一个State实例同样是Strategy模式的一个实例,反之却不成立。
State模式主要是要适应对象对于状态改变时的不同处理策略的实现,而Strategy则主要是具体算法和实现接口的解耦(coupling),Strategy模式中并没有状态的概念(虽然很多时候有可以看作是状态的概念),并且更加不关心状态的改变。
Observer:
观察者
1、Observer模式应该可以说是应用最多、影响最广的模式之一,因为Observer的一个实例Model/View、Control(MVC)结构在系统开发架构设计中有着很重要的地位和意义,MVC实现了业务逻辑和表示层的解耦。
个人也认为Observer模式是软件开发过程中必须要掌握和使用的模式之一。
2、Observer模式要解决的问题为:
建立一个一(Subject)对多(Observer)的依赖关系,并且做到当“一”变化的时候,依赖这个“一”的多也能够同步改变。
Memento:
备忘
1、Memento模式的关键就是在不破坏封装的前提下,捕获并保存一个类的内部状态,这样就可以利用保存的状态实施恢复操作。
2、
Mediator:
中介者
1、Mediator模式提供将对象间的交互和通讯封装在一个类中,各个对象间的通信不必显式去声明和引用,大大降低了系统的复杂性能。
2、Mediator模式还带来了系统对象间的松耦合
Command:
命令
1、Command模式通过将请求封装到一个对象(Command)中,并将请求的接受者存放到具体的ConcreateCommand类中(Receiver)中,从而实现调用操作的对象和操作的具体实现者之间的解耦。
2、模板类的构造函数必须要实现,要不编译通过,连接不上,错误提示也不准确(模板类的函数指针)
Command模式结构中,将请求的接收者(处理者)放到Command的具体子类ConcreateCommand中,当请求到来时(Invoker发出Invoke消息激活Command对象),ConcreateCommand将处理请求交给Receiver对象进行处理。
Visitor:
访问者
1、Visitor模式则提供了一个解决方案:
将更新(变更)封装到一个类中(访问操作),并由待更改类提供一个接收接口,则可达到效果。
2、
Visitor模式在不破坏类的前提下,为类提供增加新的操作。
Visitor模式的关键是双分派(Double-Dispatch)的技术。
(双分派意味着执行的操作将取决于请求的种类和接收者的类型)
在Visitor模式中Accept()操作是一个双分派的操作。
具体调用哪一个具体的Accept()操作,有两个决定因素:
(1)Element的类型。
因为Accept()是多态的操作,需要具体的Element类型的子类才可以决定到底调用哪一个Accept()实现。
(2)Visitor类型。
Accept()操作有一个参数(Visitor*vis),要决定了实际传进来的Visitor的实际类别才可以决定具体是调用哪个VisitorConcrete()实现。
3、问题
(1)破坏了封装性
(2)ConcreateElement的扩展很困难
ChainofResponsibility:
责任链
1、ChainofResponsibility模式描述其实就是这样一类问题将可能处理一个请求的对象链接成一个链,并将请求在这个链上传递,直到有对象处理该请求(可能需要提供一个默认处理所有请求的类)
2、ChainofResponsibility模式最大的一个优点就是给系统降低了耦合性,请求的发送者完全不必知道该请求会被哪个应答对象处理,极大地降低了系统的耦合性。
Iterator:
游标(Cursor)
1、Iterator模式也正是用来解决对一个聚合对象遍历问题,将对聚合的遍历封装到一个类中进行,这样就避免了暴露这个聚合对象的内部表示的可能。
2、
Interpreter:
解析器
1、Interpreter模式的目的就是使用一个解释器为提供一个一门定义语言的语法表示的解析器,然后通过这个解释器来解释语言中的句子。
2、
补充State:
状态
1、State模式会处理算法的不同,但是更加关注的是状态的改变。
2、
4、附件(原文?
和代?
)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 设计 模式 GOF23 解析 VS 重写 实现 包含 LinuxMakefile 代码 文档 插入
![提示](https://static.bingdoc.com/images/bang_tan.gif)
链接地址:https://www.bingdoc.com/p-15832853.html