在以前的一片博文里 http://www.cnblogs.com/mightofcode/archive/2012/11/19/2771216.html,我发表了我对设计模式的一点看法
但是今天的一个案例又让我对设计模式又有了一点思考
今天在处理这么一个问题:
组件A是我以前写的,这个组件会不断被重用,而今天要写到的模块B用到了A,现在B有一个很奇葩的需求,A似乎满足不了了!,怎么办?!
首先我想到的是能不能把问题简单化,绕过这个问题
经过仔细的分析后,我的结论是:没法绕过去,只能硬上了,给A添加功能!
在思考这个这个功能怎么在A中实现的时候,我发现这里面的逻辑很复杂,而且很特殊,后来看A代码的人一定看不懂为什么会有这个功能,这个功能也不大可能在以后被用到
其中由于项目进度的关系,项目组让另一个同事来处理这个问题,于是我先去干别的
同事干完之后,我一看,坑爹了,这位同事没有理解需求,给A添加了一个不必要的功能,我果断又掉进了坑里,还得我来处理这个问题
我又试图给A添加功能,添加接口...
首先我想给A添加状态(以前A只有一种状态),在状态1下如何如何,状态2下提供B要的服务,这导致A里面密布if else,代码很难看
这个时候可以考虑用状态模式了,抽象出各个状态的区别,放到接口类里面,各个状态只要实现接口就好了,看起来很完美
但是! 这个状态2很难理解,也很难被复用,因为它完全是为了模块B的需求而做的,这个状态2很有鸡肋的感觉
其实可以用策略模式,这种情况下具体行为应该由外部注入,而以后A的用户根本不会接触到丑陋的状态2,只有B知道状态2(或者应该说是策略2)
以前看设计模式的时候我就不理解策略模式和状态模式的区别,书上有讲,但是语焉不详,说不到重点
下面整理一下我的理解:
组件A承担一定的职责,这个职责要处理很多种功能,而这些功能分为两类,常用的,不常用的
不常用的功能甚至在需求分析的时候都不会被考虑到
常用的功能可以做成状态模式,那么组件A的代码将会非常清晰,这些代码也将是非常稳定的
不常用的功能由于无法预知,应该抽象出接口(这个接口可能具体需求来了才能确定),具体实现由外部注入,保持组件A的简单
可以想象,如果所有需求都放在组件A中实现,那么组件A很快就臃肿不堪,无法维护,但是组件A又必须实现那些常见的需求,这些需求可以抽象为状态,由组件A实现
这其实是一个职责的问题,可以重用的功能应该放到组件A中,不可以重用但是又依赖于A的职责可以由A提供一个接口,外部来注入
ps:不得不吐槽一下网上关于设计模式的文章,经常拿什么矩形正方形(众所周知这个例子有bug),各种动物(包括很奇葩的寓言),甚至唐僧孙悟空猪八戒(鄙视下闫宏的那本书,设计模式真的需要这么大一本书才能讲清楚吗?)做例子,我很怀疑这些东西真的能表现设计模式吗?