面向对象的设计模式系列之二：工厂方法模式(FactoryMethod)
Python中的工厂模式
Python中的工厂模式工厂模式（Factory Pattern）是一种常用的设计模式，用于创建对象。
它属于创建型模式，通过定义一个工厂类负责创建其他对象的实例，而不必直接使用new关键字来创建对象。
工厂模式使得代码的可拓展性和复用性更好，同时也隐藏了对象的创建和实现细节，简化了客户端的操作。
工厂模式的核心思想是将对象的实例化操作封装起来，让客户端只需调用工厂方法即可创建所需的对象。
从而达到降低系统耦合度的目的。
工厂模式的实现方式有两种：一种是通过一个单独的工厂类来创建所需的对象，另一种是通过将工厂方法定义在需要创建对象的类中。
其中，单独的工厂类又可以分为简单工厂和工厂方法两种模式。
1.简单工厂模式简单工厂模式（Simple Factory Pattern），也叫静态工厂模式，由一个工厂类负责创建所有需要的产品类的实例。
客户端只需向该工厂类传递相应的参数，即可获取所需的对象。
该模式下，工厂类通常是一个静态类或者包含一个静态方法的类。
简单工厂模式的代码结构如下：```class Product:def __init__(self):passclass ProductA(Product):def __init__(self):print("Product A")class ProductB(Product):def __init__(self):print("Product B")class SimpleFactory:def create_product(self, product_type):if product_type == "A":return ProductA()elif product_type == "B":return ProductB()factory = SimpleFactory()productA = factory.create_product("A")productB = factory.create_product("B")```该代码中，类Product、ProductA、ProductB分别为抽象产品类、具体产品类。
设计模式的分类及功能划分
设计模式的分类及功能划分设计模式有两种分类⽅法，即根据模式的⽬的来分和根据模式的作⽤的范围来分。
⼀、根据⽬的来分；通过完成什么⼯作划分为创建型模式、结构型模式和⾏为型模式 3 种类型 1、创建型模式：作⽤于对象的创建，将对象的创建与使⽤分离。
其中囊括了单例、原型、⼯⼚⽅法、抽象⼯⼚、建造者5 种创建型模式。
2、结构型模式：将类或对象按某种布局组成更⼤的结构，其中以代理、适配器、桥接、装饰、外观、享元、组合 7 种结构型模式为主。
3、⾏为型模式：作⽤于类或对象之间相互协作共同完成单个对象⽆法单独完成的任务，以及怎样分配职责。
主要包含了模板⽅法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种⾏为型模式。
⼆、根据作⽤范围来分；根据是⽤于类上还是⽤于对象上划分分为类模式和对象模式两种。
1、类模式：⽤于处理类与⼦类之间的关系，这些关系通过继承来建⽴，在编译时刻便确定下来了。
⼯⼚⽅法、（类）适配器、模板⽅法、解释器均属于该模式。
2、对象模式：⽤于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运⾏时刻是可以变化的，更具动态性。
除了以上 4种，其他的都是对象模式。
设计模式的分类表设计模式的功能1、单例（Singleton）模式：某个类只能⽣成⼀个实例，该类提供了⼀个全局访问点供外部获取该实例，其拓展是有限多例模式。
2、原型（Prototype）模式：将⼀个对象作为原型，通过对其进⾏复制⽽克隆出多个和原型类似的新实例。
3、⼯⼚⽅法（Factory Method）模式：定义⼀个⽤于创建产品的接⼝，由⼦类决定⽣产什么产品。
4、抽象⼯⼚（AbstractFactory）模式：提供⼀个创建产品族的接⼝，其每个⼦类可以⽣产⼀系列相关的产品。
5、建造者（Builder）模式：将⼀个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
6、代理（Proxy）模式：为某对象提供⼀种代理以控制对该对象的访问。
面向对象23种设计模式
面向对象23种设计模式面向对象23种设计模式在面向对象的编程中，设计模式是一种解决问题的通用方案。
设计模式可以帮助开发人员在开发过程中减少代码的冗余和复杂性，并提高代码的可维护性和可重用性。
本文将介绍23种面向对象的设计模式。
1. 工厂方法模式工厂方法模式是一种创建型设计模式，它定义了一个用于创建对象的接口，但是让子类决定实例化哪个类。
在工厂方法模式中，客户端不需要知道具体的创建逻辑，只需要知道工厂类中定义的接口即可。
2. 抽象工厂模式抽象工厂模式是一种创建型设计模式，它提供了一个接口，用于创建相关或依赖对象的家族，而不需要指定它们的具体类。
在抽象工厂模式中，客户端不需要知道具体的创建逻辑，只需要知道工厂类中定义的接口即可。
3. 单例模式单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个访问该实例的全局点。
4. 原型模式原型模式是一种创建型设计模式，它允许复制或克隆一个现有的对象，而不必知道其具体实现。
5. 建造者模式建造者模式是一种创建型设计模式，它允许逐步创建复杂的对象，而不必知道其内部实现细节。
6. 适配器模式适配器模式是一种结构型设计模式，它将一个或多个不兼容的类或接口转换为客户端所需的接口。
7. 桥接模式桥接模式是一种结构型设计模式，它将抽象部分与其实现部分分离开来，以便独立地进行修改。
8. 组合模式组合模式是一种结构型设计模式，它将一组对象作为单个对象处理，以便客户端可以以相同的方式处理单个对象和组合对象。
9. 装饰器模式装饰器模式是一种结构型设计模式，它允许向现有对象添加额外的功能，同时不改变其现有的结构。
10. 外观模式外观模式是一种结构型设计模式，它为一组复杂的子系统提供了一个统一的接口，以便于客户端使用。
11. 享元模式享元模式是一种结构型设计模式，它利用共享技术来最小化内存使用，以及提高应用程序的性能。
12. 代理模式代理模式是一种结构型设计模式，它提供了一个代理对象，使得客户端可以通过代理对象间接地访问实际对象。
23种设计模式
创建型模式1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式：客户类和工厂类分开。
消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时，工厂类也要做相应的修改。
如：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。
（这一定比美军在伊拉克用的翻译机好卖）建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。
（100块钱一份，你要不要）原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。
23种设计模式记忆口诀
23种设计模式记忆口诀设计模式是软件开发中常见的解决方案模板，它们能够解决许多常见的设计问题。
为了帮助记忆23种设计模式，可以使用下面这个口诀来记忆：Creational Patterns（创建型模式）:1. Singleton（单例模式）：一个类能产生一个实例，全局访问。
2. Builder（建造者模式）：分步骤创建复杂对象，易拓展。
3. Factory Method（工厂方法模式）：子类决定实例化哪个对象。
4. Abstract Factory（抽象工厂模式）：创建一组相关对象，不依赖具体类。
5. Prototype（原型模式）：通过复制现有对象来创建新对象。
Structural Patterns（结构型模式）:6. Adapter（适配器模式）：将类的接口转换为客户端希望的接口。
7. Bridge（桥接模式）：将抽象部分与实际部分分离。
将对象组合成树形结构来表示部分整体的层次结构。
9. Decorator（装饰器模式）：动态地给对象添加功能。
10. Facade（外观模式）：提供一个统一的接口，简化客户端使用。
11. Flyweight（享元模式）：共享细粒度对象，减少内存使用。
12. Proxy（代理模式）：控制对其他对象的访问。
Behavioral Patterns（行为型模式）:13. Chain Of Responsibility（责任链模式）：将请求的发送者和接收者解耦，多个对象都可能处理请求。
将请求封装成对象，可以用参数化方式处理。
15. Iterator（迭代器模式）：提供一种遍历集合的统一接口。
16. Mediator（中介者模式）：将多个对象之间的复杂关系解耦。
17. Memento（备忘录模式）：将对象的状态保存起来，以后可以恢复。
18. Observer（观察者模式）：当一个对象改变状态时，依赖它的对象都会收到通知。
19. State（状态模式）：对象的行为随状态的改变而改变。
06设计模式工厂方法模式Fac讲义toryMethod
简单工厂类 +CreateOperate() : 运算类
用户要求：添加一个新运算
问题(Problem)
class OperationFactory {
public static Operation createOperate(string operate) {
Operation oper = null; switch (operate) {
加法工厂
减法类 +GetResult() : double
除法类 +GetRes厂
工厂方法模式(Factory Method)
// 工厂方法 interface IFactory {
Operation CreateOperation(); }
// 专门负责生产“+”的工厂 class AddFactory : IFactory {
public Operation CreateOperation() {
return new OperationDiv(); } }
工厂方法模式(Factory Method)
static void Main(string[] args) {
try {
Console.Write("请输入数字A："); string strNumberA = Console.ReadLine(); Console.Write("请输入数字B："); string strNumberB = Console.ReadLine(); string strResult = "";
精品
06设计模式工厂方法模式 FactoryMethod
问题(Problem)
软件工程中的设计模式
软件工程中的设计模式设计模式是在软件工程中，为了应对常见的设计问题，而提出的一系列可重用的解决方案。
设计模式可以帮助我们提高代码的可维护性、可扩展性和复用性。
设计模式主要分为三类：创建型、结构型和行为型。
一、创建型模式创建型模式主要关注对象的创建过程，主要有以下五种模式：1.单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。
2.工厂方法模式（Factory Method）：定义一个接口用于创建对象，但让子类决定实例化哪个类。
3.抽象工厂模式（Abstract Factory）：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
4.建造者模式（Builder）：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。
5.原型模式（Prototype）：通过复制现有的实例来创建新的实例，而不是通过构造函数创建。
二、结构型模式结构型模式主要关注类和对象之间的组合，主要有以下七种模式：1.适配器模式（Adapter）：将一个类的接口转换成客户端期望的另一个接口，使得原本接口不兼容的类可以一起工作。
2.桥接模式（Bridge）：将抽象部分与实现部分分离，使它们可以独立地变化。
3.组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构，使得客户可以统一使用单个对象和组合对象。
4.装饰器模式（Decorator）：动态地给一个对象添加一些额外的职责，而不改变其接口。
5.门面模式（Facade）：为一组复杂的子系统提供一个统一的接口，使得子系统更容易使用。
6.享元模式（Flyweight）：运用共享技术有效地支持大量细粒度的对象。
7.代理模式（Proxy）：为其他对象提供一个代理以控制对这个对象的访问。
三、行为型模式行为型模式主要关注对象之间的通信，主要有以下十一种模式：1.职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免了请求发送者和接收者之间的耦合关系。
java设计模式及应用场景
Java设计模式及应用场景1. 概述设计模式是一种通用的解决问题的模板或蓝图，它提供了解决常见软件设计问题的经验。
在软件开发过程中，设计模式可以提高软件的可维护性、可扩展性和重用性。
Java语言是一种面向对象的编程语言，提供了一些常见的设计模式，并且在Java开发领域有广泛的应用。
本文将对Java中的一些常见设计模式及其应用场景进行深入探讨。
2. 创建型设计模式创建型设计模式主要关注对象实例化的方式，目标是提供一种灵活、可扩展的对象创建机制。
2.1 工厂方法模式（Factory Method Pattern）工厂方法模式是一种常见的创建型设计模式，它定义了一个用于创建对象的接口，但将具体的对象创建操作延迟到子类。
工厂方法模式可以隐藏对象的具体创建方式，使得客户端代码与具体对象解耦。
应用场景•当需要创建的对象有共同的接口或基类，并且需要根据具体情况选择其中一个对象时，可以使用工厂方法模式。
•当对象的创建过程比较复杂或需要根据不同的条件创建不同的对象时，可以使用工厂方法模式。
示例代码// 定义产品接口interface Product {void doSomething();}// 具体产品类1class ConcreteProduct1 implements Product {public void doSomething() {// 具体产品1的实现}}// 具体产品类2class ConcreteProduct2 implements Product { public void doSomething() {// 具体产品2的实现}}// 定义工厂接口interface Factory {Product createProduct();}// 具体工厂类1class ConcreteFactory1 implements Factory { public Product createProduct() {return new ConcreteProduct1();}}// 具体工厂类2class ConcreteFactory2 implements Factory { public Product createProduct() {return new ConcreteProduct2();}}// 客户端代码public class Client {public static void main(String[] args) {Factory factory = new ConcreteFactory1(); Product product = factory.createProduct(); product.doSomething();}}2.2 抽象工厂模式（Abstract Factory Pattern）抽象工厂模式是一种创建型设计模式，它提供了一个创建一系列相关或相互依赖对象的接口，而无需指定具体的类。
23种设计模式记忆口诀
23种设计模式记忆口诀根据内容要求，对23种设计模式进行简要说明，并整理成口诀。
设计模式是软件开发中常用的一种解决方案，它提供了面向对象设计和编程中常见问题的解决思路和方法。
根据GoF（Gang of Four）的分类，设计模式可以分为创建型、结构型和行为型三种类型，共23种设计模式。
1. 创建型模式（Creational Patterns）：- 工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，但由子类决定实例化的类。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关对象或依赖对象的接口，而无须指定它们的具体类。
- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点。
- 原型模式（Prototype Pattern）：用于创建重复性对象的一个原型。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建和表示分离，使得同样的构建过程可以创建不同的表示。
2. 结构型模式（Structural Patterns）：- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。
- 桥接模式（Bridge Pattern）：将抽象部分和它真正的实现分离，使它们独立的变化。
- 装饰器模式（Decorator Pattern）：动态地将责任附加到对象上，扩展功能。
- 外观模式（Facade Pattern）：为子系统中的一组接口提供一个统一的接口，以简化系统的使用。
3. 行为型模式（Behavioral Patterns）：- 策略模式（Strategy Pattern）：定义一系列算法，将每个算法封装起来，并使它们可以相互替换。
- 模板方法模式（Template Method Pattern）：定义一个算法的骨架，由子类实现具体步骤。
工厂模式简介和应用场景
⼯⼚模式简介和应⽤场景⼀、简介⼯⼚模式主要是为创建对象提供了接⼝。
⼯⼚模式按照《Java与模式》中的提法分为三类：1. 简单⼯⼚模式(Simple Factory)2. ⼯⼚⽅法模式(Factory Method)3. 抽象⼯⼚模式(Abstract Factory)⼆、简单⼯⼚模式我喜欢吃⾯条，抽象⼀个⾯条基类，(接⼝也可以)，这是产品的抽象类。
public abstract class INoodles {/*** 描述每种⾯条啥样的*/public abstract void desc();}先来⼀份兰州拉⾯（具体的产品类）：public class LzNoodles extends INoodles {@Overridepublic void desc() {System.out.println("兰州拉⾯上海的好贵家⾥才5 6块钱⼀碗");}}程序员加班必备也要吃泡⾯（具体的产品类）：public class PaoNoodles extends INoodles {@Overridepublic void desc() {System.out.println("泡⾯好吃可不要贪杯");}}还有我最爱吃的家乡的⼲扣⾯（具体的产品类）：public class GankouNoodles extends INoodles {@Overridepublic void desc() {System.out.println("还是家⾥的⼲扣⾯好吃 6块⼀碗");}}准备⼯作做完了，我们来到⼀家“简单⾯馆”（简单⼯⼚类），菜单如下：public class SimpleNoodlesFactory {public static final int TYPE_LZ = 1;//兰州拉⾯public static final int TYPE_PM = 2;//泡⾯public static final int TYPE_GK = 3;//⼲扣⾯public static INoodles createNoodles(int type) {switch (type) {case TYPE_LZ:return new LzNoodles();case TYPE_PM:return new PaoNoodles();case TYPE_GK:default:return new GankouNoodles();}}}简单⾯馆就提供三种⾯条（产品），你说你要啥，他就给你啥。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
在上一篇文章中(Singleton设计模式)曾谈到了工厂模式，那究竟什么是工厂模式呢？它又能解决什么样的问题呢？在知晓这个问题之前，让我们先了解一个概念：对象耦合。
经常在很多技术书籍上听到"松耦合，高内聚"。
那什么是松耦合呢？既然有松耦合，那应该存在相对的紧耦合吧。
两者之间到底有什么联系呢？带着这些问题，我们可以展开为什么需要工厂模式的缘由。
松耦合即在软件系统中，模块与模块之间在应对软件变化(主要来自需求变化)时，一些模块很容易被替换或更改，而能使其他模块保持不变。
相对的，紧耦合即软件应对变化时，一些软件的改变将会使相关模块发生改变。
先看看下面的两幅图：图1——紧耦合图2——松耦合我们在这里姑且说明一下，两图中的每根线代表系统的模块，图2中的圆圈代表接口。
从图1中我们可以看出，各个系统模块之间相互依赖，当我们面对需求改变时，也就是说图1中有几根线需要改变时，与之相关的线将因此随之而改变，导致整个系统处于不稳定状态之中。
而图2中，我们假设中间的那根长线为系统的主模块，而在主模块上附加的那些分支为次模块，并且此模块与主模块之间是以接口来建立依赖关系，各此模块之间彼此相对独立，这样当其中几个次模块改变时，不会影响其他的次模块。
从两图中我们不难发现，图2较图1更优越，能够保持整个软件系统的稳定性和可维护性。
由此我们总结：当我们在设计软件系统时，首先必须分清系统模块的主次，并建立起主模块和多个次模块，主模块与次模块之间以接口的方式相互依赖，各次模块之间通过主模块相互贯通。
也即是：高层模块(主模块)不直接依赖于低层模块(次模块)，低层模块的变动不会影响到高层模块和其他相关次模块的变动。
相信到这里，大家对这个概念应该有充分的认识了，接下来我们开始工厂模式的讲解了，首先以简单工厂开始吧。
设计意图：定义一个用于创建对象的接口(或抽象类)，让子类决定实例化哪一个类，客户端却不知道具体的实现类。
应用场景: 在软件系统中，经常面临着"某个对象"的创建工作，但由于需求的变化导致这个对象的创建方式剧烈的变化，但是它却拥有相对稳定的接口。
如何应对这种变化呢？需要提供一种"封装机制"来隔离这个"易变对象"的变化，而使"依赖于该易变对象的其他对象"不随着需求改变而改变。
实例案例：现在存在一套Web系统是在SQL Server数据库环境下工作，而且也运行良好。
但突然有一天由于公司业务量的增长，数据量大为剧增可能需要往Oracle迁移，实现数据库的完全切换，可能原有的支持SQL Server数据库环境的数据访问底层已经无法满足现在业务的需要，但又不能去直接改变底层访问的代码，可能以后还有其他数据库来支撑。
我们就会想到使用统一的数据库访问接口，让SQL Server,Oracle以及其他数据库都支持这套接口。
这样做固然解决支持多数据库问题，但问题在于客户端调用时，怎样去实例化该接口对应的数据库类型，在这种情况下简单工厂就能很好解决这个创建获取数据库类型的问题了。
///<summary>///定义数据库提供者基类///</summary>public abstract class DBProvider{protected string connectionString = String.Empty;protected DbConnection Connection = null;public DBProvider(string connectionString){this.connectionString = connectionString;}public abstract void Connect();public abstract bool CheckConect();public abstract DataTable ExecuteDataSet(string selectSql);public abstract bool ExecuteInsert(string insertSql);public abstract bool ExecuteUpdate(string updateSql);public abstract bool ExecuteDelete(string deleteSql);}接下来是Sql Server提供者实现类：Sql Server提供者实现///<summary>/// Sql Server提供者实现///</summary>public class SqlServerProvider : DBProvider{public SqlServerProvider(string connectionString): base(connectionString){Connection = new SqlConnection(connectionString);}public override void Connect(){//SqlServer Connect}public override bool CheckConect(){return true;}public override DataTable ExecuteDataSet(string selectSql) {return null;}public override bool ExecuteInsert(string insertSql){return true;}public override bool ExecuteUpdate(string updateSql){return true;}public override bool ExecuteDelete(string deleteSql){return true;}}接下来是Oracle提供者实现类：Oracle提供者实现///<summary>/// Oracle提供者实现///</summary>public class OracleProvider : DBProvider{public OracleProvider(string connectionString): base(connectionString){Connection = new OracleConnection(connectionString);}public override void Connect(){//Oracle Connect}public override bool CheckConect(){return true;}public override DataTable ExecuteDataSet(string selectSql){return null;}public override bool ExecuteInsert(string insertSql){return true;}public override bool ExecuteUpdate(string updateSql){return true;}public override bool ExecuteDelete(string deleteSql){return true;}}最后是获取提供者工厂类：///<summary>///数据库类型枚举///</summary>public enum DataBaseType{SqlServer,Oracle}///<summary>///获取数据库提供者工厂///</summary>public class DBFactory{public static DBProvider CreateDBProvider(DataBaseType dbType, string connectionString){switch (dbType){case DataBaseType.SqlServer:default:return new SqlServerProvider(connectionString);case DataBaseType.Oracle:return new OracleProvider(connectionString);}}}在客户端访问：public class Program{public static void Main(){var sqlserverProvider =DBFactory.CreateDBProvider(DataBaseType.SqlServer,"server=***;database=***;uid=***;password=***");var oracleProvider = DBFactory.CreateDBProvider(DataBaseType.Oracle, "DataSource=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT= MyPort)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=***)));UserId=***;Password=***;");}}此时发现如何获取数据库提供者的职责完全交给工厂去做了，客户端只需要传入对应的数据库类型和连接字符串就可以获取到对应的数据库提供者，是不是非常简单呢？在这里，我们不妨总结一下：按松耦合思路，客户端只依赖于数据库提供者工厂，而不依赖于具体的数据库提供者，在一定程度上实现了从SQL Server向Oracle迁移的过渡。
对于示例而言，主模块是客户端获取数据库提供者接口CreateDBProvider(),只要保持该接口不发生变化，即使其中某个具体的数据库提供者发生变化也不会影响到其他的数据库提供者，这正是松耦合的主旨所在。
从这个例子中也能总结出简单工厂的适用范围：要实例化的子类的数量有限且无复杂层级关系，并且可以在编译之前就可以提前预知，例如前面的数据库类型枚举。
如果要增加新的类型，势必导致子类的类型增加和工厂的变动(增加枚举标识和switch判断)，这无疑与我们的"松耦合"设计理念相违背(由于次模块的改变导致主模块随之变动)，因此我们提出了工厂方法模式来解决这个问题。
首先，我们要明确工厂模式所面临的问题，简单工厂通过传递参数的方式来决定实例化哪个子类，这种方式的弊端在于子类的增加可能是动态的，在编译之前不可预知到。