上节写到了UML中的类图:UML从需求到实现---类图(1)

写完以后总觉得写的不够详细.里面很多细节没有说到.一篇文章就把强大的面向对象的类说完.当然是不可能的.这次我再补充一些关于UML中类图和类的思想.供大家参考

一:DAL层为什么不把它直接分成增,删,改,查四个类

其实很多人开始的时候都是这样想的.把它设置成这四个类不是很好吗.简单.不用在那么多类中找来找去.最让人感觉不错的地方就是在画UML时序图的时候.很是简单.基本上所有的图都是一样.

首先说.这样的分类对于系统来说是可以实现的.只是每个类中有很多的方法.比如查找这个类.里面对于每一个表的查找都要出现几个方法.

但是这样做违反了一个很重要的软件设计原则:开闭原则

开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改 
当把DAL层设计成四个类的时候.比如我们要增加一张表, 或者一个功能.我们只有去修改原来的类.这样显然违反了开闭原则.如果我们把每一张表都对应一个类.这样我们再增加一个表的时候.只需要增加一个类就可以了.

面向对象的核心就是封装.装起来以后就把它看作一个整体.不要轻易去改动它.只能来复用它.这样才是可复用的软件设计.

二:同层之间尽量不要相互调用.模块与模块直接也尽量不要交叉调用

我们分层的目的就是为了减少模块与模块之间的耦合.在层与层之间.尤其是bll层和dal层之间.一般是不相互调用的.也不去交叉调用.

这个就像是*的部门.你*部的人不能随便调用我财政部的人.你只要做好的你地任务就好了.但是如果一个部门需要另一个部门的功能怎么办?比如我*部需要一个管理财政的?

很简单.你*部也设立一个下属的财务部门就解决了.这样看起来比较重复.其实分层设计很多代码都是重复的.但是大量的重复换来了以后的方便.

这个就像是我们设计类一样.如果一个模块需要另一个模块的功能.比如我结账要查询,充值也要查询.你可以在bll中设立两个查询去解决.坚决不要调用bll的一个查询.

任何事情都有特殊.如果一个部门实在是解决不了怎么办?那么只能麻烦我们的老大.也就是顶层UI来.让他来调用另一个窗体.或者页面去解决.这个就可以交叉调用.

这是两个对UML分层和类的补充.希望对大家有用.

转自：http://blog.csdn.net/lsh6688/article/details/6301144