设计模式之工厂模式，以通知为例

概述

工厂模式解耦了调用方与被调用方。
最大的例子就是Spring。
我们以信息推送为例子，因为一般service都只有一个实现类，很难体会区别。而信息推送有的系统用手机，有的用app，有的用多端集成，所以是可能有多种实现的，包括spring的cache实现类，session存储类等等，这类非service类型一般都有多套实现类。
信息推送类结构图如下：

在有Spring之前，我们一个信息推送类的引入方式是，在所有需要推送信息的类里加一个如下代码：
private MsgSender msgSender = new PhoneMsgSender;
然后方法里写msgSender.send(new MessageBuilder().build());
如果这个时候我要修改系统里的所有MsgSender实现类，改成app的或者用委派模式实现的多种集成的。我需要做如下几件事

• 找出系统里所有用了这个功能的代码；
• 将实现类改为我要用的新的模式。

如果我这是一个基础功能，要用于多个项目的话，每个新项目都要这么改一遍。
这个时候我们如果定义了一个工厂类，我们就不需要改这些代码了。

我们的代码是private MsgSender = DefaultMsgSenderFactory.getMsgSender(MsgSender.class);
当项目要切换的时候，可以通过配置文件等方式去修改系统级别的MsgSender；

现在通过使用Spring，很多配置层级可以通过注册不同的Bean或者yml文件配置来实现使用不同类型的实现，而Spring通过BeanFactory来注入这些实现，将调用方与创建方解耦。
一个系统里的动态配置项还是很多的，比如session存储方式：redis存储、本地存储，Spring Cache集成什么类型的cache实现：redis、ehcache。事务管理的实现类，各种我们在Config中配置的Bean等等。

实例

以Spring里的切面代理工厂为例。

@SuppressWarnings("serial")
public class DefaultAopProxyFactory implements AopProxyFactory, Serializable {

	@Override
	public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
		if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
			Class<?> targetClass = config.getTargetClass();
			if (targetClass == null) {
				throw new AopConfigException("TargetSource cannot determine target class: " +
						"Either an interface or a target is required for proxy creation.");
			}
			if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
				return new JdkDynamicAopProxy(config);
			}
			return new ObjenesisCglibAopProxy(config);
		}
		else {
			return new JdkDynamicAopProxy(config);
		}
	}

	private boolean hasNoUserSuppliedProxyInterfaces(AdvisedSupport config) {
		Class<?>[] ifcs = config.getProxiedInterfaces();
		return (ifcs.length == 0 || (ifcs.length == 1 && SpringProxy.class.isAssignableFrom(ifcs[0])));
	}
}

简单将就是根据入参不同返回不同的类对象
Spring的BeanFactory也算一个大的工厂，他包括注册和获取两个大的接口，获取时通过特定的配置属性（class或者name）来获取。

抽象工厂

抽象工厂是多个工厂继承工厂接口，不同的工厂创建不同 系列 的工厂，相当于将工厂们根据对象的相关性隔离开。
没想到什么实际应用场景。