GoF设计模式 - 概述

掌握编程语言仅仅意味着掌握了如何给计算机“下命令”，而到底要计算机如何去做，怎么指挥，则是另一个问题——如何编程。设计模式是一套程序员的“武功套路”，它教我们如何去编程。虽然不遵守这个套路也是可以编程的，但是为了做到让整支程序员军团以整齐一致的步伐协调工作，设计模式的存在还是很有必要的。它定义了一系列的“武功套路”以及对应的招式的名称，相当于制定好了行业内的一套规范以及术语，方便程序员军团成员之间相互沟通。

GoF的23种设计模式

GoF是指Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四个人，他们四个人被称为Gang of Four，缩写GoF。这四个人曾经合著过一本书《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大名鼎鼎的《设计模式》一书。此书流传很广，已经是程序员界的圣经之一了。这本书中介绍了23种设计模式，虽然设计模式其实不止这23种，但是由于这23种太常用了，所以我们一般说到设计模式，就是指GoF的23种设计模式。本文后续说的设计模式也将默认设计模式为GoF的23种设计模式。另外，我的第一语言是Java，Java也几乎是OO界默认的语言，所以后续文章将使用Java。文章中出现的示例代码将同步更新到java-design-pattern-samples项目。

六大原则

所有的设计模式都遵循以下六个基本的设计原则。

• 单一职责原则: The Single Responsibility Principle(SRP)
• 开放封闭原则: The Open Closed Principle(OCP)
• 里氏替换原则: The Liskov Substitution Principle(LSP)
• 迪米特法则: The law of Demeter(LD)
• 接口隔离原则: The Interface Segregation Principle(ISP)
• 依赖倒置原则: The Dependency Inversion Principle(DIP)

六大设计原则取其英文首字母简称为SOLID原则。( ′◔ ‸◔`) 咦！不是六大原则吗！为啥缩写只有五个字母！
这个。。。我还真不知道！或许是把里氏替换原则和迪米特法则的两个L合并成一个更好看吧！如果有知道原因的朋友可以在博客中留言告诉我！

单一职责原则

一个类只做一件事情，不要去做与这个类的主要职责无关的事情。

开放封闭原则

对扩展开放，对修改关闭。简单的说就是类或者接口定义好之后不可进行破坏性的更新！如果没有bug，或者修改类、接口不是为了改进内部实现机制就不应该去修改这个类。开闭原则的目的是为了保持类或者接口后续版本能够向后兼容，这是一个最根本的原则。开闭原则是六大原则中最重要的一个，算是一个总原则吧！

虽然理论上我们应该严格遵守开闭原则，不过现实往往没有那么理想化。任何一个软件在设计的时候都无法预料到后续发展中的所有需求，所以现实情况是修改几乎不可避免。比如Java8中为了stream加了个毁三观的default方法，这就是一个活生生的例子。我们只能在进行设计的时候尽可能的去遵守这些原则！

和我一起在心里默念几次程序员圣经中的上帝指示：对扩展开放，对修改关闭！对扩展开放，对修改关闭！对扩展开放，对修改关闭！

里氏替换原则

所有父类可以出现的地方，都可以透明的用子类替换。也就是说，子类可以扩展父类，但是不可以修改父类的原有功能。子类 is a 实现 of 父类。

迪米特法则

迪米特法则又叫最少知识原则Least Knowledge Principle(LKP)，意思是一个类应该对他自己所依赖的类知道的越少越好！我们的目标是：没有蛀牙！:-) 开玩笑的！应该是：高内聚，低耦合。

接口隔离原则

使用多个小的更具体的接口比使用一个臃肿的接口要更好！也就是说，优雅的程序需要精心呵护，所以为了保护她，我们应该鄙视太粗的接口，应该喜欢细一点的接口。:-) 我知道你们在想什么，不过本司机指的不是你想的那个意思！
细一点的接口有利于重构！:-) 原则就是被用来违反的！对修改关闭？怎么可能！谁写的代码可以一步到位永久不修改的吗！
另外细一点的接口也有利于客户端遵守最少知识原则。

依赖倒置原则

不要依赖具体实现，要依赖抽象！也就是面向“接口”编程而不是面向实现类编程！这样做可以解除客户端与实现类的耦合。

六大设计原则总结

开闭原则要求我们写好的类不要去修改，如果需要增加功能，那么扩展它。单一职责原则要求我们一个类只做一件事情。里氏替换原则要求我们子类必须兼容父类。迪米特法则要求我们尽可能少的依赖其他的类。接口隔离原则要求我们定义接口的时候尽可能简单一些。依赖倒置原则要求我们不能去依赖实现类！

设计模式分类

GoF23种设计模式一般分为三大类。

创建型模式

• 工厂方法模式(Factory Method)
• 抽象工厂模式(Abstract Factory)
• 单例模式(Singleton)
• 创建者模式(Builder)
• 原型模式(Prototype)

除此之外，简单工厂模式(Simple Factory)应该也算。不过为了凑整23个模式，就不放到列表里了。

结构型模式

• 适配器模式(Adapter)
• 外观模式(Facade)
• 享元模式(Flyweight)
• 组合模式(Composite)
• 装饰器模式(Decorator)
• 代理模式(Proxy)
• 桥接模式(Bridge)

行为型模式

• 策略模式(Strategy)
• 状态模式(State)
• 职责链模式(Chain of Responsibility)
• 观察者模式(Observer)
• 模板方法模式(Template Method)
• 命令模式(Command)
• 备忘录模式(Memento)
• 迭代器模式(Iterator)
• 调停者模式(Mediator)
• 解释器模式(Interpreter)
• 访问者模式(Visitor)

上述设计模式有链接的表示已经写好了介绍的文章，可以直接戳链接去看对应的文章。