学习笔记：什么是设计模式？

模式

模式（patterns）这个词，来自Christopher Alexander的 The Timless way of Building。
“质 量是客观的么？”从这个问题出发，Alexander开始思考，优秀的设计和糟糕的设计之间，到底存在怎样的差别？或者说，优秀的设计包含了什么？糟糕的 设计又包含了什么？在进行了许多观察和研究之后，Alexander发现，优秀的设计结构，尽管千差万别，但具有某种共性（good construts had things in common with each other）。Alex明白，结构与问题的解决方案是不能割裂的，于是他把自己研究的重点集中到能解决相似问题的结构的共性上来——这些高质量的设计的共 通，就是“模式”。
于是，Alex把模式定义为：“解决场合中某个问题的方案”（a solution to a problem in a context），每一种模式都描述了环境中重复出现的问题，以及解决方案的核心，有了模式，我们就能以不变应万变，而不需要重复劳动。
在Alex那里，模式有以下四个要素：
1.名称（name of the pattern）；
2.目的及问题（purpose of the pattern, the problem it solves）；
3.实现方式（how to accomplish）；
4.需要考虑的限制和因素（constraints and forces we have to consider in order to accomplish it）；

软件的模式

上世纪90年代，一些聪明的开发人员偶然接触了Alexander关于模式的著作，他们开始思考，软件开发中是否也存在模式——重复出现的问题是否也能用同样的方式解决？一旦确立了模个模式，能否在新的设计中应用这个模式呢？答案都是肯定的。
于是，就有了著名的“四人帮”（the gang of four），也有了那本著名的 设计模式 ，根据这本书的定义，软件设计模式有以下几个要素：
1.名称（Name），模式的标识
2.目的（intent），模式的目的
3.问题（problem），模式要解决的问题
4.解决方案（solution），模式在具体场合中解决问题的方式
5.参与者及合作者（participants and Collaborators），模式中包含的实体
6.影响（consquence），应用此模式对既有因素(present forces)的影响
7.实现（implemention），模式的实现方式，仅仅是关于模式的说明，而不是模式本身
8.四人帮的评价（GoF reference），从四人帮那里获得关于此模式的更多信息

同时，四人帮还给出了几条通用的建议：
1.根据接口进行设计（design to interfaces）
2.尽量用复合（favor composition over inheritance）
3.找出变数加以封装（find what varies and encapsulate it）

模式的价值

模式的价值主要体现在下面三个方面：
1.解决方案的重用——利用已有的模式开发，可以借鉴他人的经验，准备周全（avoid gotchas），减少开发成本和风险；
2.建立通用的术语——在项目的分析和设计阶段，模式提供了约定俗成的词汇和视角，有利于team内部的沟通
3.解放视角——无论是对问题，还是对设计，设计模式都提供了高层次的视角，开发人员不必从一开始就埋头于具体细节之中。

一个例子

要做一个抽屉，木匠A和木匠B的思路分别是：
木匠A：我们怎样来做这个抽屉？
木匠B：首先，我们必须在木头上凿一个孔，先垂直向下凿，再从旁边以四十五度角向下打通，再垂直向下，再从旁边……

不要笑，很多时候程序员的思维就类似于木匠B——这里，我用一个while循环达到某某目的……然后我开始用if判断条件……到这里再用swich来处理……
而木匠A关心的问题是：是要做一个A型的抽屉呢，还是做一个B型的。A型抽屉实现简单，承载重量少，看起来很一般；B型相对要复杂一些，但能够耐高温潮湿，不需要粘接，如果做得好的话，非常美观。
于是，木匠A关注的重点就在于，到底是要做A型的抽屉还是B型呢？
一旦确定了这一点，剩下的只是按照既有的方式加以实现。任何人都会看出，木匠A的思维（也就是模式的思维）远远比木匠B的高明。
————————————————————————————————————————————

        Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。
        尽管Alexander所指的是城市和建筑模式，但他的思想也同样适用于面向对象设计模式，只是在面向对象的解决方案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。

        软件中的设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。

        面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

        设计模式与面向对象
        1、面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式几个方面”。
        2、面向对象设计模式是“好的面向对象设计”，因为它可以满足“应对变化，提高复用”。
        3、面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达。
        4、面向对象设计模式不像算法技巧，可以直接照搬照用，它是建立在对“面向对象”纯熟、深入的理解的基础上的经验性认识。掌握面向对象设计模式的前提是首先掌握“面向对象”！

        从编程语言直观了解面向对象
        各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支持，即：“封装、继承、多态”
        ●    封装：隐藏内部实现
        ●    继承：利用现有代码
        ●    多态：改写对象行为

        但OOPL并非面向对象的全部
        通过面向对象编程语言（OOPL）认识到的面向对象，并不是面向对象的全部，甚至只是浅陋的面向对象。
        OOPL没有回答面向对象的根本性问题——我们为什么要使用面向对象？我们应该怎样使用三大机制来实现“好的面向对象”？我们应该遵循什么样的面向对象原则？

        对象是什么？
        —    从概念层面讲：对象是某种拥有责任的抽象。
        —    从规格层面讲：对象是一系列可以被其他对象使用的公共接口。
        —    从语言实现层面来看：对象封装了代码和数据。

        从设计原则到设计模式        
        ·    针对接口（抽象部分）编程，而不是针对实现（具体部分）编程
                —    客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。
        ·    优先使用对象组合，而不是类继承
                —    类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程序上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
        ·    封装变化点
                —    使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对别一侧产生不良的影响，从而实现层次间的松耦合。
        ·    使用重构得到模式
                —    设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

        几条更具体的设计原则
        ·     单一职责原则（SRP）：一个类应该仅有一个引起它变化的原因。
        ·     开放封闭原则（OCP）：类模块，对扩展开放，对更改封闭。
        ·     Liskov替换原则（LSP）：子类必须能够替换它们的基类。
        ·     依赖倒置原则（DIP）：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
                                                            抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
        ·     接口隔离原则（ISP）：不应该强迫客户程序依赖于它们不用的方法。