设计模式

单例模式的优点

1）实例控制：Singleton会阻止其他对象实例化其自己的Singleton对象的副本，从而确保所有对象都访问唯一实例。

2）灵活性：因为类控制了实例化过程，所以类可以更加灵活修改实例化过程。

5.2、单例模式的缺点

1）开销：虽然数量很少，但如果每次对象请求引用时都要检查是否存在类的实例，将仍然需要一些开销，可以通过使用静态初始化解决此问题。

2）可能的开发混淆：使用Singleton对象（尤其在类库中定义的对象）时，开发人员必须记住自己不能使用new关键字实例化对象。因为可能无法访问库源代码，因此应用程序开发人员可能会意外发现自己无法直接实例化此类。

3）对象的生存期：Singleton不能解决删除单个对象的问题。因为它包含对该静态的私有字段的引用，静态字段是不能被CLR回收内存的，该实例会和应用程序生命周期一样长，一直存在。

5.3、单例模式的使用场合

1）当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

2）当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

工厂模式的优点

看完简单工厂模式的实现之后，很多人肯定会有这样的疑惑--我们只是把变化的代码移到了工厂类中罢了，好像没有其它的变化了。如果客户想吃其它菜时，此时我们还是需要修改工厂类中的方法，也就是多加case语句（没应用简单工厂模式之前，修改的是客户类）。我首先要说：大家想的很对，每种设计模式只会解决一种问题，它们有自己的使用场景，没有一种模式可以解决所有问题，这个就是简单工厂模式的缺点所在（这个缺点后面介绍的工厂方法模式可以很好地解决）。

3.1、简单工厂模式的优点

1）简单工厂模式解决了客户端直接依赖于具体对象的问题。客户端可以消除直接创建对象的责任，而仅仅是消费产品。

2）简单工厂模式实现了对责任的分割，也起到了代码复用的作用，因为之前的实现（自己做饭的情况）中，换了一个人同样要去在自己的类中实现做菜的方法，然后有了简单工厂之后，去餐馆吃饭的所有人都不用那么麻烦了，只需要负责消费就可以了，此时简单工厂的烧菜方法就让所有客户共用了。

3.2、简单工厂模式的缺点

1）工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都会受到影响（通俗地意思就是：一旦餐馆没饭或者关门了，很多不愿意做饭的人就没饭吃了）。

2）系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，这样就会造成工厂逻辑过于复杂。

3.3、简单工厂的使用场景

1）当工厂类负责创建的对象比较少时可以考虑使用简单工厂模式。

2）客户如果只知道传入工厂类的参数，对于如何创建对象的逻辑不关心时可以考虑使用简单工厂模式。 

抽象工厂的优点

1）如果没有应对“多系列对象创建”的需求变化，则没有必要使用AbstractFactory模式，这时候使用简单工厂模式完全可以。

2）"系列对象"指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中“道路”与“房屋”的依赖，“道路”与“地道”的依赖。

3）AbstractFactory模式主要在于应对“新系列”的需求变动，其缺点在于难以应对“新对象”的需求变动。

4）AbstractFactory模式经常和FactoryMethod模式共同组合来应对“对象创建”的需求变化。

3.1、抽象工厂模式的优点

抽象工厂模式将系列产品的创建工作延迟到具体工厂的子类中，我们声明工厂类变量的时候使用的是抽象类型，同理，我们使用产品类型也是抽象类型，这样做可以尽可能地减少客户端代码与具体产品类之间的依赖，从而降低了系统的耦合度。耦合度降低了，对于后期的维护和扩展就更有利，这就是抽象工厂模式的优点所在。

可能有人会说在Main方法里面（客户端）还是会使用具体的工厂类，对的。这个其实我们可以通过.Net配置文件把这部分移出去，把依赖关系放到配置文件中。如果有新的需求我们只需要修改配置文件，根本就不需要修改代码了，让客户代码更稳定。依赖关系肯定会存在，我们要做的就是降低依赖，想完全去除很难，也不现实。

3.2、抽象工厂模式的缺点

有优点肯定就有缺点，因为每种模式都有它的使用范围，或者说不能解决的问题就是缺点。抽象工厂模式很难支持增加新产品的变化，这是因为抽象工厂接口中已经确定了可以被创建的产品集合，如果需要添加新产品，此时就必须去修改抽象工厂的接口，这样就涉及到抽象工厂类以及所有子类的改变，这样也就违背了开闭原则。

3.3、抽象工厂模式的使用场景

如果系统需要多套的代码解决方案，并且每套的代码方案中又有很多相互关联的产品类型，并且在系统中可以相互替换地使用一套产品的时候就可以使用该模式，客户端不需要依赖具体实现。