流动的程序设计流程.docVIP

流动的程序设计：流程 baidic@yahoo.cn 面向对象的三板斧 主管要求小程设计一个简单的仓库，他毫不犹豫地选择了面向对象。 面向对象的程序设计该怎样进行呢？ 没错，正如教科书所讲：抽象、封装、继承…… 小程首先抽象出【货物】、【库房】与【保管员】三个对象，然后分别为它们封装属性和行为，结果大致如下： 货物属性： 货物 属性：名称 属性：位置 属性：数量 库房 属性：库存清单 行为：入库 行为：出库 行为：查找货物 行为：更新库存 保管员 行为：记录流水账 很简单嘛，已经可以开始使用了。 然而没过几天，保管员就开始抱怨：【库房】总爱偷懒！每次入库或者出库之后，他都得提醒【库房】去更新库存。如果一时疏忽了，他就不得不花费大量的时间去重新清点库存。这本来不就应该是【库房】的分内之事吗？ 唔，这个简单，修改一下【库房】的入库与出库，让它们去执行更新库存就行了。 没等小程松口气，主管又要求小程为每件货物增加一个条形码，以便根据条形码来识别货物。 这个就麻烦多了，需要给【货物】增加新的属性：条形码，同时给【库房】增加新的行为：识别货物，并修改所有既有的行为，以适用于条形码方式，而且要把这些变化告知保管员。 库房行为：识别货物 库房 行为：识别货物 行为：查找货物 …… 货物 属性：条形码 …… 小程正忙于修改程序，保管员又提出一个新点子：【库房】应该更勤快点，自动记录流水账，这样他就不用担心会遗漏流水账了。 还有，主管要求货物分类放置，方便以后拆分仓库…… …… 小程很快发现，【库房】的行为增加到了十几个甚至更多，保管员对此晕头转向，威胁说如果小程不改善仓库，他就跳槽…… 正当小程一筹莫展时，一个叫【工场】的家伙跳了出来，声称能改变这一切…… 使用工场 先来看看工场的名片： 工场 工场 行为：开工 其他对外保密 【工场】接着做自我介绍： 工场（理论上）只做一件事情或者一类事情； 工场只开放一个单向访问入口； 工场（理论上）是独立的，封闭的； 工场相对固定，不随入口数据的变化而变化； 唔，貌似很单纯又很神秘的一个对象。小程决定尝试从【工场】继承一个【库房工场】： 库房工场 库房工场 行为：开工 内部属性：库存清单 内部行为：入库、出库、查找货物、更新库存、识别货物…… 这下保管员开心了，他只需要告诉【库房】：来货物了，开工啦，或者，嘿，出库单来了，快开工……库房就会把所有的任务依次完成。 不过小程就比较郁闷了，他不得不对每一种情况进行判断，如果是货物，【库房】需要执行入库、贴条形码、更新库存、记录流水账，如果是出库单，【库房】需要出库、更新库存、记录流水账…… 而且，假如以后要添加一个行为，可能所有的流程都会受到影响……想一想小程就头大如斗……保管员开心了，他却更痛苦了…… 嘿，【工场】再次跳了出来，不要把流程放进【工场】里，那是另一个家伙【流程】的事情，【工场】只是用来做事情的。但是，一件事往往不是简简单单的一件事，所以，告诉你一个好消息： 工场具备动态执行自己的行为的能力； 工场按照预置流程（像一道流水线一样）智能运作。 智能工场 小程顿时来了兴致，怎么才能让工场智能运作？ 首先，需要设置预置流程，外部配置文件是个不错的选择： 库房工场 库房工场预置流程 货物入库：入库、贴条形码、更新库存、记录流水账…… 清单出库：出库、更新库存、记录流水账…… …… 默认流程：…… 这下轻松多了，入库货物来的时候，只需要把预置流程同时交给【库房】，由于它的动态执行能力，它就会像流水线一样从头执行到尾：入库、贴条形码、更新库存、记录流水账；出库清单来的时候也一样。如果没有找到合适的预置流程，它就会去执行默认路程。而且，如果以后需要更改流程，甚至不用修改设计，只需要修改预置流程就行了。更妙的是，如果不小心发现了以前留下的问题，小程可以悄悄的修改好，而不必让任何人知道。 不管小程增加、删除或者修改【库房】，在保管员看来，【库房】都没有发生变化，他再也不用为【库房】的频繁变更而上火了。 对此小程提出了一个新的想法：【库房】应该更智能点，只需要告诉它货物入库，它会自己找到预置流程并执行。 没错，这是一个非常棒的想法。由于【工场】的封闭特性，你有两个选择： 把预置流程作为必须的构造参数（记得保留一个默认流程）； 使用一种类似的方式：预置工场。 预置工场 单例模式你一定非常熟悉，无论你怎么创建或者获取对象，它总是一个静态的唯一的实体。这将非常适用于记录流水账一类的事情。 注意下面这个单例，看看它有什么不同： class class LogWork { # by PHP private static $ENTRY = null; public function __construct($flows = null){ if (! self: