利用ColdFusion组件实现状态模式

第二种方案

由此看来，我们应该承认“方法爆炸”方案可能不是最好的，或许我们可以简化问题。

理想的情况下，我认为每个内容项只对一个更普通的行为请求做出反应。这将会使内容项需要的方法降低到三个：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() />
<cfset contentConditional.approve() />
<cfset contentConditional.approve() />
<cfset contentConditional.save() />
<cfset contentConditional.approve() />
<cfset contentConditional.reject() />
<hr/>

<cfset contentConditional2 = createObject('component','ConditionalContentItem').init('review') />
Content item created in <strong>review</strong>...<br/>
<cfset contentConditional2.reject() />
<cfset contentConditional2.save() />
<cfset contentConditional2.approve() />
<cfset contentConditional2.approve() />
<cfset contentConditional2.reject() />
<hr/>

很好，这的确看起来很简单，而且注意现在客户端代码不知道下一步状态项应该是什么状态。它只是调用了approve（）方法，有内容项本身跟踪调用该方法后该如何做出反应，问题解决了。

但是还不能高兴得太早，我们的确简化了每个内容项的公共接口，并将跟踪状态的职责转移给了内容项本身。但是，我们又该为此付出什么代价呢？

列表D显示了这个版本的CFC代码，我要警告你，这个代码十分糟糕。看看这么多的逻辑条件。每调用一个方法，我需要对所有状态进行条件检查以确定该如何做出反应。并且，增加更多的方法或行为时仍旧意味着爆炸，只不过是一种不同类型的爆炸，在这种情况下，结果是条件语句的爆炸。

列表 D

<cfcomponent name="ConditionalContentItem" hint="I am a per-reqeust CFC that represents a Content Item, but does not use the State pattern.">
<cffunction name="init" access="public" returntype="ConditionalContentItem" hint="Constructor.">
<cfargument name="initialStatus" type="string" required="true" />
<cfset setStatus(arguments.initialStatus) />
<cfreturn this />
</cffunction>
<cffunction name="save" access="public" returntype="void" output="true" hint="">
<cfset var local = structNew() />
<cfif getStatus() eq 'draft'>
<cfoutput>
Status '#getStatus()#' saving content item...<br/>
</cfoutput>
<cfelseif getStatus() eq 'published'>
<cfoutput>
Status '#getStatus()#' setting the content to draft mode...<br/>
</cfoutput>
<cfset setStatus('draft') />
</cfif>
</cffunction>
<cffunction name="approve" access="public" returntype="void" output="true" hint="">
<cfset var local = structNew() />
<cfif getStatus() eq 'draft'>
<cfoutput>
Status '#getStatus()#' saving content item and alerting reviewer about content for review...<br/>
</cfoutput>
<cfset setStatus('review') />
<cfelseif getStatus() eq 'review'>
<cfoutput>
Status '#getStatus()#' alerting content author that content is approved...<br/>
Status '#getStatus()#' marking content as ready for publish approval...<br/>
</cfoutput>
<cfset setStatus('publishApproval') />
<cfelseif getStatus() eq 'publishApproval'>
<cfoutput>
Status '#getStatus()#' Marking content as deployed...<br/>
Status '#getStatus()#' Pushing live and updating content cache...<br/>
</cfoutput>
<cfset setStatus('published') />
</cfif>
</cffunction>
<cffunction name="reject" access="public" returntype="void" output="true" hint="">
<cfset var local = structNew() />
<cfif getStatus() eq 'review'>
<cfoutput>
Status '#getStatus()#' alerting content author that content is rejected...<br/>
Status '#getStatus()#' setting back to draft mode...<br/>
</cfoutput>
<cfset setStatus('draft') />
<cfelseif getStatus() eq 'publishApproval'>
<cfoutput>
Status '#getStatus()#' alerting reviewer that publishing is rejected...<br/>
Status '#getStatus()#' setting back to review mode...<br/>
</cfoutput>
</cfif>
</cffunction>
<cffunction name="getStatus" access="private" returntype="string" output="false" roles="" hint="I return the status.">
<cfreturn variables.instance.status />
</cffunction>
<cffunction name="setStatus" access="private" returntype="void" output="false" roles="" hint="I set the status.">
<cfargument name="status" type="string" required="true" hint="status" />
<cfset variables.instance.status = arguments.status />
</cffunction>
</cfcomponent>

这种方法可能比第一种方法好，但是我还是认为有太多的缺点。这就是为什么我们转向状态模式，看看是否能够有所帮助。