工厂模式

工厂模式

通过“对象创建”绕开new，避免new对象导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象后的第一步工作 。

tips

工厂模式：将创建对象引起的变化关到工厂的笼子里 。

工厂模式并不会消除变化，而是集中管理由创建对象所带来的变化。

例子

假如，公司在为A超市设计商业智能软件 需要完成：

1.获取数据2.建模3.展示

于是项目完成后主要代码如下：

public class BusinessIntelligence { public static void main(String[] args) { //获取数据 DataManagerA DMA = new DataManagerA(); Data data = DMA.getData(); //训练模型 Model modelA = new Model(data); modelA.train(); Data presentData = modelA.predict(); //web展示 Presentor presentor = new Presentor(presentData); presentor.present(); } }

后来因为市场反响好，好几家公司都要买公司的产品，你发现只需改获取数据代码就能轻松完成需求。于是对于B、C公司你分别改成了。

B公司

DataManagerB DMB = new DataManagerB(); Data data = DMB.getData();

C公司

DataManagerC DMC = new DataManagerC(); Data data = DMC.getData();

分别建立新项目，很轻松就搞定了。直到模型团队说要修改模型，你发现必须到A,B,C 三个项目下改动，而且随着客户的增加，改动的重复工作量也越来越多，分散各处的代码越来越不利于维护。

总结原因，DataManager改动所造成的影响被扩散了。更严重的是，由于一时偷懒，你让他扩散到了整个项目。

为了不让影响扩散，首先会想到，把公共的行为抽象成接口：

DataManagerInterface dm = new DataManagerInterface ()

虽然保证了赋值语句左边的代码稳定了，但抽象但接口是不能创建的。 new DataManagerInterface () 于是就想，是否可以用一个函数返回

pubic DataManagerInterface getDataManager (){ return new new DataManagerC() } DataManagerInterface dm = getDataManager();

由于这个函数的实现会随着公司的不同而不同，这是变化，千万不能留在本类中，最好是找个地方集中管理起来。

于是就得到了

DMFacotry f; DataManagerInterface dm = f.getDataManager();

这时由于创建所带了的变化，被工厂类管理起来了。,新增一个客户D，程序员实现D的DataManagerD，然后把DataManagerD通过Factory的接口传递给BusinessIntelligence对象。

此时BusinessIntelligence类中代码稳定了下来，变化被放到了工厂类的具体实现中。

总结

工厂模式就是用来管理由创建所带来改动，把这些改动关到工厂的笼子里。

没有工厂模式前，程序员为每个公司维护来一分项目代码，一有改动很难处理。引入工厂模式后，数据获取方式变化后，只需要业务同事实现具体的工厂类，并传给BusinessIntelligence即可。