【博览网】设计模式——第一周课程笔记

本周课程先大致介绍了设计模式的概念以及产生原因，然后详细讲解了设计模式的几大原则，接着按照顺序介绍了模板方法、策略模式、观察者模式、装饰模式、桥模式这几个设计模式。

课程目标：
• 理解松耦合设计思想
• 掌握面向对象设计原则
• 掌握重构技法改善设计
• 掌握GOF核心设计模式

参考书籍：
《设计模式：可复用面向对象软件的基础》

一、程序开发的两种思维
1.底层思维
• 语言构造
• 编译转换
• 内存模型
• 运行时机制
2.抽象思维
• 面向对象
• 组件封装
• 设计模式
• 架构模式

二、面向对象设计原则
1.依赖倒置原则
该原则主要描述两件事情，一是高层模块不应该依赖于底层模块，二者都应该依赖于抽象；二是抽象不应当依赖于实现细节，实现细节应该依赖于抽象。这两条内容的核心思想是将变化的东西依赖于稳定的东西，实现将变化隔离的效果，这是设计模式的核心思想。这样，当需要进行变化时，便可以通过扩展对应的子类，通过运行时多态来实现，达到代码复用的效果。
2.开放封闭原则
即代码应该是对扩展开放，对更改封闭；类模块应该是可扩展的，但是不可修改。这样可以保证已完成代码在后续开发过程中的复用性，防止在修改或者扩充功能时引入新的bug。
3.单一职责原则
一个类应该仅有一个引起它变化的原因，即变化的方向应该隐含着类的责任。
4.Liskov替换原则
子类必须能够替换它的父类，即满足is-a的关系。
5.接口隔离原则
不应该强迫客户程序依赖它们不用的接口，即设计类时应当将内部使用的函数使用protected或者private的形式影藏起来，使得接口小且完备。这样在修改程序时便可以避免对客户程序进行修改。
6.优先使用组合对象，而不是类继承
在面向对象程序设计中，类继承是一种“白箱复用”，而对象组合是一种“黑箱复用”。使用类继承往往子类与父类间耦合度较高，这容易破坏类的封装性。
7.封装变化层
使用封装来创建对象之间的分界层，让设计者可以再分界层一次进行修改而不会对另一侧产生不良影响。
8.针对接口编程，而不是针对实现编程
即在编程时，变量应当尽量声明为抽象接口或者抽象类，客户端只需要知道类的接口，而无需知道其底层实现便可以完成功能。这样在实现产生变化时可以非常方便的修改，而不影响客户端程序。

三、模板方法
1.应用情景
在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个自步骤却有很多改变需求，或者由于固有的原因而无法和任务的整体结构同时实现。在这个情境下，稳定的是该任务的执行框架，变化的是每个子任务的具体实现。
2.解决方案
在父类中将任务的执行框架先实现，并将其中易便的子步骤设置为protected虚函数，在子类进行发生变化时重载该虚函数。这种设计模式极大的降低了客户端程序的使用该模块的负担，并且提供了一种反向调用结构，是非常常见的设计模式。
其结构如下图所示：

四、策略模式
1.应用情景
在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使得对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。
2.解决方案
将多个算法从代码中提取出来，封装成一个个的策略类，并提供一个统一的接口作为父类。在需要使用多种算法的对象中定义一个该算法的父类指针，根据传进去的子类实现运行时确定计算方法。这样便可以在不更改对象源代码的情况下非常轻松的扩展策略算法。如果算法本身不涉及数据存储，算法类也可以使用单例模式设置，降低内存消耗。
其结构如下图所示：

五、观察者模式
1.应用情景
在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
2.解决方案
在软件中为定义一个发出通知的接口，对于需要接受通知的类便可以继承该接口并实现它。在发出通知的类中放置一个接口数组，在客户端程序中将所有需要接受通知的对象都放置进该数组中。这样，便可以实现通过客户程序灵活的选择和分配消息传送渠道，实现发出通知代码的复用。
其结构如下图所示：

六、装饰模式
1.应用情景
在某些情况下我们可能会“过度的使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多的子类膨胀。即我们需要找到一种方式，实现功能可通过非继承方式扩展，但是接口不发生变化的类。
2.解决方案
先定义一个抽象基本类型，为该基本类型定义两种子类，一种是不含有基类指针的子类，实现基本功能；另一种是含有基类指针的子类，实现基于基本功能之上的扩展功能。在某些情况下，也会为后一种类型子类抽象出一个基类作为装饰基类。这个设计模式实现了在接口上为is-a关系，在实现上为has-a关系的设计，解决了主题类在多个方向上扩展功能的问题。
其结构如下图所示：

七、桥模式
1.应用情景
由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个维度的变化。这是违反单一职责原则的。
2.解决方法
将基类的接口按照变化维度拆分，再将这些拆分后的接口组合起来，以适应类在不同情况下的变化。
其结构如下图所示：