摘要:所以,也要慎用当你的项目中,产品越来越多,创建者的数量也随之臃肿,下一篇将介绍抽象工厂方法的变体原型模式,这种模式可以减少必须创建的类。
抽象工厂方法模式
在工厂方法模式中,我们通过中间件的方式,形成了以下格式的分离:
使用者
↓
创建者
↓
具体产品
这样,我们无论怎样修正具体产品,都不会影响使用者。现在,我们可以做出来一群小工厂,他们有各自的产品,但形成了模式层面的重复,那么我们如何化解这种重复呢?
在本篇,将通过抽象工厂方法模式——抽象 - 工厂方法 - 模式,来完成对小公司的整合,最初设计(母公司 - 子公司):
接下来,我们要通过抽象类解决多个业务并行的问题。
现在,我们要写一个PIM的数据格式解码器 - Personal Information Manage,会产生预约(Appt)、待办事宜(Ttd)、联系人(Contact)三种数据格式。
我们就可以设计出下列UML:
通过CommsManager抽象类,我们可以生成具体的所有子公司(子类)。
但事实上,这也一定程度的显示了为什么有些公司做不好某些行业,一旦他哪怕是间接介入子公司,也会影响子公司的血统(这个想法我最早接触于吴军先生的《浪潮之巅》)。
实现abstract class CommsManager { abstract function getHeaderText(); abstract function getApptEncoder(); abstract function getTtdEncoder(); abstract function getConteactEncoder(); abstract function getFootText(); } class BloggsCommsManager extends CommsManager { function getHeaderText() { return "BloggsCal header "; } function getApptEncoder() { return new BloggsApptEncoder(); } function getTtdEncoder() { return new BloggsTtdEncoder(); } function getConteactEncoder() { return new BloggsConteactEncoder(); } function getFootText() { return "BloggsCal footer "; } }
在这里,我们用了工厂模式(目录在最后)。设计模式之间经常这样协作,一个模式的创建,可以成为另一个模式的一部分。
这方面的想法就是源于模式本身:他是经过无数次同条件下,实践得出的最优解——未来如果有更好的条件,这个最优解就仍然有优化的空间 / 或者没有存在的。
结果模式的意义:
彻底的将 业务需求 与 实现细节 分割,现在,我们可以随意的改动编码格式,而不用担心业务层产生BUG;
通过强制整合,所有Blogger格式的内容,都通过Blogger创建者类来实现,不会出错;
当然,添加新产品则是令人苦恼的,为了创建新产品的具体实现,我们必须修改抽象创建者、和他的每一个具体实现。
PHP目前还没有强制规定 方法的返回类型,这产生了一些额外的灵活性。(强制规定返回类型,一般为JAVA之类的 强类型-面向对象-语言)
abstract class CommsManager { const APPT = 1; const TTD = 2; const CONTACT = 3; abstract function getHeaderText(); abstract function mark( $flag_int ); abstract function getFootText(); } class BloggsCommsManager extends CommsManager { function getHeaderText() { return "BloggsCal header "; } function mark( $flag_int ) { switch ($flag_int) { case self::APPT: return new BloggsApptEncoder(); case self::TTD: return new BloggsTtdEncoder(); case self::CONTACT: return new BloggsConteactEncoder(); } } function getFootText() { return "BloggsCal footer "; } }
类的接口变得更加紧凑,但也有一定的代价,我们放弃了详细的数据格式方法,而是将其中心化了,客户无法确认是否实现了需要的具体产品。
所以,也要慎用~
当你的项目中,产品越来越多,创建者的数量也随之臃肿,下一篇将介绍抽象工厂方法的变体:原型模式,这种模式可以减少必须创建的类。
面向对象设计模式 - 目录
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/22580.html
摘要:工厂方法模式面向对象的设计强调抽象类高于实践,尽可能的将代码设计的一般化,而非特殊化也就是降低耦合,提升标准性。于是,前辈们便设计了特定类处理实例化的工厂方法。实现这个时候我们引入工厂方法模式,设置类创造者,类产品,。面向对象设计模式目录 工厂方法模式 面向对象的设计强调抽象类高于实践,尽可能的将代码设计的一般化,而非特殊化——也就是降低耦合,提升标准性。于是,前辈们便设计了特定类处理...
摘要:原型模式平行的继承层次使用工厂模式在大型设计中,必须去维护大量的产品类。上文中,称之为特殊的耦合在这里我们介绍一种其抽象工厂模式的变体原型模式。面向对象设计模式目录 原型模式 平行的继承层次使用工厂模式在:大型设计中,必须去维护大量的产品类。(上文中,称之为特殊的耦合) 在这里我们介绍一种其抽象工厂模式的变体:原型模式。它使用clone关键词,来复制具体产品类,使得具体产品类能完成自我...
摘要:我们今天也来做一个万能遥控器设计模式适配器模式将一个类的接口转换成客户希望的另外一个接口。今天要介绍的仍然是创建型设计模式的一种建造者模式。设计模式的理论知识固然重要,但 计算机程序的思维逻辑 (54) - 剖析 Collections - 设计模式 上节我们提到,类 Collections 中大概有两类功能,第一类是对容器接口对象进行操作,第二类是返回一个容器接口对象,上节我们介绍了...
摘要:面向对象设计的五大原则单一职责原则接口隔离原则开放封闭原则替换原则依赖倒置原则。主要是针对继承的设计原则,继承与派生多态是的主要特性。 面向对象设计的五大原则:单一职责原则、接口隔离原则、开放-封闭原则、替换原则、依赖倒置原则。这些原则主要是由Robert C.Martin在《敏捷软件开发——原则、方法、与实践》一书中总结出来,这五大原则也是23种设计模式的基础。 单一职责原则 Sin...
阅读 1209·2019-08-30 15:55
阅读 956·2019-08-30 15:55
阅读 2153·2019-08-30 15:44
阅读 2884·2019-08-29 14:17
阅读 1132·2019-08-29 12:45
阅读 3303·2019-08-26 10:48
阅读 3134·2019-08-23 18:18
阅读 2601·2019-08-23 16:47