大话设计模式笔记 - 简单工厂模式
总的来说，简单工厂模式就是对封装，继承，多态的基本实现。是面向对象的基本思路。
我在最开始写程序的时候，业务逻辑和界面一股脑的堆在一起。根本没有任何设计模式。
每次业务修改的时候，不是改出新的bug，就是对已有程序做大手术。加了很多班，走了很多弯路。
这个章节就分析了为什么会造成这种情况的原因。
1. 面向对象编程
我们在遇到问题的时候，直觉地会用计算机能够理解的逻辑来表述我们的求解过程。
比如说，我要处理一个加减法，一共要分几步？
1.输入第一个数
2.输入运算逻辑
3.输入第二个数
4.等待输出结果
这么做并没有错，但这样却只能满足当下的需求，程序不易维护、扩展和复用。
如果有新的运算逻辑加入？我们要怎么修改程序？
原来所有的算法逻辑都在一个方法中，我们是再加一个在其中吗？
这么写的话很容易就会造成bug和动大手术，这就是上面总加班的主要原因。
我们应该使用面向对象的思维来分析和设计软件。通过封装，继承，多态。使业务逻辑和产品逻辑解耦。
1.1 封装
首先我们对业务逻辑和界面逻辑封装。这样，如果我们的程序需要移植到其他平台上去的话，业务逻辑可以不用动。我们需要重新编写的只是页面逻辑。（若二者语言是相同的话）
1.2 松耦合和紧耦合
如果我们所有的算法都在一个方法当中，我们修改或者添加一个算法，那么其他的算法很可能在我们不知情的情况下发生了变动。（这就看自测和测试人员能否发现了）若发现不了，很可能产生严重的bug。
所以，我们需要将所有的算法进行松耦合。将他们分别定义。
但是如果我们将他们分别提出一个单独的方法，这样只是在一定程度上解耦了，我们还可以更进一步。
1.3 继承
定义一个基类Operation，让所有的算法都继承这个类。
这样，所有算法的具体实现都在自己的类当中，根本不会相互影响。
若我们重新定义一个新的算法，我们可以让该算法继承Operation类，之后把判断逻辑添加到工厂当中。
那我们怎么把定义好的这些算法类联系到我们的逻辑当中呢？这就用到了多态。
1.4 多态
我们新建一个工厂类，在该类当中对用户的操作进行判断，eg:使用switch 来判断用户具体的操作，根据这个操作，给出对应的Operation 实现类。返回该类给我们的业务逻辑当中就可以了。
这就是简单工厂模式的实现思路，一个从封装，到继承，再到多态循序渐进的过程。
2 UML图
大家都见过UML图，基础的我就不说了，这里记录类与类，类与接口之间的关系以及一些思考。
1. 类与类之间的关系使用实线和空心三角表示，表示*继承*。
2. 类与接口之间是通过虚线和空心三角表示。表示*实现* 他和第一条的区别就是实线和虚线的区别
3. 当一个类需要知道另一个类时，表示 *关联关系* 。使用实线箭头表示。
4. A对象包含B，但B并不是A的一部分。这表示 *弱拥有* 。用空心棱形和箭头表示 eg: 雁群 与 大雁之间的关系
5. 和4相反，A对象包含B，且B是A的一部分，表示 *拥有*。 用实心棱形和箭头表示。 eg: 翅膀和鸟
6. *依赖关系*，使用虚线箭头。 eg: 鸟 和空气、水 之间的关系
我们在构建一个类的时候，要思考这个类和其他类之间的关系，
只有这样才能构建出更好更稳定的系统。
SUM
编程时一门技术，更加是一门艺术。
编程也不是一蹴而就的，需要反复思考和琢磨。
共勉。
