工厂模式：关于一个工厂的故事( 二 ) _工厂

小曾又想了想，咋又要动现有的产品线？不得行，不得行！现在虽然轻松，以后要是再出现其他新型电视机，又要改动，老是改来改去，迟早要出事！
经过一番苦想，既然电视生产的具体流程没法统一，何不建造新的工厂，由特定的工厂来针对性地生产特定的电视机呢？又想到了如下方案：
要建立多个工厂，那么就需要有工厂的标准，工厂是用来生产电视机，而不是来干其他事情的。
电视机工厂建设标准：
/*** 电视机工厂* @author zherop*/public interface TVFactory {/*** 生产电视机* * @return*/public TV createTV();}
建造具体工厂：
/*** 海尔电视机工厂* @author zherop*/public class HaierTVFacatory implements TVFactory {public TV createTV() {return new HaierTV();}}/*** 海信电视机工厂* @author zherop*/public class HisenseTVFactory implements TVFactory {public TV createTV() {return new HisenseTV();}}/*** 荣耀智慧屏工厂* @author zherop*/public class HonorSmartTVFactory implements TVFactory {public TV createTV() {return new HonorSmartTV();}}
测试：
public class Client {public static void main(String[] args) {// 使用荣耀智慧屏工厂TVFactory tvFactory = new HonorSmartTVFactory();TV tv = tvFactory.createTV();// 测试电视机是否正常工作tv.play();}}
嘿嘿，小曾心想，这样工厂以后灵活性很高了，无论科技怎么发展，工厂都能轻松应对。

文章插图
看到这儿，故事就差不多结束了，至此工厂方法模式也讲得差不多了，各种变体也蕴含其中。设计模式虽是招式，但是需要根据不同的场景，进行灵活变动，不能太死板了。
定义
工厂方法模式定义：工厂方法模式又称工厂模式，工厂父类负责定义创建产品对象的公共接口，而工程子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。
涉及的角色：
抽象产品（）
抽象产品是定义产品的接口。比如故事中的TV类。
具体产品（）
具体产品实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，它们之间一一对应。比如故事中的、、类。
抽象工厂（）
在抽象工厂类中，声明了工厂方法，用于返回一个产品。比如故事中的类。
具体工厂（）
具体工厂类是抽象工厂类的子类，实现了抽象工厂中定义的工厂方法，并可由客户端调用，返回一个具体产品类的实现。比如故事中的、类。
类图：
工厂方法模式，扩展性非常好，符合开闭原则，是典型的解耦框架。高层模块只需要知道产品的抽象类，其他实现类都不需要关心，符合迪米特法则；只依赖于产品类的抽象，符合依赖倒置原则；也符合里氏代换原则。
理论上，工厂方法模式在所有需要生成对象的地方都可以使用，但是需要考虑是否要增加一个工厂类来进行管理，毕竟会增加代码的复杂度。