设计模式
1995 年,艾瑞克·伽马(ErichGamma)、理査德·海尔姆(Richard Helm)、拉尔夫·约翰森(Ralph Johnson)、约翰·威利斯迪斯(John Vlissides)等 4 位作者合作出版了《设计模式:可复用面向对象软件的基础》(Design Patterns: Elements of Reusable Object-Oriented Software)一书,在本教程中收录了 23 个设计模式,这是设计模式领域里程碑的事件,导致了软件设计模式的突破。这 4 位作者在软件开发领域里也以他们的“四人组”(Gang of Four,GoF)匿名著称。
软件设计模式的基本要素
软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构,它通常包含以下几个基本要素:模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等,其中最关键的元素包括以下 4 个主要部分。
- 模式名称
每一个模式都有自己的名字,通常用一两个词来描述,可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名称(PatternName)有助于我们理解和记忆该模式,也方便我们来讨论自己的设计。
- 问题
问题(Problem)描述了该模式的应用环境,即何时使用该模式。它解释了设计问题和问题存在的前因后果,以及必须满足的一系列先决条件。
- 解决方案
模式问题的解决方案(Solution)包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板,可应用于多种不同场合,所以解决方案并不描述一个特定而具体的设计或实现,而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合(类或对象的 组合)来解决这个问题。
- 效果
描述了模式的应用效果以及使用该模式应该权衡的问题,即模式的优缺点。主要是对时间和空间的衡量,以及该模式对系统的灵活性、扩充性、可移植性的影响,也考虑其实现问题。显式地列出这些效果(Consequence)对理解和评价这些模式有很大的帮助。
设计模式划分
设计模式有两种分类方法,即根据模式的目的来分和根据模式的作用的范围来分。
- 根据目的来分
根据模式是用来完成什么工作来划分,这种方式可分为创建型模式、结构型模式和行为型模式 3 种。
创建型模式:用于描述“怎样创建对象”,它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
结构型模式:用于描述如何将类或对象按某种布局组成更大的结构,GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
行为型模式:用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。
- 根据作用范围来分
根据模式是主要用于类上还是主要用于对象上来分,这种方式可分为类模式和对象模式两种。
类模式:用于处理类与子类之间的关系,这些关系通过继承来建立,是静态的,在编译时刻便确定下来了。GoF中的工厂方法、(类)适配器、模板方法、解释器属于该模式。
对象模式:用于处理对象之间的关系,这些关系可以通过组合或聚合来实现,在运行时刻是可以变化的,更具动态性。GoF 中除了以上 4 种,其他的都是对象模式。
设计模式常用七大原则
-
单一职责原则
-
接口隔离原则
-
依赖倒转原则
-
里式替换原则
-
开闭原则 OCP
-
迪米特法则
-
合成复用原则
单一职责原则
1.降低类的复杂度,一个类只负责一项职责;
2.提高类的可读性,可维护性;
3.降低变更引起的风险;
接口隔离原则
客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上
依赖倒转(倒置)原则
- 依赖倒转原则(Dependence Inversion Principle)是指:
-
高层模块不应该依赖低层模块,二者都应该依赖其抽象
-
抽象不应该依赖细节,细节应该依赖抽象
-
依赖倒转(倒置)的中心思想是面向接口编程
-
依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中,抽象指的是接口或抽象类,细节就是具体的实现类
-
使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成
- 依赖倒转原则的注意事项和细节
-
低层模块尽量都要有抽象类或接口,或者两者都有,程序稳定性更好.
-
变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间,就存在
一个缓冲层,利于程序扩展和优化
- 继承时遵循里氏替换原则
里式替换原则
OO中的继承性的思考和说明
-
继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏。
-
继承在给程序设计带来便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障
-
问题提出:在编程中,如何正确的使用继承? => 里氏替换原则
- 基本介绍
- 里氏替换原则(Liskov Substitution Principle)在1988年,由麻省理工学院的以为姓里
的女士提出的。
- 如果对每个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1
的子类型。换句话说,所有引用基类的地方必须能透明地使用其子类的对象。
-
在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
-
里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,在适当的情况下,可以通过聚合,组合,依赖 来解决问题。
- 解决方法
- 我们发现原来运行正常的相减功能发生了错误。原因就是类B无意中重写了父类的
方法,造成原有功能出现错误。在实际编程中,我们常常会通过重写父类的方法完
成新的功能,这样写起来虽然简单,但整个继承体系的复用性会比较差。特别是运
行多态比较频繁的时候
- 通用的做法是:原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,
采用依赖,聚合,组合等关系代替.
开闭原则
- 基本介绍
-
开闭原则(Open Closed Principle)是编程中最基础、最重要的设计原则
-
一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。用抽象构建框架,用实现扩展细节。
-
当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
-
编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则
- 方式1(提取公共抽象方法) 的优缺点
-
优点是比较好理解,简单易操作。
-
缺点是违反了设计模式的ocp原则,即对扩展开放(提供方),对修改关闭(使用方)。
即当我们给类增加新功能的时候,尽量不修改代码,或者尽可能少修改代码.
- 比如我们这时要新增加一个图形种类 三角形,我们需要做如下修改,修改的地方较多
迪米特法则
- 基本介绍
-
一个对象应该对其他对象保持最少的了解
-
类与类关系越密切,耦合度越大
-
迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内
部。对外除了提供的public 方法,不对外泄露任何信息
-
迪米特法则还有个更简单的定义:只与直接的朋友通信
-
直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部。
合成复用原则
- 基本介绍
原则是尽量使用合成/聚合的方式,而不是使用继承