列表B
<h2>First, method explosion with separate methods for all actions and statues:</h2>
<cfset contentMethodExplosion = createObject('component','MethodExplosionContentItem').init() />
<cfset contentMethodExplosion.saveDraft() />
<cfset contentMethodExplosion.approveDraft() />
<cfset contentMethodExplosion.approveReview() />
<cfset contentMethodExplosion.approvePublishApproval() />
<cfset contentMethodExplosion.savePublished() />
<cfset contentMethodExplosion.approveDraft() />
<cfset contentMethodExplosion.rejectReview() />
<hr/>
<cfset contentMethodExplosion2 = createObject('component','MethodExplosionContentItem').init() />
<cfset contentMethodExplosion2.rejectReview() />
<cfset contentMethodExplosion2.saveDraft() />
<cfset contentMethodExplosion2.approveDraft() />
<cfset contentMethodExplosion2.approveReview() />
<cfset contentMethodExplosion2.rejectPublishApproval() />
<hr/>
从上面的运行看代码能够满足要求,它的确按照我们的要求运行。然而,对于它是如何工作的,存在几个问题。首先是拥有大量的方法,每个状态和行为组合对应一个方法。我们要有saveDraft(), savePublished(), rejectReview(), rejectPublishApproval()等方法。假如这时你注重到这一点,不错因为我们应该注重。因为假如我们增加几个状态或行为,那么状态和事件组合将会呈指数级增加。三个状态和三个行为需要九个方法,四个状态和四个行为要有十六个方法等等。很明显,这不是一个可以升级的方案。
这还不是全部,还存在另一个问题,我们需要客户端代码(在本例中就是简单的测试模板)跟踪内容项的状态变化。假如失去状态跟踪,本该调用approveDraft()方法却意外调用了approvePublishApproval()方法,就会导致内容项进入错误状态,此时可能就会发生错误。
或者导致发布本不应该发布的内容项。要害问题是客户端代码本不应该跟踪内容项状态,它的状态应该有状态项自身维护。
第二种方案
由此看来,我们应该承认“方法爆炸”方案可能不是最好的,或许我们可以简化问题。
理想的情况下,我认为每个内容项只对一个更普通的行为请求做出反应。这将会使内容项需要的方法降低到三个:save(), approve(), and reject()。列表C所示是该方法的测试用例。
列表C
<h2>Next, using conditional logic in Content Item:</h2>
<cfset contentConditional = createObject('component','ConditionalContentItem').init('draft') />
Content item created in <strong>draft</strong>...<br/>
<cfset contentConditional.save() />
<cfset contentConditional.approve() />
评论加载中…
![]() |