对设计模式的一些总结

OOP思想:抽象、继承、多态、统一接口、功能最小化、对象只对自己负责
设计模式原则:“开-闭原则“,“优先使用组合”


对设计模式的一些总结:

外观模式:”将复杂的接口简单化“
最底层(最接近实现)的模式,其上层可以是桥接模式,可以是抽象工厂模式,甚至是最简单
的模板方 法模式,甚至什么模式都没有,仅仅是简单的类封装或函数封装,但是它却是我们生活中实实在
在最常用的模式之一,它封装复杂的功能,向上展现简单的 接口或方法。TerryLee常说外观模式是亡羊补牢,
我觉得还应该发挥我们的“拿来主义”,对我们有用的东西我们就毫不客气地拿来,使用外观模 式加以利用。

适配式模式:“转换接口“
适配器模式和外观模式有很多相似的地方,两者都是用在最接近实现的层次,而且都是封装转换。
但适配器模式 更注重于转换接口。

在实际使用中,我们不必拘泥于这两者的区别,这是很重要的。

抽象工厂模式:“系例化工厂生产系列化对象“
这是大家所认为最没有明显优点的模式了,从短期来看,它甚至把简单的问题复杂化了。
它 屏蔽我们通常的new,将类的实例化封装起来,并延迟到工厂对象中,通过工厂的CreateInstance()
方法来管理。通常一个工厂只负责 生产一种产品,所以的工厂和所以的产品都拥有统一的接口,
都通过抽象工厂或抽象产品来派生。

工厂方法有很好变种,但它们统一的特点就是,屏蔽了用户直接new对象,给库接口设计者提供了
切换对象的空间,当然,也可以由用户来选择工 厂。

桥接模式:“将对象的变化部分分离开来,实现形态与变化的分离“
如果一个抽象的类存在多个变化部分,如形状和行为,采用传统派生的方法必须 造成类爆炸现象。
桥接模式,将这两个变化部分分离,实现松耦合。

装饰模式:“对现有的接口进行包装,增加新的功能“
装饰模式和桥接模式、外观模式有相似的地方,它们都面向已有的接口,后两者的注重转换, 而
装饰模式注重增加新功能。

模板方法模式:“提供抽象的基类接口“
最简单也是最常见的模式这一。如插件设计。

命令模式
命令模式有三个用法:
1 “OOP时代回调的替代,扩展性好“
回调实现了调用者也被调用者的分离,调用者不用关心 被调用者(是否存在,在哪里)。但调用者
与被调用者需要函数形式的协商。
OOP时代,命令模式用来代替回调,调用者与被调用者需要类名及 接口的协商。客户可以将派生的
类对象传递给调用者,由调用者在必要的时候调用对象的协商方法(Execute())。
特点:由于类可以派 生,因而只要一个协商,就可以实现多个命令的回调,而更容易管理。传统回调
必须每一个都要协商。
2. “集中管理命令代码”
如菜 单命令管理,client只需要将要执行的代码封装在Command对象,并以name-Command的方式,向
命令管理者注册,就可以在需要 的时候以name的方式执行这段代码。
3. “以任务的方式下达命令“
命令执行者不需要知道命令的名字、类型,client下达命令对 象,执行者无条件执行。

迭代器模式:“隐藏数据及Iteator的细节“
提供GetItemCount(), Move(n), MoveFirst(), MoveNext(), MovePrevs(), MoveLast()等方法来
访问迭代器数据。

观察者模式:“处理1:n的依赖变化关系”
将管理观察者的责任由client转移到了观察者本身。将被依赖者的变化,调用观察者的通知方 法,
使观察者主动更新数据。这实现了用户与(依赖者和观察者)的解耦,增大了依赖者和观察者耦合
关系。

生成器/建造者模式:“Driver-Builder-对象”
举个例子来说明:
顾客去KFC买套餐,他把要求告诉收银员 (Driver),收银员然后通告工作人员(Builder),
工作人员把食品(对象)按照需求收集过来(算法),交给收银员,然后由收银员交给 顾客。
这和工厂模式有些相似,但是不同之处是一个工厂只生产一种产品,而且生产过程比较简单(new)。
建器者模式的侧重点是,由 Driver选择不同的Builder,生产出较为复杂的产品。生产的过程对
Driver也是透明的。


单件模式:“保证只有一个实例“
getInstance()

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值