前言
我写这篇博文，是对我研一这一学期到现在，学习设计模式的总结。我自己使用的是程杰写的《大话设计模式》这本书，我会跟据这本书，对自己这么多天学习到的知识做一个总结。
目前，第一篇先总结前三章。涉及到的只是有：第一章讲述的UML类图和简单工厂模式，第二章的策略模式和第三章的单一职责原则。首先，先来看第一章地1.11节的UML类图。
UML类图
类图
类图分为三层，第一层是类名；第二层是类特性，即类成员；第三层则是列操作，即类的成员函数。其中，+表示public，-表示private，#表示protected。
接口图
接口图分为两层，第一层以<<interface>>打头，接接口名，用来指明这是一个接口。第二层则是接口方法。
连接线
- 类间的继承关系用带有空心三角形的实线表示。
- 实现具体的接口用带有空心三角的虚线表示。
- 关联关系用实线箭头表示。所谓关联关系，可以是友元类的关系。
- 聚合关系使用空心菱形和实线箭头组合来表示。聚合关系表示一种弱拥有关系，例如A包含B，但B对象不一定是A对象的一部分。用文氏图来表示，那A和B是相交的关系。
- 合成关系用实心菱形和实线箭头组合来表示。合成关系是一种强拥有关系，是严格的整体和部分的关系且部分与整体的生命周期是一致的。用文氏图来表示，A和B是包含关系。
- 依赖关系用虚线箭头表示。
书中12页示例图如下所示：
简单工厂模式
1.4节指出，面向对象和设计模式是因为解决代码不容易维护，不容易扩展，不容易复用和灵活性差的问题的。
1.6节指出通过封装、继承和多态把程序耦合度降低，使用设计模式使得使得程序更加机灵活，易于修改和复用。
简单工厂模式考虑用一个单独的类来做这个创造实例的过程。这个类就像是工厂批量生产产品一样，得名简单工厂模式。在1.10节里，OperationFactory类（操作符工厂类）就是为计算器功能生产各种运算功能的工厂类。
书上的参考代码是这样的，以加法为例，将numberA与numberB相加：
Operation oper;
oper = OperationFActory.createOperate('+');
oper.NumberA = 1;
oper.NumberB = 2;
double result = oper.GetResult();策略模式
第二章，用一个商场促销软件引入，说明简单工厂迷失虽然也可以使用，但是简单工厂模式只是针对对象创建问题而提出的。促销软件包括了所有类似的收费模式，而每个收费模式类似第一章不同的操作符。但有一点不同的是，打折的计费方式是多种多样的，而每次采用新的收费模式时都需要改动工厂类，就违反了封装的要求，所有才需要使用策略模式。
策略模式定义了家族算法，分别封装起来，让他们之间可以互相替换。这个模式让算法变化不会影响使用算法的客户。
策略模式结构图如下：
总之，策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是类似的工作，算法实现不同，程序员调用这些算法时的调用方式是一样的，这样可以减少各种算法类与使用算法的类之间的耦合。且在测试的时候也更加方便测试人员的调试，其实本萌新最早些项目，最近常使用的也是策略模式，将各个功能单独写成函数，一一测试，来判断哪里出错了。要是连在一起写debug时候会把自己累死。
可以这么认为工厂模式封装了生产各种对象的类成员函数，而策划略模式是封装项目里的逻辑功能函数。
单一职责原则
单一职责原则：就一个类而言应该仅有一个引起它变化的原因。简单来说，一个类就因该只负责单一的责任，例如工厂类A只负责产生类似的对象，而工厂类B负责产生另一种类似的对象，这一类对象不同于工厂A产生的对象。
文中3.5节举了俄罗斯方块的例子，说明了界面和游戏逻辑函数不该写在一个类里的原因：如果一个类承担的职责过多，就等同于这些职责会耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合导致脆弱的设计，当发生变化时，会引发大量的修改。
这一章节只有4页没有实例代码，主要是称述了单一职责原则的含义。
结语
目前我看到了17章，我会按时复习总结，并更新相应的复习记录，希望自己在毕业的时候能拿到满意的薪资！！！