设计模式笔记1-简单工厂模式

1.复制和复用

        已经完成了项目A，还需要完成项目B，并且项目A和项目B所实现的功能有很多想同之处时，如果直接将项目A的代码复制到项目B去是非常不妥的行为，随着工程量的加大，维护时将会成为一场灾难。

        正确的做法应该是将项目A的功能分离开来，降低项目A的耦合性，然后可以在项目B中使用一部分项目A中的功能，差异的地方再在项目B中自行完成。

2.业务的封装

        在编写一个项目时，需要将它的业务逻辑和界面逻辑给分离开。例如，编写一个计算器的程序，我们就需要把输入提示、运算结果显示等代码做为一个类，再将数学运算作为另一个类，这样就可以完成两者的分离，如果之后出现一个新的项目，让我们把之前写的计算器从命令行程序变为Windows程序或Web版程序等，就可以直接复用之前写好的运算类。

3.松耦合

        项目进行了封装后有了一定的复用性，但是它还没有良好的扩展性。由于项目的发展，我们需要在原来实现的计算器上添加新的功能，加入平方、根号等。如果在原来项目的基础上修改的话，就必须修改已经写好的源代码。假如我们原来的代码是用switch、case语句来判断运算符，从而来进行运算，这样我们就不得不去修改switch、case语句，如果多人开发这个项目就会因为修改他人的代码让工程变得十分的危险。

        所以这里我们就需要用到继承和多态。我们先写出一个Operation的基类，给它写出一个Calculate的虚方法，然后让加、减、乘、除等分别继承Operation并实现Calculate方法，以后还有更多的功能都可以来继承Operation。这样做的最大好处就是降低了各功能之间的耦合度。

4.简单工厂模式

        有了上面的准备后，代码有了一定的可复用性和可扩展性，但是这个工程还有一个问题。这个工程实现了很多功能（加减乘除等），但是缺少了一个实例化这些功能的类。

        我们在使用这些计算类时，我们不可能同时去实例化所有的计算类，所以我们需要一个计算工厂类OperationFactory，它用来根据需求实例化对应的计算功能。在这个类的内部实现所有计算类的实例化，并通过一个方法来接受用户给的运算符，根据运算符的类型来实例化对应的运算类，这样就实现了一个简单工厂模式。以后如果我们还需要扩展，我们想再加入平方算法，我们需要去再派生一个Operation基类，用它来实现平方算法，并修改工厂类实现代码的扩展了。如果我们希望修改一下加法的算法，我们就需要去修改加法类相关的代码。

5.UML图

6.总结

简单工厂模式：一个工厂方法，依据传入的参数，生成对应的具体产品对象；

补充：

不属于23种GOF设计模式；

工厂方法一般设成静态方法，返回值一般是抽象类或接口，具体的产品类一般继承或实现抽象类、接口；

优点：产品使用者不需要关心产品类的创建过程，与具体产品的实现类达到解耦的效果；

缺点：违背"开放--封闭"原则(OCP)，因为新增一个产品类的时候，需要修改原先的工厂方法，并且必须派生一个新类，工作量较大；

适用场合：当工厂类负责创建的对象比较少的时候；