Java设计模式学习记录-GoF设计模式概述

前言

最近要开始学习设计模式了，以前是偶尔会看看设计模式的书或是在网上翻到了某种设计模式，就顺便看看，也没有仔细的学习过。前段时间看完了JVM的知识，然后就想着JVM那么费劲的东西都看完了，说明自己学习耐力还是有的，所以就打算仔细的研究研究设计模式，然后也将设计模式的学习过程记录下来。

GoF的设计模式

Gang of Four，简称GoF，分别是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides，这四位软件工程学者在1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。软件开发发展到现在设计模式已经不至23种了，但是GoF的23种设计模式还是软件开发种很常用的，所以一般讲解设计模式都是指的GoF的23种设计模式，我以后要学习的设计模式也是这23种设计模式。并且举例子也都是以Java语言为主的。

面向对象设计原则

单一职责原则（Simple Responsibility Principle,SRP）

一个类应该只有一个功能领域的职责，对外只提供一种功能，而引起类变化的原因应该只有一个。单一原则要达到的目的就是高内聚，低耦合。例如有一个用户类，这个用户类中包含用户的属性和用户的行为，这就造成了业务对象和业务逻辑被放在了一起，使得这个类有两种职责，违背了单一职责原则。应该将属性和行为分开，分别设立单独的接口（属性接口，行为接口）和实现类（属性实现类，行为实现类），这样就可以将业务对象和业务逻辑单独分开了。

开闭原则（Open Close Principle,OPC）

一个对象对扩展开发，对修改关闭。通俗的理解是：对类的改动是通过增加代码进行的，而不是改动现有的代码。例如有一个用户行为接口，这个接口已经有两个实现类了，这时有一个需求是要给这个用户新增一个行为，这个时候需要更改用户行为接口，但是这样就违背了开闭原则。真正符号开闭原则的做法是，再写一个新的接口（或抽象类）继承自用户行为接口，然后所有的用户行为实现类都实现这个新的接口（或继承自新的抽象类）。

里氏替换原则（Liskov Substitution Principle,LSP）

在任何父类出现的地方都可以用它的子类来替代。也就是说同一个继承体系中的对象应该有共同的行为特征。在里氏替换原则中，所有引用基类的地方必须能够透明地使用其子类对象。只要有父类出现的地方，子类就能够出现，而且替换为子类不会产生任何错误或异常。反过来，子类出现的地方，替换为父类就可能出现问题了。

里氏替换原则为良好的继承定义了一个规范，具体有4个：

子类必须完成实现父类的方法。
子类可以有自己的特性。
覆盖或者实现父类的方法时输入参数可以被放大。
覆盖或者实现父类的方法时输出结果可以被缩小。

依赖注入原则（Dependence Inversion Principle,DIP）

编程时要依赖于抽象，不要依赖于具体的实现。在应用程序中，所有的类如果使用或依赖于其他的类，则都应该依赖于这些其他类的抽象类（或接口），而不是依赖于这些其他类的具体实现类。

依赖注入原则需要注意的是：高层次模块不应该依赖低层次模块，即使用接口或抽象类进行变量的声明、参数类型的声明、方法返回类型的声明、数据类型状态等，而不要用具体实现类来做这些。

依赖注入的实现方式有三种：

通过构造函数传递依赖对象。
通过setter方法传递依赖对象。
接口声明实现依赖对象。

接口分离原则（Interface Segregation Priciple,ISP）

不应该强迫客户程序依赖它们不需要使用的方法。意思就是说，一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所以的操作都封装到一个接口中。

在使用接口分离原则时需要注意几点：

接口尽量小：这主要是为了保证一个接口只服务于一个子模块或一类子模块。
接口高内聚：接口高内聚是对内高度依赖，对外尽可能隔离。即一个接口内部声明的方法相互之间都与某一个子模块相关，且使这个模块必需的。
接口设计是有限度的：如果完全遵循接口分离原则，接口粒度会越来越小，接口数量剧增，会导致系统复杂度大大增加，所以在设计接口时不应该一味的去分离接口。

迪米特原则（最少知识原则-LeastKonwledge Priciple,LKP）

一个软件实体应该尽可能少的与其他软件实体发生相互作用。就是说各个对象或各个类之间应该尽可能降低耦合，提高系统的可维护性。在模块之间应该通过接口来通信，而不理会模块的内部工作原理，它可以使各个模块耦合度降到最低，促进软件的复用。

设计模式类型

访问者模式（Visitor Pattern）

这些模式的学习文章写好后，会把链接赋到名称后面的。这一篇文章也算是作为我设计模式学习的开篇吧，本来想直接写简单工厂模式的，但是后来发现要学设计模式需先把设计模式的来源以及遵循的原则搞清楚，所以就有了这么一个开篇文章，以后添加上了链接也可以作为我学习设计模式的文章的目录。