Java 设计模式简介

设计模式简介

设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题,每种模式在现实中都有相应的原理来与之对应,每种模式都描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是设计模式能被广泛应用的原因。

模式:在某些场景下,针对某类问题的某种通用的解决方案。
场景:项目所在的环境
问题:约束条件,项目目标等
解决方案:通用、可复用的设计,解决约束达到目标。

设计模式的由来

在 1994 年,由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software(中文译名:设计模式-可复用的面向对象软件元素)的书,该书首次提到了软件开发中设计模式的概念。

四位作者合称 GOF(四人帮,全拼 Gang of Four)。他们所提出的设计模式主要是基于以下的面向对象设计原则:

  • 对接口编程而不是对实现编程。
  • 优先使用对象组合而不是继承。

设计模式的使用

设计模式在软件开发中的两个主要用途:

  • 开发人员的共同平台:设计模式提供了一个标准的术语系统,且具体到特定的情景。例如,单例设计模式意味着使用单个对象,这样所有熟悉单例设计模式的开发人员都能使用单个对象,并且可以通过这种方式告诉对方,程序使用的是单例模式。
  • 最佳的实践:设计模式已经经历了很长一段时间的发展,它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。

设计模式的分类

设计模式的三大分类

根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software(中文译名:设计模式-可复用的面向对象软件元素)中所提到的,总共有 23 种设计模式。这些模式可以分为三大类:

  • 创建型模式(Creational Patterns):对象实例化的模式,创建型模式用于解耦对象的实例化过程。
  • 结构型模式(Structural Patterns):把类或对象结合在一起形成一个更大的结构。
  • 行为型模式(Behavioral Patterns):类和对象如何交互,及划分责任和算法。

如下图所示:
设计模式的类型

各分类中模式的关键点

下面简单介绍一下各分类中模式的关键点:

  • 创建型模式(Creational Patterns)

    • 单例模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
    • 工厂方法模式:定义一个创建对象的接口,让其子类自己决定实例化哪一个工厂类,工厂模式使其创建过程延迟到子类进行。
    • 抽象工厂模式:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
    • 建造者模式:将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。
    • 原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
  • 结构型模式(Structural Patterns)

    • 适配器模式:将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
    • 桥接模式:将抽象部分与实现部分分离,使它们都可以独立的变化。
    • 组合模式:将对象组合成树形结构以表示”部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。
    • 装饰模式:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰器模式相比生成子类更为灵活。
    • 外观模式:对外提供一个统一的方法,来访问子系统中的一群接口。
    • 亨元模式:通过共享技术来有效的支持大量细粒度的对象。
    • 代理模式:为其他对象提供一种代理以控制对这个对象的访问。
  • 行为型模式(Behavioral Patterns)

    • 模板模式:定义一个算法结构,而将一些步骤延迟到子类实现。
    • 策略模式:定义一系列算法,把他们封装起来,并且使它们可以相互替换。
    • 状态模式:允许对象在其内部状态发生改变时改变它的行为,对象看起来好像修改了它的类。
    • 命令模式:将命令请求封装成一个对象,从而使得可以用不同的请求对客户进行参数化。
    • 访问者模式:在不改变数据结构的前提下,增加作用于一组对象元素的新功能。
    • 观察者模式:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
    • 解释器模式:给定一个语言,定义它的文法表示,并定义一个解释器,这个解释器使用该标识来解释语言中的句子。
    • 备忘录模式:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。
    • 中介者模式:用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
    • 责任链模式:将请求的发送者和接收者解耦,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。
    • 迭代器模式:提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。

下面用一个图片来整体描述一下设计模式之间的关系:
设计模式的类型

设计模式的七大原则

开闭原则(Open Close Principle,OCP)

开闭原则的意思是:对扩展开放,对修改关闭。也就是说,在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。

单一职责原则(Single Responsibility Principle,SRP)

一个类,只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线。
一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。
简单通俗的来说:一个类只负责一项职责。

里氏替换原则(Liskov Substitution Principle,LSP)

里氏代换原则是面向对象设计的基本原则之一。里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。
LSP 是继承复用的基石,只有当派生类可以替换掉基类,且软件单位的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。

接口隔离原则(Interface Segregation Principle,ISP)

接口隔离原则是指:使用多个隔离的接口,比使用单个接口要好。它还有另外一个意思是:降低类之间的耦合度。由此可见,其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想,它强调降低依赖,降低耦合。

依赖倒置原则(Dependence Inversion Principle,DIP)

这个原则是开闭原则的基础,具体内容:针对接口编程,依赖于抽象而不依赖于具体。他主要有两个方面的内容:

  • 高层模块不应该依赖低层模块,他们都应该依赖于抽象;
  • 抽象不应该依赖于具体实现,具体实现应该依赖于抽象。

迪米特法则(Demeter Principle,DP)

迪米特法则,又称最少知道原则。为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。

合成复用原则(Composite Reuse Principle,CRP)

合成复用原则是指:要尽量的使用合成和聚合的方式,而不是继承关系达到复用的目的。该原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分:新的对象通过向这些对象的委派达到复用已有功能的目的。

致谢

Java Design Pattern


评论
 上一篇
Java 设计模式之单例模式 Java 设计模式之单例模式
模式动机对于系统中的某些类来说,只有一个实例很重要,例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;一个系统只能有一个窗口管理器或文件系统;一个系统只能有一个计时工具或 ID(序号)生成器。 如何保证一个类只有一个实例并
2018-09-07
下一篇 
看懂 UML 类图和时序图 看懂 UML 类图和时序图
这里不会将 UML 的各种元素都提到,我只想讲讲类图中各个类之间的关系;能看懂类图中各个类之间的线条、箭头代表什么意思后,也就足够应对 日常的工作和交流;同时,我们应该能将类图所表达的含义和最终的代码对应起来。 UML类关系图示例请看以下这
2018-09-03
  目录