.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，如需转载请自行联系原作者
