设计模式开篇
1.概述
本系类设计模式主要参考是程杰的大话设计模式,根据个人在工作中的一些设想和总结组织而成,所以更新会慢点。主要还是自己想对设计模式做一个总结。
2.设计模式
模式定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再重复相同的工作。即模式是在特定环境中解决问题的一种方案。
从以上定义可用提取关键字为 问题 -> 解决 -> 核心 -> 重用
3.设计模式目的
目的是一方面是教你如何利用前人总结好的模板来进行自己的设计代码开发,另一方面增加程序的灵活性和可重用性,当然与敏捷开发紧密结合在一起。
4.设计模式四要素
标识
一个设计模式的标识是很重要的,其实就是模式名称,当说哪个设计模式名称的时候就很容易知道该模式作用是什么样的。
问题
用来说明这个模式是解决哪方面的问题的。它解释了设计问题和问题存在的前因后果。
解决方案
用来说明这个模式的执行。描述了设计的组成部分,部分之间的关系以及各自协作和职责。解决方案可用统一说是一个模板,当遇到同样的问题的时候可用套用这个方案。
效果
描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时,并不总提到模式效果,但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量,它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一,所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响,显式地列出这些效果对理解和评价这些模式很有帮助。一个好的设计模式的论述应该覆盖使用这个模型的优点和缺点。
5.设计模式分类
根据目的分为如下三类
- 创建型模式:主要用于创建对象;
- 结构型模式:主要用于处理类和对象的组合;
- 行为模式:主要描述对类和对象怎样交互和怎样分配职责。
根据范围分为如下两类
- 类模式
- 对象模式
6.模式解释(参照)
- 工厂方法模式(Factory Method):是一种常用的对象创建型设计模式,此模式的核心精神是封装类中不变的部分,提取其中个性化善变的部分为独立类,通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。它的核心结构有四个角色,分别是抽象工厂;具体工厂;抽象产品;具体产品
- 抽象工厂模式(Abstract Factory):为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类。
- 建造者模式 (Builder):将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
- 原型模式(Prototype):用原型实例指定创建对象的种类,并且通过拷贝这个原型来创建新的对象。
- 单例模式(Singleton):保证一个类仅有一个实例,并提供一个访问它的全局访问点。
- 适配器模式(Adapter):将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- 桥接模式(Bridge):将抽象部分与它的实现部分分离,使它们都可以独立地变化。
- 组合模式(Composite):将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
- 装饰器 (Decorator):动态地给一个对象添加一些额外的职责。就扩展功能而言, 它比生成子类方式更为灵活。
- 外观模式(Facade):为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
- 享元模式(Flyweight):运用共享技术有效地支持大量细粒度的对象。
- 代理模式(Proxy):为其他对象提供一个代理以控制对这个对象的访问。
- 解释器模式(Interpreter):给定一个语言, 定义它的文法的一种表示,并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
- 模板方法(Template Method ):定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 职责链模式(Chain of Responsibility) :为解除请求的发送者和接收者之间耦合,而使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。
- 命令模式(Command):将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作。
- 迭代器模式(Iterator):提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
- 中介者模式(Mediator) :用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
- 备忘录模式(Memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
- 观察者模式(Observer):定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
- 状态模式(State):允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
- 策略模式(Strategy):定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
- 访问者模式(Visitor):表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
7.设计模式六大原则
1.核心原则:开放-封闭原则(开-闭 原则)
软件实体(类,模块,函数等等)应该是可用扩展,但不可以修改。
这个原则实际上有两个特征:一个是说“对于扩展是可开放的”,另一个是“对于更改是封闭的”【ASD】这个原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是 可维护, 可扩展, 可服用, 灵活性好。开发人员应该仅对程序中呈现出频率变化的那些部分做出抽象,然而,对于应用程序中的每个部分都刻意地进行抽象同样并不是一个好主意。
2.面向对象设计标识:依赖倒转原则
- 高层模块不应该依赖底层模块。两个模块之间应该依赖抽象
- 抽象不应该依赖细节。细节应该依赖抽象。
3.里氏代换原则
子类型必须能够替换掉它们的父类型。就是一个软件实体如果使用的是一个父类的话,那么一定适用其子类,而且它察觉不出父类对象和子类对象的区别。也就是说,在软件实体中,把父类都替换成它的子类,程序行为没有变化。只有当子类可以替换掉父类,软件功能不受影响时,父类才能真正的被复用,而子类也能够在父类的基础上增加新的行为。
4.单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者会抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
5.迪米特法则
如果两个类不必彼此直接通信,那么这两个就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。迪米特原则强调的前提是在类的结构设计上,每一个类都应当尽量降低成员的访问权限。实际上是强调类之间的松耦合。
6.接口隔离法则
使用多个专门的接口比使用单一的总接口总要好。换而言之,从一个客户类的角度来讲:一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
迪米特法则是目的,而接口隔离法则是对迪米特法则的规范。为了做到尽可能小的耦合性,我们需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则。