简单工厂模式

又在温习设计模式咯，所以把学习的经历写下来..... 我们希望建立一个银行系统，但银行系统应具有一些业务，诸如存款、取款、转账等，通过对这些业务进行抽象，得到一个业务接口： IOperation ，该接口包含一个业务处理的抽象方法operation，如下所示： 1 interface IOperation 2 { 3 void operation(); 4 } 通过该接口实现各个银行功能类： 1 /**/ /// <summary> 2 /// 存款业务处理类 3 /// </summary> 4 class SavingBox:IOperation 5 { 6 public void operation() 7 { 8 Console.WriteLine( " You are saving! " ); 9 } 10 } 11 /**/ /// <summary> 12 /// 取款业务处理类 13 /// </summary> 14 class OutingBox : IOperation 15 { 16 public void operation() 17 { 18 Console.WriteLine( " You are outing! " ); 19 } 20 } 21 /**/ /// <summary> 22 /// 转账业务处理类 23 /// </summary>

在 上一篇文章 中介绍了简单工厂模式，一个简单的银行系统开始初现端倪，现在我们开始为银行增加一个货币兑换业务，我们只需增加一个业务类，并实现 IOperation 接口就行了： 1 /**/ /// <summary> 2 /// 汇兑业务 3 /// </summary> 4 class Exchange : IOperation 5 { 6 public void operation() 7 { 8 Console.WriteLine( " you are exchanging! " ); 9 } 10 } 然后再在简单工厂类中加上一个判断： 1 switch (operation) 2 { 3 case " turn " : 4 opera = new TurningBox(); 5 break ; 6 case " out " : 7 opera = new OutingBox(); 8 break ; 9 case " exchange " : 10 opera = new Exchange(); // 汇兑业务 11 break ; 12 default : 13 opera = new SavingBox(); 14 break ; 15 } 也就是说我们每为银行增加一个业务都要重复以上两步操作,很明显，在银行业务很多的情况下，如缴费、汇款、理财等，用户每提出一个需求

转载:原地址http://www.cnblogs.com/zhangchenliang/p/3700820.html 简单工厂、工厂方法、抽象工厂、策略模式、策略与工厂的区别 结合简单示例和UML图，讲解工厂模式简单原理。 一、引子 话说十年前，有一个爆发户，他家有三辆汽车（Benz（奔驰）、Bmw（宝马）、Audi（奥迪）），还雇了司机为他开车。不过，爆发户坐车时总是这样：上Benz车后跟司机说“开奔驰车！”，坐上Bmw后他说“开宝马车！”，坐上 Audi后他说“开奥迪车！”。 你一定说：这人有病！直接说开车不就行了？！而当把这个爆发户的行为放到我们程序语言中来，我们发现C语言一直是通过这种方式来坐车的！ 幸运的是这种有病的现象在OO语言中可以避免了。下面以Java语言为基础来引入我们本文的主题：工厂模式！ 二、简介 工厂模式主要是为创建对象提供了接口。工厂模式按照《Java与模式》中的提法分为三类： 1. 简单工厂模式(Simple Factory) 2. 工厂方法模式(Factory Method) 3. 抽象工厂模式(Abstract Factory) 这三种模式从上到下逐步抽象，并且更具一般性。还有一种分类法，就是将简单工厂模式看为工厂方法模式的一种特例，两个归为一类。两者皆可，这本为使用《Java与模式》的分类方法。 在什么样的情况下我们应该记得使用工厂模式呢

工厂方法模式（Factory Method），是23种设计模式之一。DP中是这么定义工厂方法模式的： 工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 所谓工厂方法模式，其实也像我们现实生活中的工厂，也是用来生产东西的，只不过我们代码中的工厂是用来生产对象的，不要想歪，此对象非彼对象233。 我们在开发过程中，总是要编写许许多多的类，当我们需要一些类的实例化对象时，如果总是不管三七二十一在代码上直接去new的话，倒也不是说不行，只是会导致代码比较糟糕、不灵活。例如，有些通用的功能类或者需要隐藏得比较深的类（隐藏类是方便后期更换），你在你写的代码上去new它的对象，那么如果后期这个类更名了、移除了、功能增删了，那么你的写的代码就有可能会崩掉，需要重新去修改这些new对象的地方才能再次让你的代码正常运行。这就是一种耦合度高的体现，所以我们首先应该依赖的是一个抽象的接口或父类，而不是依赖具体的子类，这也是依赖倒转原则强调的，除此之外我们最好不要在一些容易发生变动的地方直接通过子类类名去new对象，不然的话依旧会出现这种情况。所以我们应该把子类对象的创建交给别人去完成，而这个 “别人” 就是工厂。 如果学过简单工厂模式，就应该知道，工厂的目的是为了帮我们解决创建对象实例的问题，并且工厂能够隐藏类名及对象创建的细节

抽象工厂模式（Abstract Factory），是23种设计模式之一。DP中是这么定义抽象工厂模式的： 抽象工厂模式（Abstract Factory），提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。 在学习抽象工厂模式之前，最好熟悉简单工厂模式以及工厂方法模式，这样对理解抽象工厂模式会有一定帮助，而且抽象工厂也是基于工厂方法模式的。 至于工厂是用来干什么的，我这里也不过多介绍了，因为之前在工厂方法模式里已经说过了，如果对工厂的概念不是太清楚的话，可以参考我之前的文章： https://blog.51cto.com/zero01/2067822 在这里我们暂时先不谈论抽象工厂是什么，因为如果直接上来就去描述、解释什么是抽象工厂，以及如何使用抽象工厂模式来设计代码，这样是无法很好的明白抽象工厂模式的概念以及它所带来的好处或坏处的，只会让人下意识的只去记住实现代码，而不是设计模式的思想。讲解其他模式也是一样，如果一上来就是代码+理论一顿灌，只会让人看得亿脸懵逼或似懂非懂。这就好比给你一块披萨告诉你很好吃，以及这块披萨上用了哪些好食材，你只管吃就可以了，那么如果你没有吃过难吃的披萨，可能就会以为披萨就应该是这个味道的。 所以我们先从有些糟糕的代码入手，并且分析这些代码哪些地方有问题，然后再演进成使用设计模式去重构代码，这样就能有一个明显的对比