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）

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

设计模式类型

五个建立型设计模式

工厂方法模式（含简单工厂，Factory Method Pattern）

抽象工厂模式（Abstract Factory Pattern）

单利模式（Singleton Pattern）

原型模式（Prototype Pattern）

建造者模式（Builder Pattern）

七个结构型设计模式

适配器模式（Adapter Pattern）

桥接模式（Bridge Pattern）

组合模式（Composite Pattern）

装饰模式（Decorator Pattern）

外观模式（Facade Pattern）

享元模式（Flyweight Pattern）

代理模式（Proxy Pattern）

十一个行为模式

责任链模式（Chain of Responsibility Pattern）

命令模式（Command Pattern）

解释器模式（Interpreter Pattern）

迭代器模式（Iterator Pattern）

中介者模式（Mediator Pattern）

备忘录模式（Memento Pattern）

观察者模式（Observer Pattern）

状态模式（State Pattern）

策略模式（Strategy Pattern）

模板方法模式（Template Method Pattern）

访问者模式（Visitor Pattern）

 

 

 

 

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