设计模式简介

一、什么是设计模式

程序设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
程序设计模式这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。

二、遵循模式原则

设计原则七大原则

单一职责原则（Single Reponsibility Principle）是尽量让一个类负责一个接口（功能）。
开闭原则（Open/Close Principle）是指编写类的时候，要符合对类扩展开放，对类的修改关闭。
里氏替换原则（Liskov substitution Principle）是指我们的编写子类，可以在保证业务正确的情况下，替换掉父类。
接口隔离原则（InterfaceSegregation Principle）是指接口应该保持单一性，一个接口干一件事情。不要合并多个接口到一个接口。
依赖反转原则（Dependency InversionPrinciple）指高层模块不应该依赖底层模块，具体就是Controller使用Service的接口，而不应该直接使用Service具体类。
迪米特原则/最少知识原则（Least Knowledge Principle）是指使用类和被使用类之间有个中介，达到使用者尽可能少的知道被使用者的信息。也就是如果客户端要使用service，那么客户端直接使用service的中介就好了。

。

三、所有设计模式特点

创建型模式：描述的是根据需求怎样创建对象。
结构型模式：描述的是如何处理类或者对象之间的关系，通过某种布局组成一个比较完善的结构。然后方便客户端使用。
行为型模式：描述多个类或者对象如何协同处理单个对象无法完成的任务。（程序在运行时复杂的流程控制）。我们应该根据 自己的应用场景，选择合适的模式类型，再定位具体的设计模式。

类型	设计模式	描述
创建型	Factory 模式	被实例化的子类
	AbstactFactory 模式	针对一个类的唯一实例
	Singleton模式	单选按钮
	Builder模式	如何创建一个组合对象
	Prototype 模式	针对被实例化的类
结构型	Bridge模式	对象的实现
	Adapter 模式	针对对象的接口
	Decorator模式	针对对象的职责，不生成子类
	Composite 模式	模式 一个对象的结构和组成
	Flyweight模式	对象的存储开销
	Facade模式	对一个子系统的接口
	Proxy模式	如何访问一个对象；该对象的位置
行为型	Template 模式	对算法中的某些步骤
	Strategy模式	算法
	State模式	对象的状态
	Observer模式	对多个对象依赖于另外一个对象，而这些对象又如何保持一致
	Memento模式	对一个对象中哪些私有信息存放在该对象之外，以及在对什么时候进行存储
	Mediator 模式	对象间怎样交互、和谁交互
	Command模式	何时、怎样满足一个请求
	Visitor模式	某些可作用于一个（组）对象上的操作，但不修改这些对象的类
	Chain of Responsibility模式	满足

四、设计模式由来和介绍

在Christopher Alexander的另一部经典著作《建筑的永恒之道》中，他给出了关于模式的定义：

  每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，
  通过这种方式，我们可以无数次地重用那些已有的成功的解决方案，无须再重复相同的工作。
  这个定义可以简单地用一句话表示：

**

模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。
【A pattern is a successful orefficient solution to a recurring problem within a context】

**

1990年，软件工程界开始关注ChristopherAlexander等在这一住宅、公共建筑与城市规划领域的重大突破。最早将模式的思想引入软件工程方法学的是1991-1992年以“四人组(Gang of Four，简称GoF，分别是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”自称的四位著名软件工程学者，他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。

GoF将模式的概念引入软件工程领域，这标志着软件模式的诞生。
软件模式(SoftwarePatterns)是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。
软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件开发生命周期的每一个阶段都存在着一些被认同的模式。

设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素，其中关键要素是模式名称、问题、解决方案和效果。模式名称(Pattern Name)通过一两个词来描述模式的问题、解决方案和效果，以便更好地理解模式并方便开发人员之间的交流，绝大多数模式都是根据其功能或模式结构来命名的（GoF设计模式中没有一个模式用人名命名，）；

问题(Problem)描述了应该在何时使用模式，它包含了设计中存在的问题以及问题存在的原因；

解决方案(Solution)描述了一个设计模式的组成成分，以及这些组成成分之间的相互关系，各自的职责和协作方式，通常解决方案通过UML类图和核心代码来进行描述；

效果(Consequences)描述了模式的优缺点以及在使用模式时应权衡的问题。

五、设计模式作用

   (1) 掌握设计模式并不是件很难的事情，关键在于多思考，多实践，
   不要听到人家说懂几个设计模式就很“牛”，只要用心学习，
   设计模式也就那么回事，你也可以很“牛”的，一定要有信心。

  (2) 在学习每一个设计模式时至少应该掌握如下几点：
  这个设计模式的意图是什么，它要解决一个什么问题，什么时候可以使用它；
  它是如何解决的，掌握它的结构图，记住它的关键代码；能够想到至少两个它的应用实例，
  一个生活中的，一个软件中的；这个模式的优缺点是什么，在使用时要注意什么。
  当你能够回答上述所有问题时，恭喜你，你了解一个设计模式了，至于掌握它，
  那就在开发中去使用吧，用多了你自然就掌握了。

  (3) “如果想体验一下运用模式的感觉，那么最好的方法就是运用它们”。
  正如在本章最开始所说的，设计模式是“内功心法”，
  它还是要与“实战招式”相结合才能够相得益彰。
  学习设计模式的目的在于应用，如果不懂如何使用一个设计模式，
  而只是学过，能够说出它的用途，绘制它的结构，充其量也只能说你了解这个模式，
  严格一点说：不会在开发中灵活运用一个模式基本上等于没学。所以一定要做到：少说多做。

  (4) 千万不要滥用模式，不要试图在一个系统中用上所有的模式，也许有这样的系统，但至少目前我没有碰到过。每个模式都有自己的适用场景，不能为了使用模式而使用模式？【怎么理解，大家自己思考，】，滥用模式不如不用模式，因为滥用的结果得不到“艺术品”一样的软件，很有可能是一堆垃圾代码。

  (5) 如果将设计模式比喻成“三十六计”，那么每一个模式都是一种计策，
  它为解决某一类问题而诞生，不管这个设计模式的难度如何，使用频率高不高，
  我建议大家都应该好好学学，多学一个模式也就意味着你多了“一计”，
  说不定什么时候一不小心就用上了，。因此，模式学习之路上要不怕困难，勇于挑战，
  有的模式虽然难一点，但反复琢磨，反复研读，应该还是能够征服的。

  (6) 设计模式的“上乘”境界：“手中无模式，心中有模式”。
  模式使用的最高境界是你已经不知道具体某个设计模式的定义和结构了，
  但你会灵活自如地选择一种设计方案【其实就是某个设计模式】来解决某个问题，
  设计模式已经成为你开发技能的一部分，能够手到擒来，“内功”与“招式”已浑然一体，
  要达到这个境界并不是看完某本书或者开发一两个项目就能够实现的，
  它需要不断沉淀与积累，所以，对模式的学习不要急于求成。

  (7) 最后一点来自GoF已故成员、我个人最尊敬和崇拜的软件工程大师之一John Vlissides的著作        《设计模式沉思录》
  (Pattern Hatching Design Patterns Applied)：模式从不保证任何东西，
  它不能保证你一定能够做出可复用的软件， 提高你的生产率，更不能保证世界和平，。
  模式并不能替代人来完成软件系统的创造 
  它们只不过会给那些缺乏经验但却具备才能和创造力的人带来希望。