谈架构中接口的定义
不知道有没有朋友在项目一开始设计的时候会有一种迷茫感,不知道从何处下手,也许大家都知道好的设计需要先定义接口,往往是从一个很高的层次上去审视一套系统,这种做法我并不反对,但是我感觉这样做似乎需要很高的水平,很多设计者在定义完自己的接口以后都会有一种定义了和没有定义感觉一样,还不如直接写类来的实在呢,为什么会这样呢?原因很简单,缺乏设计经验,自己虽然站在很高的层次去思考,但是细节往往忽略了很多,甚至压根就没有考虑过细节,所以定义出来的接口要不就是太过抽象以至于实现的时候不容易实现,和EJB的设计初衷犯了同一种错误,也许压根就没有抽象,这样就和没有定义接口一样,不能够很清楚的定义系统的边界,在以后的开发中常常会对现有的设计进行修改,这样就破坏了原来的设计初衷,形成一种恶性循环,说了一堆废话只是为了总结一下一般的情况和找到问题的关键点。下面我来说一下我对项目初期设计的一些方法,抛砖引玉,希望更多的人能够分享一下自己的经验,同时希望能够分享一下自己在实际当中是如何去做的。
我认为软件设计其实不能离开细节,但是也不能过多的去深究细节,那么我说的细节到底细到何种程度呢?我自己的做法是细到类的方法上,开始在设计接口的时候不要过于从高端去设计,这样容易忽略很多细节,太理想化了,等到实现的时候会有很多不合适的地方,也许有人会考虑可以使用适配器模式去改变接口啊,这确实是一种方法,但是有的亡羊补牢的意思,一般只有开始没有考虑过的接口才会用适配器模式,如果一开始就设计为什么不一开始就避免这种情况呢?我认为一开始设计的时候一定要多定义接口,画出类图来,近可能的去覆盖系统的所有功能,细到对每一个对象模型的操作,不用多想尽管去定义,去设计,这样肯定会有很多地方重复,好了,如果感觉定义的差不多了,感觉确实没有什么可以继续定义的了,这时候可以停下来开始下一个阶段了。
现在可以把笔放下,整理一下每一个接口,找其功能相同或者可以合并的方法,去抽象出一个父接口,把能够公用的方法提出来。这样一次一次不断的迭代,最终你会发现越看越顺眼,当然我指的接口不是interface定义的,也可以是一个类或者抽象类,也许有人会提出疑问,那这样定出来的接口系统能够扩展吗?我的回答是在这个领域范围内的一般可以扩展,超过这个领域范围,我还是劝你设计另外一套子系统,谁规定系统扩展一定必须是在代码上扩展。也可是以子系统的方式来扩展,这样某些子系统很多情况下也是可以复用的,举例,Auth,cache,甚至是client与server都可以设计成一个子系统,client与server一定是需要以对象作为载体的吗?xml难道就不行?接口这个东西很有多含义,有些只可意会,无法言传。
以上只是我的一点经验和想法,我很希望各位道友能够给我提出意见,有没有更好的方法,也希望大家能够发表一下自己的方法。
[该贴被zzxsky1986于2010-04-27 22:46修改过]