目录
1. 简单工厂模式概述
1.1 概念
简单工厂模式又称为静态工厂方法模式。将一个具体类的实例化交给一个静态工厂方法来执行定义一个类,根据参数的不同返回不同的类的实例。这些类具有公共的父类和一些公共的方法。简单工厂模式不属于GoF23种设计模式,但它是最简单的设计模式。
1.2 角色
简单工厂类(Simple Factory) 只包含了创建具体类的静态方法。 抽象产品(Product) 定义简单工厂中要返回的产品,一般是具体产品继承的父类或实现的接口。 具体产品(ConcreteProduct) 具体产品。 客户端(Client) 消费者。 1.3 类图
解读:
SimpleProductFactory 表示工厂类,是整个模式的核心,负责实现创建所有实例的内部逻辑。工厂类可以被
外界直接调用,创建所需的产品对象。工厂类中有一个负责生产对象的静态工厂方法,
系统根据工厂方法传入的参数,动态的决定应该创建出哪一个产品类的实例,其返回
类型为抽象产品类型。
Product 表示抽象产品角色,它是简单工厂模式所创建的所有对象的父类,负责定义所有实例
所共有的公共接口。
ConcreteProductXXX 表示具体产品角色,所有创建的对象都是充当这个角色的某个具体类的实例。 Client 表示客户端,免除直接创建产品对象的责任,而仅仅消费产品。
2. 简单工厂模式创建原理
简单工厂模式专门定义一个类来负责创建其他类的实例,这个类成为工厂类,被创建的类的实例通常都具有共同的父类。
下面以生产宝马,奥迪汽车和消费者消费汽车为实例:
汽车接口类:
/** * 汽车接口 * @author Administrator */ public interface Car { //启动汽车方法 public void run(); }
宝马汽车类:
/** * 宝马汽车类 * @author Administrator */ public class BaoMaCar implements Car{ @Override public void run() { System.out.println("宝马汽车启动!"); } }
奥迪汽车类:
/** * 奥迪汽车类 * @author Administrator */ public class AodiCar implements Car{ @Override public void run() { System.out.println("奥迪汽车启动!"); } }
工厂类:
/** * 汽车工厂类 * @author Administrator */ public class CarFactory { //静态方法:生产汽车 public static Car produceCar(String carName) { switch (carName) { case "宝马": return new BaoMaCar(); case "奥迪": return new AodiCar(); default: throw new RuntimeException("没有这个汽车的生成方法!"); } } }
消费者类:
/** * 消费者类 * @author Administrator */ public class Customer { public static void main(String[] args) { CarFactory.produceCar("宝马").run(); CarFactory.produceCar("奥迪").run(); CarFactory.produceCar("奔驰").run(); } }
运行结果:
宝马汽车启动! 奥迪汽车启动! Exception in thread "main" java.lang.RuntimeException: 没有这个汽车的生成方法! at com.simple_factory_pattern.CarFactory.produceCar(CarFactory.java:13) at com.simple_factory_pattern.Customer.main(Customer.java:8)
3. 简单工厂模式的优缺点
3.1 优点
职责单一,实现简单,且实现了客户端代码与具体实现的解耦。 工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象。 通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。 明确了各自的职责和权利,有利于整个软件体系结构的优化。 3.2 缺点
由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。因此它是违背开放封闭原则的。 当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利; 3.3 使用场景
工厂类负责创建的对象比较少; 客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心; 在一些不复杂的情况下使用