.Net与设计模式
第一章
一、设计模式的精髓之一是将可变部分封装为对象,带来的好处是系统更加灵活,易于维护,但也大量增加了对象。如果不恰当地使用设计模式,会使系统难以调试。
二、测试难度加大,由于对象的增多和对象间关系的复杂,因此测试例的设计难度增大,特别是很逻辑上的错误可能由装配关系不当造成,并且在编译时很难发现。解决测试难度大的方法是将测试用例文档化,即绘制测试用的对象图。
三、当你的项目发现有如下问题之一时,就需要考虑重构代码,可能会有某种模式适合:
(1)代码无法进行单元测试。
(2)需求的变动总是导致代码的变动。
(3)有重复代码存在。
(4)继承层次过多。
(5)隐藏的依赖过多。
总结:为了合理地使用模式,需要深入理解模式。模式不仅仅是解决方案,在使用模式时不能仅将注意力放在模式如何实现上,更重要的是理解模式存在的上下文及相关的“作用力系统”。由于设计模式没有明确指出这两个部分内容,所以要真正领会在问题、动机和实现中隐含的相关思想。
模式的使用即有好的效果,也会付出一事实上的代价。就设计模式来说,对象增加及对象关系复杂是得到好处的代价。
总之,设计模式不是万能的,不能指望设计模式的使用能提高开发的速度,或者项目的形象进度。
最后学习设计模式的最佳途径就是编程,动手实践。有很多设计模式的非软件实例,这些实例可以帮助理解设计模式,但也可能会误导。
第二章 UML与设计模式
|
二、Pro1是public属性,在UML中前面用“+”修饰。
Pro2是protected属性,在UML中前面用“#”修饰
Pro3是private属性,在UML中前面用“-”修饰.
在UML中抽象方法用斜体表示。
三、对象图描述的是对象之间的关联关系,在描述动态模型和构成测试用例,
对象非常有用。应当注意的是,有时系统的类图并不复杂,但对象图却很复杂。
第三章 面向对象软件设计的目标、原则和难点
一、设计的目标是完成需求所规定的任务,包括功能按照权利要求和性能指标,当然,这是最基本的目标。针对相同的需求,可以用很多不同的途径来实现。目前的开发速度、可理解的程度和软件的可维护性等因素是经常需要考虑的。
二、实际上,软件设计的目标是要保证在满足需求的前提下(包括功能与性能需求),还要确保软件的可维护性。即在需求变化或演化时,并且能够很方便地扩充软件设计。城可预计的时间和成本范围内完成,而不需要推翻重来。
三、在设计时首先要考虑的不是形象进度,而是系统的可维护性如下:
(1) 可扩展性:有了新的需求,新的性能可以容易地添加到系统中,并且不影响现有的性能,也不会带来新的缺陷。
(2) 可修改性:系统某一部分的代码需要修改时不会破坏系统的现有结构,也不会影响到其他部分。
(3) 可替换性:可以将系统中的某些类替换为相同接口的其他类,并且各级系统不受影响。
开闭原则
一、“开-闭”原则指软件实体应当对扩展开放,对修改关闭和。即软件实体应该在不修改的前提下扩展,这个原则实际上为软件设计指明了目标。我们知道软件设计应该充分考虑软件的可维护性,即需求发生变化时软件结构能够灵活地适应这种变化。就评价软件的可维护性而方,“开-闭”原则提供了一个依据。实际上,设计模式的应用就是使软件的结构在某种程度上满足“开-闭”原则。
二、面向接口编程的优势如下:
(1)降低程序各部分之间的耦合性,使程序模块互换成为可能。这样客户无须知道自己使用的对象类型,只要对象有客户所期望的接口即可。并且客户也不需要知道对象是如何实现的,只要知道定义接口的抽象类。
(2)使软件各部分便于单元测试,通过编制与接口一致的模拟类,可以很容易地实现软件各部分的单元测试。从而提高软件的可靠性,降低错误率。
(3)易于实现软件模块的互换,软件升级时可以只部署发生变化的部分,而不会影响其他部分。
三、程序中任何可能发生变化的部分都可以封装为对象,包括命令、事件、属性、算法和状态等。封装变化是实现“开-闭”原则的重要手段,也是在设计中发现对象的重要途径。因此在分析需要时,一定要注意什么是不变的,什么是可能发生变化的,心脏这些可能的变化会对封装带来的影响。
本文转自Sam Lin博客园博客,原文链接:http://www.cnblogs.com/samlin/archive/2008/01/13/1037397.html,如需转载请自行联系原作者