简单工厂模式与策略模式

在现实开发中，遇到中途改需求,加功能的事情屡见不鲜.但面对已完成的程序代码,却是需要几乎重头来过的尴尬,这实在是痛苦不堪。说白了,原因就是因为我们原先所写的程序,不容易维护,灵活性差,不容易扩展,更谈不上复用,因此面对需求变化,加班加点,对程序动大手术的那种无奈也就成了非常正常的事了。所以在开发中要运用面向对象的分析设计编程思想,开始考虑通过封装、继承、多态把程序的耦合度降低,不把程序所有逻辑写在一起，尽量业务逻辑分离开，避免改动一小点东西，需要造成大量代码重新编译。这就需要使用设计模式使得程序更加的灵活,容易修改,并且易于复用。

• 简单工厂模式--创建型模式

  ---

1. 定义：定义一个工厂类，他可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类
2. 在简单工厂模式中用于被创建实例的方法通常为静态(static)方法,因此简单工厂模式又被成为静态工厂方法(Static Factory Method)
3. 需要什么，只需要传入一个正确的参数，就可以获取所需要的对象，而无需知道其实现过程
4. 例如，计算器（加减乘除）运算,加减乘除则被称为参数，工厂可以根据参数的不同返回不同的算法，这就是简单工厂模式

• 简单工厂模式的优缺点和适用环境  

---

• 简单工厂模式的优点

　　　　（1）工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责
　　　　（2）客户端无需知道所创建具体产品的类名，只需知道参数即可
　　　　（3）也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

• 简单工厂模式的缺点

　　　　（1）工厂类集中了所有产品的创建逻辑，职责过重，一旦异常，整个系统将受影响
　　　　（2）使用简单工厂模式会增加系统中类的个数(引入新的工厂类)，增加系统的复杂度和理解难度
　　　　（3）系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂
　　　　（4）简单工厂模式使用了static工厂方法，造成工厂角色无法形成基于继承的等级结构。

• 简单工厂模式的适用环境

　　　　(1)工厂类负责创建对的对象比较少，因为不会造成工厂方法中的业务逻辑过于复杂

　　　　(2)客户端只知道传入工厂类的参数，对如何创建对象不关心

使用简单工厂模式,可以避免每次新增或修改一种算法的时候需要去变更原有的代码，而我们仅仅只用确定如何去实例化对象，例如输入运算符号,工厂就能实例化出对应的算法对象，通过多态就能实现计算方式。

注：每新增一种算法需要在工厂类方法中增加相应的语句，例如用switch来判断时候，就需要增加一个分支，返回新增的实例对象。

Strategy 策略模式——对象行为模式

1.定义:定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立使用它的客户而变化。

2.适用性：许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。
算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
 

总结简单工厂模式和策略模式
1.从类型上说：简单工厂模式属于创建型模式，而策略模式属于行为型模式。
2.接下来，看一个小例子：

 斧子有很多种，有一个工厂专门负责生产各种需求的斧子。

工厂模式：
1）根据你给出的目的来生产不同用途的斧子，例如要砍人，那么工厂生产砍人斧子，要伐木就生产伐木斧子。
2）即根据你给出一些属性来生产不同行为的一类对象返回给你。
3）关注对象创建
策略模式：
1）用工厂生产的斧子来做对应的事情，例如用砍人的斧子来砍人，用伐木的斧子来伐木。
2）即根据你给出对应的对象来执行对应的方法。
3）关注行为的选择
3.简单工厂模式：根据客户选择的条件，来帮客户创建一个对象。
 策略模式：客户给它一个创建好的对象，它来帮客户做相应的事

通过比较客户端的代码发现：
  简单工厂模式：将对象的选择创建交给了简单工厂类，客户端只需要输入相应的条件就可以，不用负责对象的创建，但是需要客户端自己调用算法类的方法。但是一旦需要增加新的运算类，比如开根运算，就要去修改简单工厂类。
  策略模式：对象的选择创建仍需要自己来做，但是将调用方法的职责交给了Context类。一旦需要增加新的策略需要修改客户端。

因此，简单工厂模式的缺点就是当有新的需求增加时，需要频繁的修改工厂类。只用策略模式，当有新的需求增加时需要修改的是客户端，客户端仍然承担着创建对象的职责，并没有减轻客户端的压力。而将这两种模式结合起来使用，则需要修改 Context 类，总之不是完美的。