工厂方法模式角色分配:
interface IFactory //工厂接口 { IProduct GetProduct(); } //A工厂类 public class FactoryA: IFactory { IProduct productA; public FactoryA() { this.productA = new ProductA(); } public IProduct GetProduct() //A工厂生产A产品 { return this.productA; } } //B工厂类 public class FactoryB : IFactory { IProduct productB; public FactoryB() { this.productB = new ProductB(); } public IProduct GetProduct() //B工厂生产B产品 { return this.productB; } } //产品接口 public interface IProduct { //产品方法 //...... } //产品A public class ProductA : IProduct { //产品属性 //...... } //产品B public class ProductB : IProduct { //产品属性 //...... } //调用 Ifactory factoryA =new factoryA(); Iproduct pa=factory.GetProduct(); Iproduct pb=factory.GetProduct();
工厂方法模式优缺点
在工厂方法模式中,核心工厂类不在负责产品的创建,而是将具体的创建工作交给子类去完成。也就是后所这个核心工厂仅仅只是提供创建的接口,具体实现方法交给继承它的子类去完成。当我们的系统需要增加其他新功能时,只需要创建对应工厂和产品即可,这样很好地符合了“开放-封闭“原则。
虽然工厂方法模式满足了"开放-封闭”原则,但是这个模式也仍然有缺点:每次增加一个产品时,都需要增加一个具体类和对象实现工厂,是的系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。
开放封闭原则(Open Closed Principle)描述
符合开放封闭原则的模块都有两个主要特性:
1. 它们 "面向扩展开放(Open For Extension)"。
也就是说模块的行为是能够被扩展的。当应用程序的需求变化时,我们可以使模块表现出全新的或与以往不同的行为,以满足新的需求。
2. 它们 "面向修改封闭(Closed For Modification)"。
模块的源代码是不能被侵犯的,任何人都不允许修改已有源代码。
仔细观察这段代码,在工厂模式中,已经将工厂类分开,不再将所有产品在同一工厂中生产,这样就解决了简单工厂中不停的switch case的问题。如果说来了一个C产品,那么我们只需要写一个C工厂和C产品,在调用时用C工厂生产C产品即可,A和B工厂和产品完全不受影响。OK,优化说完了,但是还是有问题。
问题在哪里呢?当业务需求是需要生产产品族的时候,工厂就不再适合了。首先我们搞清楚何谓产品族和产品等级结构。举个例子来说,比如三星是一个品牌,三星生产洗衣机,电视,冰箱;格力也是一个品牌,格力也生产洗衣机,电视,冰箱。那么,三星工厂和格力工厂生产的2个品牌的洗衣机,就在洗衣机这种产品的产品等级结构中(当然洗衣机产品等级结构中还有LG,海尔,三菱等等不同的品牌的工厂的产品),所以,洗衣机就是一个产品等级。那么三星生产的三星洗衣机,三星电视机,三星冰箱就是三星这个工厂的产品族。可能还会有西门子工厂产品族,格力工厂产品族,美的工厂产品族等等。
(也就是说我们的前提是工厂只有一种,但它可以生成多种产品,若要不同的工厂,则这种设计模式不符合)