抽象工厂方法模式在工厂方法模式中，我们使用中间件形成以下格式的分离：用户 ↓创建者 ↓具体产品问题在这样，无论我们如何修改具体的产品，都不会影响到用户。现在，我们可以创建一批小工厂，有自己的产品，但是在模型层面形成了重复，那么如何解决这种重复呢？本篇将通过抽象工厂方法模式完成小公司的整合——抽象-工厂方法-模式，初步设计（母公司-子公司）：接下来，我们将通过抽象类解决多业务并行的问题。现在，我们要编写一个PIM数据格式解码器——PersonalInformationManage，它会生成三种数据格式：约会（Appt）、待办事项（Ttd）和联系人（Contact）。我们可以设计如下UML：通过CommsManager抽象类，我们可以生成所有具体的子公司（子类）。但实际上，这也在一定程度上说明了为什么有些企业在某些行业做不好。一旦他甚至间接插手子公司，也会影响到子公司的血统（我最开始接触的是吴军先生的《浪潮之巅》）。现实抽象类CommsManager{抽象函数getHeaderText();抽象函数getApptEncoder();抽象函数getTtdEncoder();抽象函数getConteactEncoder();abstractfunctiongetFootText();}classBloggsCommsManagerextendsCommsManager{functiongetHeaderText(){return"BloggsCalheader\n";}}functiongetApptEncoder(){returnnewBloggsApptEncoder();}functiongetTtdEncoder(){returnnewBloggsTtdEncoder();}functiongetConteactEncoder(){returnnewBloggsConteactEncoder();}functiongetCalnfootText(){regt\n";}}在这里，我们使用了工厂模式（最后的目录）。设计模式通常以这样一种方式协作，即一个模式的创建可以成为另一个模式的一部分。这个想法这方面来自于模型本身：它是在相同的条件下经过无数次的实践得到的最优解——如果以后有更好的条件，这个最优解还有优化的空间/或者不存在的。结果模式：将业务需求和实现细节完全分离，现在我们可以随意改变编码格式，不用担心业务层的bug；通过强制集成，所有Blogger格式的内容都通过Bloggercreator类处理实现，没有问题；当然，添加新产品很烦人，为了创建新产品的具体实现，我们必须修改抽象创建者，以及他的每个具体实施。PHP目前不强制方法的返回类型，这允许一些额外的灵活性。（强制返回类型，一般是JAVA等强类型面向对象语言）abstractclassCommsManager{constAPPT=1;常量TTD=2;const联系人=3；抽象函数getHeaderText();抽象函数标记（$flag_int）；抽象函数getFootText();}classBloggsCommsManagerextendsCommsManager{functiongetHeaderText(){return"BloggsCalheader\n";}functionmark($flag_int){switch($flag_int){caseself::APPT:returnnewBloggsApptEncoder();caseself::TTD：返回新的BloggsTtdEncoder()；caseself::CONTACT:returnnewBloggsConteactEncoder();}}functiongetFootText(){return"BloggsCalfooter\n";}}类的接口变得更加紧凑，但是也有一定的代价。我们放弃了详细的数据格式方式，而是集中化，客户无法确认自己需要的具体产品是否已经实现。所以，慎用哦~当你项目的产品越来越多的时候，创作者的数量也会变得臃肿。下一篇文章将介绍抽象工厂方法的一种变体：原型模式，可以减少创建类型的次数。面向对象的设计模式-目录
