包图+设计模式？

    最近开工了机房收费系统重构版，确实是有点纠结。

    因为这一次是完全应用面向对象的思想设计程序。虽然之前学习了很多次面向对象编程，但是到实际应用的时候，还是会感到无从下手。纠结也没用，因为生活还在继续。。

    机房收费系统，先从UML建模开始说起，刚刚画完包图和用例图，现在在头疼类图，说到类图,那真是无所适从，怎么抽象出类?添加什么属性?应该有什么方法?类直接又改怎么联系?等等肯定不能像第一次画图那样胡扯…没关系只要去做，所有的问题都不是问题！

 

    说到包图，虽说包图比较简单，心里也明白要按照刚学的三层思想来设计包图，但是具体怎么做呢？还是不懂，通过查阅资料稍稍了解了一些：

            

    这就是机房收费系统的三层包图。多么简单挺清晰！

但就是如此就可以了吗？

    答案是　Ｎo！

    我们都知道包图，体现的是整个系统的架构，而系统的架构应该是相对稳定的,或者说能够良好的适应变化的.因为架构一变,代码必定伤筋动骨!这样就会导致成本上升、工期延长。这种结果我们肯定不愿看见。那么怎么才能隔离或者掌控这种变化呢？

    上个月刚刚学习了《大话设计模式》，设计模式一共有23种；根据模式的应用目的，又将它们分为3 类：创建型、结构型和行为型。回顾一下。另外在课本的第１４页，我发现了这么一句话“重要的不是你将来会不会用到这些模式，而是通过这些模式让你找到“封装变化”，“对象间松散耦合”，“针对接口编程”的感觉，从而设计出以维护，易扩展，易复用，灵活性好的程序。”仔细想想“对象间松散耦合”，“针对接口编程”的目的也是为了封装变化，所以设计模式的作用则可以概括为四个字：“封装变化”

    这个作用正好和架构设计的难题“隔离变化”有点一拍即合的感觉。当然事实也正是如此，设计模式可以封装变化，帮助架构“未雨绸缪”。

    总的来说：要让设计的架构能适应变化，就是要预见组件之间的交互接口和编码实现将来可能发生什么变化，并对此做出正确的决策：采用正确的设计模式去封装变化。

 

在机房收费系统中的体现：

    如图是加入设计模式后的包图，IFactory（抽象工厂）和ＩＤＡＬ（ＤＡＬ的接口）是为了预防数据库的变更。

Ｆａｃａｄｅ（外观模式）是为了Ｕ层和Ｂ层松耦合。

    大家可能会有疑问：程序中用到的设计模式都要体现在包图上吗？

    答案是：Ｎｏ！

    实际上我在构思重构版的时候还考虑到了应用策略模式和状态模式。但是为什么没有添加到上图中呢？这还要考虑这些模式的实际应用。策略模式的作用是封装算法，让算法的变化不影响使用它的客户。而这些算法逻辑都放在ＢＬＬ层（业务逻辑层）所以策略模式可以作为包ＢＬＬ的一个子包而存放其中，不存在调用关系。

 

    说到调用关系，这也是包图的一个非常重要的地方。包之间是否存在调用关系，以及调用的方向都需要我们仔细的斟酌。

 

    包图就先说到这吧，第一次学习包图的时候，怎么没发现原来包图也有这么大的学问！循循渐进没发现的还有很多。。。