"单一职责的核心思想:一个类,最好只做一件事情,只有一个引起它变化的原因",这句话简单,很容易理解.但是仔细想下去,如何真的要做到这点,的确不是一件容易的事情.有很多迷惑的地方,最先的时候,天真的认为这个原则只是为具体的每个方法制定的,终于有一天,认识升级了,一个类也是要单一的,但是类中有很多方法,属性.那么如何去做到单一呢?!
下面我们从一个简单的"产品发布DEMO"来分析下.
"有一个小型的贸易网站,客户的需求是可以将产品发布到网站中,并且可以让用户进行查看",这其实是一个很简单的需求,然后将这简单的需求在细化下:
1,新增,修改,删除产品
2,发布产品
3,查询产品
4,用户浏览产品
用户需求明确了,可以开始设计咯!怎么设计呢,
这样可以吧!产品对象和IProdBS产品的服务接口(对应与需求),好象没有什么问题,但是这个接口符合SRP吗?它是做一件事情吗?有多少因素可以引起它发生变化?这的确很难回答,因为站在不同的角度,对它的理解是不一样的.
业务角度的分析:
IProdBS是服务接口,面向的业务,所以对它需要站在业务角度上去分析.通过需求可以很清楚它们业务之间的关系,如下图
通过图大家就很清楚的了,因为产品的使用者有系统用户和客户,在这业务多变的世界里,如果把这两个不同使用者的业务放到一个接口里面,那这个接口的稳定性更定不好.所以我们把它分开吧,系统用户操作的接口IProdBSForSystem,客户操作的接IProdBSForCustomer.最终的设计如下:
数据库角度的分析:
数据库中有一张产品的数据表,所以我需要的接口只是对这张表进行操作,引起接口改变的因素只有当数据表发生变化的时候,我才需要去修改接口.所以我可以这样去设计它
以上是站在业务和数据库的角度上去对产品操作接口的划分.可能有时候你会认为这其实是个简单的编码，弄那么复杂干嘛!的确,但是如果你的业务够复杂,并且还需要不断扩展和维护的话,你应该让你的设计和代码符合这个原则.我一直都在一个类下有N个方法,几千行代码的类中工作,深刻体会到SRP的必要性......
软件设计根本就没有一个标准,所以设计的对或错就很难评判,不同的分析角度做出的设计都是不同的.当你开始进行设计的时候,首先一定要找到自己的角度,就像 "你建了一个房子,然后问别人,我这房子设计的好吗?!可是,你又没有告诉这房子是要作为标志性建筑,居名建筑,或是工厂".选好角度后,再去设计吧.你可以把你的软件分成不同的角度去设计(以业务为中心,数据库为中心,或者两者都加上),你想怎么样都行... 呵呵!但是一定要符合设计原则呀,首先的就是"SRP(单一职则)"...,
写完了,大家可以拍砖了,不过千万别拍死我了......
