其实我觉得出现这样的问题,一定是分析错了,分析错了那么即使重构也不能有很大的改观,除非换一种分析方案.小弟在下面将举例两种分析方案的不同,您可能有是曾相识的感觉.
就以Jdon论坛为例.A为客户,B为设计人员
第一种分析方案: 现有对象 ForumMessage.ForumMessageService
1A:我想发表消息Message以及删除Message
2B:这很简单,我们可以通过Service添加行或删除行来实现
3A:当Message已经被回复时,我们是不希望用户更改Message的,如果用户随意更改,那将会很混乱.而对于管理员我希望具有此功能.
4B:这个很简单,通过对Message增加判断是否被回复的属性,在进行修改时,只需要很简单的进行属性判断就可以实现您的期望.
5A:我还想知道最近发表的Message,以了解人们现在对什么话题最感兴趣.
6B:没问题,利用sql语句便可以办到.
最明显效果:
第3行所述的功能中,可以通过在service层进行判断是否是管理员和是否有回复进行解决.
第6行所述功能,可以通过在service中写查询最近消息的SQL语句进行解决.SQL语句可能有service层产生,也可能由特定的DAO接口产生.
第2种分析方案:现有对象ForumMessage,ForumMessageService
1A:我想发表消息Message以及删除Message
2B:这很简单,Service就具有这样的行为,它能够帮助我们解决。
3A:当Message已经被回复时,我们是不希望用户更改Message的,如果用户随意更改,那将会很混乱.而对于管理员我希望具有此功能.
4B:哦,您的会有多重的管理员吗?
5A:这就不太清楚了,我想以后会有吧.
6B:这样啊,我们引入一个叫Specifiaction的对象来解决这个问题.
7A:我还想知道最近发表的Message,以了解人们现在对什么话题最感兴趣.
8B:恩,我们通过引入一个叫SpecificMessageRecord,它知道人们现在对什么话题最感兴趣.
最明显效果:
第6行,发现需求可能会变更,引入一个规格来维护业务规则,当业务规则改变时,规格能够从容的面对.
第8行,以对象的风格来封装最近发表的Message,比用Service+sql语句来的更加内聚.
两者比较:
1方案已经遗漏了一些重要的业务规则,而这也业务规则通常是会变化的。2方案通过引入DDD中的规格检查便能轻松的面对变化,同时也将零散的业务规则用对象的方式进行封装。
1方案使用特定的SQL语句来解决最近消息记录,然而这样的方式使得模型表现效果不是很完善,客户的需求是根据特定的技术来解决的而不是领域,这会让我们付出一定的代价,当需求变更的时候. 但有时候使用这样的特定查询方式,往往又能达到效果.
需求变更设想:
A:我想知道最近发表的在一定的时间内消息回复量达到5时,进行置顶。还有在一天内Banq在此message进行3次回复时,想将此消息一红色效果显示,同时置顶;这样人们便能够轻松的找到并阅读人们最近最感兴趣的话题.
1方案应对措施:哇?嘿嘿,难不倒我,利用我在SQL语句的天分,能轻松解决此问题,您稍后.
2方案应对措施:SpecificMessageRecord能轻松的应对客户所提需求.
不同的分析方案得到了不同的领域模型,同时也对应着不同的解决方案,解决方案的不同,应对需求变化的能力也就不同.
小弟最近疲于找工作,深感求职难,几次面试都不成功(应届毕业生).闲暇之余思索面向对象的实施方式,以上分析难免片面或有所错误,望您指点一二、同时让小弟欣赏您的OO方案。