《设计模式学习总结 一》

第一章 简单工厂模式

1.好的设计模式：

可维护 ----只需要更改要改的代码
可复用----代码可以重复使用
可扩展----添加功能只需要另外加入代码就可以
灵活性----只需将代码移动就可以做到满足排列需求

2.面向对象的好处：通过封装、继承、多态把程序的耦合度降低。用设计模式使得程序更加灵活，容易修改，利于复用。

3.尽可能的方法避免重复代码，即让业务逻辑与界面逻辑分开，让它们之间的耦合度下降。

4.UML图：

一个矩形框表示一个类，+代表public、-代表private，#表示protected
第一层：类的名称，抽象类的名称是斜体
第二层：类的特性，通常是字段和属性
第三层：类的操作，通常是方法和行为

接口矩形表示法：顶端有《interface》，第一行接口名称，第二行接口方法。
接口棒棒糖表示法：圆圈旁为接口名称，接口方法在实现类中出现。

继承关系用空心三角形+实线表示。
实现接口用空心三角形+虚线表示。
关联关系用实线箭头来表示。
聚合关系表示一种弱的“拥有”关系,体现的是A对象可以包含B对象，但是B对象不是A对象的一部分。用空心菱形(A)+实线箭头(B)表示。
合成（组合）关系是一种抢的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。用实心的菱形（A）+实线箭头（B）表示。
依赖关系用虚线箭头表示。

简单工厂模式：工厂类会实例化出合适的对象。

第二章 策略模式

1.策略模式解析：策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法的完成都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法之间的耦合。

2.总结

策略模式简化了单元测试，每个算法都有自己的类，可以通过自己的接口单独测试。
修改其中一个算法，不会影响其他算法
当不同的行为堆砌到一个类中，难免有switch，if等分支，将这些行为封装在一个个独立的Strategy类中，可以在使用这些行为的类中消除条件语句。
策略模式几乎可以封装任何类型的规则，只要在分析过程中听到需要在不同的时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性
基本的策略模式，选择所用具体实现的职责由客户端承担，并转给策略模式的context对象。但与工厂模式结合后，选择的职责也由Context承担，大大减轻了客户端的职责。
策略模式的C++代码实现：https://blog.csdn.net/Rage_/article/details/84255703

第三章 单一职责原则

1.单一职责原则的定义是：

	不要存在多于一个导致类变更的原因。通俗的说，就是一个类只负责一项职责。

2.单一职责原则针对的问题

有一个类T负责两个不同的职责：职责P1和职责P2.当因为职责P1的需求发生改变而需要修改类T的时候，有可能会导致原本运行正常的职责P2功能发生故障。

3.单一职责原则的解决方案

遵循单一职责原则，分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1的时候，不会使职责P2发生风险。同理，当修改P2的时候，也不会使职责P1发生故障风险。

4.单一职责原则的认识

说到单一职责原则，很多人都会不屑一顾，因为它太简单了。稍有经验的程序员即使从来没有读过设计模式，从来没有听说过单一职责原则，在设计软件的时候也会自觉遵守这个重要原则，因为这是一个常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即使是经验丰富的程序员写出的程序也会有违背这一设计原则的代码存在。这是职责扩散导致的。所谓的职责扩散，指的就是因为某种原因，职责P1被分化为粒度更细的职责P1和P2。
比如说，类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，或许是需求变更了，又或许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1和P2。这时候，如果要使程序遵循单一职责原则，就需要将类T也分解为两个类T1和T2，分别去负责P1和P2两个职责。但是在程序已经写好的情况下这样做，十分浪费时间和精力。所以，简单地修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做会有悖于单一职责原则。
适当地违背单一职责原则有时候反而能提高开发效率，因此设计原则还是要按照实际需求来选择使用的。

5.单一职责原则的优点：

降低类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑肯定要比多项职责简单的多。
提高类的可读性，提高系统的可维护性。
降低变更引起的风险。变更是必然的，如果单一职责原则遵守得好，当修改一个功能的时候可以显著降低其他功能的影响。