Bug辉的博客 不忘初心,方得始终!

GoF设计模式 - 概述

2017-06-10
Bug辉 [原创文章]

本文为博主原创文章,请遵守文章最后的版权申明。


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

最近一段时间做了两件事情,首先是重构了一下自己的个人网站的后台,其次是写了一个wifi考勤程序,所以有一段时间没有写文章了。从今天开始,我将抽空整理一下设计模式相关的知识。本文将是我的《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种设计模式一般分为三大类。

创建型模式

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

结构型模式

行为型模式

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

后续计划

下一篇文章开始将逐个介绍23种设计模式,敬请期待!


版权声明

知识共享许可协议
若无特殊说明则文章内容均为博主原创内容,包括但不限于代码、文字、图片。
《GoF设计模式 - 概述》 Bug辉 采用 知识共享 署名-非商业性使用-禁止演绎 4.0 国际 许可协议 进行许可。
转载文章时文章署名请注明原作者为Bug辉(Elvin Zeng、zenghui、曾辉也行)并带上原文链接:https://www.bughui.com/2017/06/10/gof-design-pattern-overview/

鉴于目前国人版权意识比较薄弱,所以路过的同学可能并不了解CC协议。在此特地介绍一下!上述协议大概的意思是(这里只是简单解释,并不替代协议,以上述协议为准):
  • 权利:遵守协议的情况下你可以在任何媒介以任何形式复制、发行本作品。
  • 约束:使用本作品得保留署名(作者+原文链接),不得声称或暗示文章是你创作的。
  • 约束:你不可以将本作品用于商业目的。
  • 约束:如果你再混合、转换、或者基于本作品创作,你不可以发布修改后的作品。
  • 在得到作者允许的情况下你可以不用受上述条款约束。
不论本作品是否对你有益,不论你是否认同本作品的观点,本作品都是作者的劳动产物。尊重别人的劳动别人才会尊重你的劳动是吧!


类似文章

评论

打赏时请在备注信息中填上你的称呼!好让我把你的名字加入致谢名单