房间计费系统改造—三

  房间的改造基本完成。在中三比重建,被推翻后。七然后重建(外观和工厂)。再重构,来来回回用了一个月........

  重构机房从绘图画到一半就废弃了。由于对三层不熟。之后。做完了,才敢又一次拾起来画。绘图先从包图開始。宏观上有个了解:

(一)重构机房包图:



  先前画包图的时候,跟师傅交流。结果被一个师姐给笑话了,由于我觉得:它们各个层之间都是双向箭头的,后来才知道,箭头表示调用关系,B层仅仅能被U层或外观调用,B层不能调用U层,所以不存在双向箭头。大家注意。

  在我这次重构中是严格依照上面的图中来的。

  对于UI调用外观(Facade)或者UI层调用BLL层,都能够:

  UI调用外观:client不知道B层的存在,减少了与B层的耦合。一旦用户的需求有变动。仅仅改U层。加一个B层就能够了。

  UI调用B层:有些功能非常单一的,事实上能够直接UI层调用B层即可了。加上外观反而认为有多此一举了。

  大家重构度数自己把握就能够了。

 

(二)重构机房用例图

  关于用例图,我认为有两种分类的方法:

  第一种:能够依照功能来区分,功能依照大的能够分为三类:查询功能、维护功能、运算功能

  另外一种:能够依照角色来区分。角色能够分为三类:一般用户、操作员、管理员

  依照功能来划分举个简单的样例:运算功能:

  依照角色划分:

  在做第一次机房的时候,我们基本上就是依照角色来划分的。

  依照角色划分:简单直观,一个用例就是一个界面。而且从总体上我们整个设计非常清晰,宏观上也非常easy接受。

  依照功能划分:B层是依照功能划分的。这里假设你是依照功能划分的话,B层是非常easy就能够做成的。可是一定要注意不要越缠越乱即可。

  我是依照角色划分的。

 

(三)重构机房的类图

  以充值为例:


  这里两个ICard和IRecharge事实上是接口,为了与上面的七层的图回应,就这样画了。

  在类图中我们不难看出U层是依照界面划分的。一个UI为一个界面,外观层和B层是依照功能划分的,一个界面可能有非常多个功能,有相应一个外观和多个B层,B层的功能要细化。外观仅仅有一个。一个外观调用多个B层。U层仅仅知道外观不知道B层的细化功能。比方说充值(首先要推断卡号是否存在,推断充值金额是否低于最小金额,recharge表中加入数据。相应card表中cash字段的改动。)。充值仅仅有一个界面反应用户的需求,外观为一个,可是B层会有几个类分别为:查询card表、查询basicdata表、加入recharge表、改动card表。每个功能都是一个B的类,这样减少耦合。


  关于外观层,有几种说法:

  1、能够依照用例分,一个用例分为一个外观。有不同的返回值能够通过不同的function来实现,不一定一个外观就仅仅有一个function。

  2、能够依照用户的级别来划分,分别为:一般用户、操作员、管理员,是谁的功能就调谁的外观。

  无论是哪一种,我认为都能够。

 

  这里我想给大家提供几条线供大家思考:

  1、外观用用户级别划分,几个功能就有几个function。用一个function来调用B层的一个类(依照功能划分)。

  2、外观用用户级别划分,几个功能就有几个function。B层用表来划分,跟IDAL层分类同样,外观中的Function调B层的时候,可能要看清楚了。

  3、外观依照界面(用例)划分,一个外观几个function。B曾能够用表来分,也能够用功能划分。

  个人觉得前两种更好一点,由于通知200个人和通知100个人没有什么差别,要是能实现通知10个人不就省了非常大的力气了吗?

  

  我们划分三层实际上就是解耦和,大家能宏观上不要脱离了这条主线就能够了,如何做,给自己一个说法,说的过去即可了。





版权声明:本文博主原创文章。博客,未经同意不得转载。

原文地址:https://www.cnblogs.com/gcczhongduan/p/4850928.html