似乎世界运行的规律就是越是更高级越是更简单，越是更简单更容易标准化，一旦标准化模式形成，按照这个标准可以衍生出无数个符合此标准的产品或者服务。在这里我介绍一种工厂方法模式，这种模式的使用频率可能是最高的，在平时的生活和工作中也颇为常见。
工厂方法模式，咋一听就好像这种模式的产生是从工业时代的工厂里面总结出来的，不过也不必追究溯源，掌握其精髓才是重中之重。
工厂方法模式的定义
不管三七二十一，先来领略一下工厂方法模式的概念，由浅入深，深入浅出的了解更能便于理解和掌握。
官方定义：是这么说的，定义一个用于创建对象的接口，但是让子类决定具体实例化哪一个类。工厂方法使一个类的实例化延迟到了子类。
通俗释义：抽象类或者接口给你定义好，也就是先进行高度抽象的定义，然后子类产品进行具体实现，工厂根据具体需要创建相应的产品。
如果上面的定义没有看懂，其实没有关系，重点在理解意会，我相信多看几遍其义自见。再不行，看看下面的图，加深理解，正所谓图文并茂，效果更好。
通用类图：
工厂方法模式的通用代码
创建抽象产品类，也就是定义一个公共的通用接口或抽象类，方便具体的子类实现或继承。
/**
* @Description:抽象产品类
*/
public abstract class AbstractProduct {
//声明抽象方法
public abstract void create();
//其他方法
public void otherMethod() {
//相关业务逻辑
}
}
此时就可以如法炮制，具体子类就可以继承抽象产品，来实现自己的产品创建细节。
/**
* @Description:具体子类1
*/
public class ConcreteProduct1 extends AbstractProduct {
@Override
public void create(){
//具体实现细节1
}
}
/**
* @Description:具体子类2
*/
public class ConcreteProduct2 extends AbstractProduct {
@Override
public void create(){
//具体实现细节2
}
}
以上产品定义好了，接下来就需要地方去创建这些产品，那么产品是在哪里创建的呢，那当然是工厂了。那么直接来个具体工厂创建就可以了吗，不不不，必须要站在一定的高度看问题，我们写程序必须要有起码的可读性和可维护性，所以先来创建一个抽象工厂，然后由交给具体工厂去创建产品。
/**
* @Description:抽象工厂嘞
*/
public abstract class AbstractFactory {
//根据具体参数（枚举，字符串，Class等），创建相应的产品对象
public abstract <T extends AbstractProduct> T createProduct(Class<T> c);
}
/**
* @Description:具体创建工厂类
*/
public class ConcreteCreator extends AbstractFactory {
@Override
public <T extends AbstractProduct> T createProduct(Class<T> c) {
AbstractProduct product = null;
//通过反射获取产品实例
try {
product = (AbstractProduct) Class.forName(c.getName()).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return (T) product;
}
}
以上就是整个工厂方法模式的通用代码，其实在实际开发工作中，很多模式的代码都开发好了，基本上都是些业务逻辑代码处理，但是要是进行代码重构或者进行新产品的设计的时候，这个时候框架型的代码就很重要。
工厂方法模式的使用场景
1.关于工厂方法模式的使用场景真的是太多了，例如在创建像每日必抢，促销直降以及更多类型的活动的时候，关于活动的管理以及活动的相关状态变化等维护，都可以考虑使用工厂方法模式，当然这种模式不一定是最好的，只有合适的场景下采用合适的设计模式才是最优的。
2.异常项目当中的使用，尤其是对接不同类型的外部接口，可以采用此种设计模式来满足不同类型业务场景。
工厂方法模式的优缺点
关于工厂方法模式的优缺点，更多的是突出其优点，更何况我们使用某个产品都是看中其优点，发挥其优势作用，毕竟瑕不掩瑜嘛！工厂方法模式是典型的解耦框架，符合三个原则，第一，符合迪米特原则：高层模块需要知道抽象类，其他的实现不必了解，所以知道你该知道的，其余让她随风吧！第二，符合依赖倒置原则：高层模块不依赖于底层模块，两者都应该依赖于抽象；抽象不应该依赖细节，细节应该依赖抽象。第三，当然也符合里氏替换原则：只要父类能出现的地方，子类也能出现。
优点：
1.良好的封装性。这种代码的风格是非常的优秀的，而且结构清晰可读性高，同时此类代码的可维护性也非常的高。
2.良好的扩展性。由于具有高度的扩展性，对于项目或产品的开发是非常有优势的，能够支持业务快速迭代。
3.屏蔽实现细节。也就是我们在进行调用的时候，只关注接口是否变化，具体的实现细节是完全没有必要关心的。
缺点：
在进行扩展的时候，子类可能扩展无限多，不过此类场景也非常的少见，如果使用恰当，还是能发挥巨大作用的。
工厂方法模式的经典应用
工厂方法模式也是有非常多的经典应用，阅读这些代码，可以加深对工厂方法模式的理解。
public abstract class Calendar
public abstract class NumberFormat
public abstract class EnumSet<E extends Enum<E>> extends AbstractSet<E>
工厂方法模式的实际应用
本例子是在项目中对频道活动与促销直降活动的一个小重构，创建活动是非常复杂的，包括很多校验规则，我这里知识抽象一下，把框架抽出来演示一下工厂模式的实际应用，和通用代码差不多的，可以参考理解一下。
/**
* @Description:活动服务接口
*/
public interface ActivityService {
/**
* 声明活动创建公共方法
* @param form
* @param context
* @throws Exception
*/
void createAct(ActivityForm form, Map<String, Object> context) throws Exception;
}
/**
* @Description:频道活动服务类
*/
public class ChannelActivityService implements ActivityService{
@Override
public void createAct(ActivityForm form, Map<String, Object> context) throws Exception {
//频道活动创建
}
}
/**
* @Description:促销直降活动服务类
*/
public class PromotionActivityService implements ActivityService{
@Override
public void createAct(ActivityForm form, Map<String, Object> context) throws Exception {
//促销直降活动创建
}
}
/**
* @Description:活动服务工厂类
*/
public class ActivityServiceFactory {
public ActivityService create(Integer type){
if (type == null){
return null;
}
if (type == 1)return new ChannelActivityService();
if (type == 2)return new PromotionActivityService();
throw new RuntimeException("不存在的活动类型");
}
}
/**
* @Description:活动创建调用方
*/
public class ActivityCreator {
public static void main(String[] args) throws Exception{
ActivityForm form = new ActivityForm();
ActivityServiceFactory factory = new ActivityServiceFactory();
ActivityService activity = factory.createActivity(1);
activity.createAct(form,null);
}
}
以上就是工厂方法模式的介绍，本身内容比较简单，但是要是能结合实际应用在工作中，我想帮助还是比较大的，尤其现在的项目系统体量不可谓不复杂，要抽出一些时间去应用设计模式重构是非常艰难的，但是还是要有这种意识，老代码都是一步一步慢慢重构出来的，今天抽出一个私有类，明天创建个辅助类，后天设计模式优化一下，这样慢慢的迭代优化就会有非常不错的成长，加油！