很好,这的确看起来很简单,而且注重现在客户端代码不知道下一步状态项应该是什么状态。它只是调用了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/>
评论加载中…
![]() |