首页 > 代码库 > 设计模式总结
设计模式总结
设计模式是一些前人对面向对象编程方式进行总结而得出的一些巧妙的编程技巧,通过学习《大话设计模式》这本书,一方面巩固了对c#的学习,还有一方面进一步了解了面向对象编程技巧。模式有非常多种。各有优缺点。可是还要根据实际情况而定。并非不论什么情况下某个模式都适用的,所以某个模式。指的是在某个详细情况下用这样的方法去编程实现。能够降低系统的开销、优化程序代码、提高效率等等。
以下则是我学习这本书的时候。每敲完一个实例之后。都用自己能理解的话对这个模式的理解的记录,既不官方,也不太通俗易懂,至少自己能看懂而已,有些还弄的不太懂,希望掠过的大鸟可以指导指导。当中也有一部分是对面向对象里面的一些元素的理解。也都请多多批评不吝赐教。顺序不太对,还有的是缺少了非常多模式,这里是由于当时敲完之后没进行及时的总结。然后就忘了,以后有机会再补吧!
原型模式
首先创造一个类A,类中包含各种私有属性和公有方法,可是新增了一个MemberwiseClone()方法(该方法是类里面默认自带的一个特殊的方法)。当你用A实例化一个对象a之后,再调用a的MemberwiseClone()方法赋给用A实例化的还有一个对象b,则b就是a的一个虚拟复制品,当b中使用某个方法传入数据时,那么这个数据就会覆盖原来与a同样的数据。达到了复制对象然后对对象的改动却不影响到其它的数据的作用。
外观模式
有多个子类都有相似的方法,使用的时候都须要共同调用。则能够创建一个类用以实例化这些子类,并分类创建调用这些子类的方法,这样就能够仅仅调用新类的某个方法(包括子类多个方法)来统一调用多个子类的方法。能够降低类间的耦合度
建造者模式
对复杂类抽象出父类。使得子类去实现这些复杂的细节,然后创建一个指挥者类,把父类放进去,与指挥者形成组合关系,实现的时候子类当作參数放进指挥者类中就可实例化出想要的对象。
接口:就像遥控器一样,接口提供一个方法,可是须要外接提供一个參数。然后详细的实现放在了实现的类里面。遥控器须要用户提供如调频的參数。而遥控器并不能播放视频,可是通过遥控器能够控制视频,这就是方法。
抽象类:为什么会有抽象类呢?由于假设没有抽象类的话。详细类假设太多。而且他们有非常多共性,那么要创建这么多类,就要多写非常多反复的代码。
中介者模式
有一个中介类(联合国)。他里面有各个终端类(国家)作为数据成员,创建终端类之后,各个终端类要发送消息给其它终端类,首先经过中介类的推断是发给谁,然后中介类负责找到接受者,然后传递消息。
这样就减轻了终端类的负担(寻找类的负担)。
模板方法模式
把不变的。但在实现里须要用到的代码放到父类中。这样子类在实现的时候仅仅须要调用父类方法和详细实现即可。假设有非常多子类,则都是通过调用父类。所以实现了代码的复用。
工厂方法模式
创造出一个类,不应该直接用来实例化。而是依赖于接口去实现,而假设要实现的类非常多或考虑到扩展,则应该创建一个接口工厂,然后继承这个接口工厂的工厂作为实现这些类的接口,再通过这些类的接口去实现这些类从而产生对象。(太绕了,我有点难以接受)
依赖倒转原则:类依赖于接口实现,接口不应依赖于类,这样无论你添加还是改动,都不会影响到其它类了。
反射-抽象工厂的数据訪问程序。。。没懂
状态模式
假设对象能够处在非常多种状态,那么能够将每一个状态写作一个类,并初始化状态,按线性链接的方式将全部状态链接起来。通过初始状态推断是否为初始。假设不是则转入下一个状态的推断。
适配器模式
某对象依赖于接口,后来扩展别的类之后却无法使用这个接口去訪问那个对象,所以再写一个接口来对接原来的接口。并使这个新街口能适应扩展出来的类(印象不太深,可能不正确)。
备忘录模式
假设某个对象A经历某些事件之后,其数据成员发生变化。假设想恢复到原来的状态,能够提前创建一个对象B用来存储这些数据成员,可是又不要直接进行赋值。还以能够再创建一个对象C用来作为创建对象B的工厂类。这样就能够让对象A通过对象C间接地将数据存储到对象B 里面。
组合模式
创建一个抽象类,子类A和B继承抽象类,可是仅仅有A真正的去实现父类的方法。并可将属于父类的子类装进一个类似数组的容器里面。然后我就不知道为什么要将这些子类放进去了!
单例模式
让自己给自己提供方法实例化自己。并保证仅仅能实例化一个,并把构造函数写成私有,仅仅能依靠全局变量的调用来调用该方法以实现实例化该类。
桥接模式
假设有两个占主体地位的比較顶层的父类,他们当中一个派生出来的类假设一层一层的继承下去。然后由于还有一个基类的不同。又要适应这还有一个类,那么这样就会导致要产生非常多类,并形成复杂的关系。
这个时候则能够让这两个类形成聚合关系,这时候仅仅须要对一个类下功夫(这个类的功能包含将还有一个类当作參数传递下去),就能够让功能就像是在适应一个类就能够了。这两个类之间用聚合符号链接起来像一座桥,所以叫桥接模式。
命令模式
明白的分工,顾客仅仅管下单子。无论肉串怎么做、还有没有,服务员仅仅管推断还有没有肉串。有就提交,以及满足顾客的服务,厨子仅仅管做菜。然后顾客通过提交详细的肉串给服务员。服务员再命令厨子去做,这就是命令模式。能够在命令类里面做个保存命令的数组,然后就能够满足客户添加和撤销命令了。
职责链模式
有不同级别的类,他们所能处理的请求也因级别而异,当接收到请求时,假设不能处理,则把请求传递给自己的上级(要有一个能设置自己上级的方法)。
设计模式总结