开工了机房收费系统重构版，确实是有点纠结。
由于这一次是全然应用面向对象的思想设计程序。尽管之前学习了非常多次面向对象编程。可是到实际应用的时候，还是会感到无从下手。纠结也没用，由于生活还在继续。。
机房收费系统，先从UML建模開始说起，刚刚画完包图和用例图。如今在头疼类图。说到类图,那真是无所适从，怎么抽象出类?
加入什么属性?
应该有什么方法?
类直接又改怎么联系?等等肯定不能像第一次绘图那样胡扯…没关系仅仅要去做，全部的问题都不是问题！
说到包图。虽说包图比較简单。心里也明确要依照刚学的三层思想来设计包图，可是详细怎么做呢？还是不懂，通过查阅资料稍稍了解了一些：
这就是机房收费系统的三层包图。多么简单挺清晰！
但就是如此就能够了吗？
答案是 Ｎo！
我们都知道包图，体现的是整个系统的架构。而系统的架构应该是相对稳定的,或者说可以良好的适应变化的.由于架构一变,代码必然伤筋动骨!这样就会导致成本上升、工期延长。这样的结果我们肯定不愿看见。那么怎么才干隔离或者掌控这样的变化呢？
上个月刚刚学习了《大话设计模式》，设计模式一共同拥有23种。依据模式的应用目的，又将它们分为3 类：创建型、结构型和行为型。
回想一下。另外在课本的第１４页。我发现了这么一句话“重要的不是你将来会不会用到这些模式，而是通过这些模式让你找到“封装变化”，“对象间松散耦合”，“针对接口编程”的感觉。从而设计出以维护，易扩展。易复用，灵活性好的程序。
”细致想想“对象间松散耦合”，“针对接口编程”的目的也是为了封装变化。所以设计模式的作用则能够概括为四个字：“封装变化”
这个作用正好和架构设计的难题“隔离变化”有点一拍即合的感觉。当然事实也正是如此。设计模式能够封装变化。帮助架构“未雨绸缪”。
总的来说：要让设计的架构能适应变化，就是要预见组件之间的交互接口和编码实现将来可能发生什么变化，并对此做出正确的决策：採用正确的设计模式去封装变化。
在机房收费系统中的体现：
如图是增加设计模式后的包图，IFactory（抽象工厂）和ＩＤＡＬ（ＤＡＬ的接口）是为了预防数据库的变更。
Ｆａｃａｄｅ（外观模式）是为了Ｕ层和Ｂ层松耦合。
大家可能会有疑问：程序中用到的设计模式都要体如今包图上吗？
答案是：Ｎｏ！
实际上我在构思重构版的时候还考虑到了应用策略模式和状态模式。可是为什么没有加入到上图中呢？这还要考虑这些模式的实际应用。策略模式的作用是封装算法，让算法的变化不影响使用它的客户。而这些算法逻辑都放在ＢＬＬ层（业务逻辑层）所以策略模式能够作为包ＢＬＬ的一个子包而存放当中。不存在调用关系。
说到调用关系，这也是包图的一个很重要的地方。包之间是否存在调用关系，以及调用的方向都须要我们细致的斟酌。
包图就先讲到这吧，第一次学习包图的时候。怎么没发现原来包图也有这么大的学问！
循循渐进没发现的还有非常多。
。
。
版权声明：本文博客原创文章，博客，未经同意，不得转载。