设计模式笔记 24. 设计模式总结

 

设计模式总结

7 月初的一个周末，准确的说应该是7 月1 号周六，在网上看到一本《大话设计模式》的书，而且看到很多很好的评论，于是乎，下载了电子书看看，一下子看了几章之后，对设计模式有了个了解，于是继续上网搜些其他资料，进一步了解设计模式。。。最终结论：设计模式是个好东西，具体怎么好，一两句话是无法概括的，也是从那天起，我就决定学习设计模式，于是就看《大话设计模式》，至七月十多号，大概看了一百多页后，感觉有点难，有点看不下去的感觉，于是上网找其他的好方法，无意间发现了李建忠老师的《C# 设计模式纵横谈》系列讲座，微软的Web Cast 课程，主要讲解GOF 的23 个设计模式，每个一讲，加上一头一尾，共25 讲，试听了一节课后，感觉很有用，于是就抽时间去边听课边看书，并在我的博客里写下笔记，依赖加深印象，二来可以督促我的进度。。。

三个月以来，总算把设计模式学完一遍了，原计划是两个月学完（一星期三个模式），由于。。。计划两个月学完实际花了三个月，感触多多，收获多多——对C# 语言有了更进一步的认识，对OO 的思想有了更全面的了解。。。

下一步在设计模式方面的计划：巩固并运用设计模式，巩固：把《大话设计模式》，《.Net 设计模式》，《设计模式——可复用的面向对象基础》，《敏捷软件开发：原则、模式与实践》这些书再结合起来系统的看一看，当然还会去买一些我手头上没有的关于设计模式的书；运用：部门前几天也提倡用C# 来改版VB 程序，我想这是一个很好的平台，正好有机会把理论的东西在实际中应用，理论加实际——唯一的学习方法。。。

下面对各个模式再简单总结一下：

 

1、 创建型模式：

Singleton ：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了Singleton 之外，其他创建型模式解决的都是 new 所带来的耦合关系。

 Abstract Factory ：创建一系列相互依赖对象，并能在运行时改变系列。

Factory Method ：创建单个对象，在Abstract Factory 有使用到。

Prototype ：通过拷贝原型来创建新的对象。

Factory Method ，Abstract Factory, Builder 都需要一个额外的工厂类来负责实例化“一边对象”，而Prototype 则是通过原型（一个特殊的工厂类）来克隆“易变对象”。

如果遇到“易变类”，起初的设计通常从Factory Method 开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Factory Method ，Abstract Factory, Builder ）。

 

2 、结构性模式

Adapter ：注重转换接口，将不吻合的接口适配对象，用于旧代码复用、类库迁移等。

Bridge ：注重实现抽象和实现的分离，支持对象多维度的变化。

Composite ：注重同意接口，将“一对多”的关系转化为“一对一”的关系，屏蔽对象容器内部实现结构，实现对象和对象容器使用的一致性。

Decorator ：注重稳定接口，在此前提下为对象扩展功能，实现对象功能的扩展，避免子类膨胀。

Facade ：注重简化接口，屏蔽各子系统的复杂性，提供更高层接口供客户访问。

Flyweight ：注重保留接口，在内部使用共享技术对对象存储进行优化（通过共享大量细粒度对象，提供系统性能）。

Proxy ：注重假借接口，通过增加间接代理，实现更多控制，屏蔽复杂性。

 

3  、行为型模式

Template Method ：封装算法结构，定义算法骨架，支持算法子步骤变化。

Strategy ：注重封装算法，支持算法的变化，通过封装一系列算法，从而可以随时独立于客户替换算法。

State ：注重封装与状态相关的行为，支持状态的变化，通过封装对象状态，从而在其内部状态改变时改变它的行为。

Memento ：注重封装对象状态变化，支持状态保存、恢复。

Mediator ：注重封装对象间的交互，通过封装一系列对象之间的复杂交互，使他们不需要显式相互引用，实现解耦。

Chain of Responsibility ：注重封装对象责任，支持责任的变化，通过动态构建职责链，实现事务处理。

Command ：注重将请求封装为对象，支持请求的变化，通过将一组行为抽象为对象，实现行为请求者和行为实现者之间的解耦。

Iterator ：注重封装特定领域变化，支持集合的变化，屏蔽集合对象内部复杂结构，提供客户程序对它的透明遍历。

Interpreter ：注重封装特定领域变化，支持领域问题的频繁变化，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。

Observer ：注重封装对象通知，支持通信对象的变化，实现对象状态改变，通知依赖它的对象并更新。

Visitor ：注重封装对象操作变化，支持在运行时为类结构添加新的操作，在类层次结构中，在不改变各类的前提下定义作用于这些类实例的新的操作。

 

正确对待模式：

设计模式建立在对系统变化点的基础上进行，哪里有变化，哪里就应用设计模式。

设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能准确定位。

不能为了模式而模式，设计模式是一种软件设计的软力量，而非规范标准，不应夸大设计模式的作用。

 

2009-02-05：

大话设计模式读书心得：——公司部门去年十月份成立读书会，学习设计模式，现要求写读书心得。

从一开始学习设计模式至今已半年有余了，第一次接触设计模式是一次不经意间在网上看到《大话设计模式》一书，看了前言了第一章后，就感觉到其诱惑力对于一个程序员来说，是无比巨大的。大概是去年十月份的时候，部门决定成立读书会，系统学习设计模式。

通过学习设计模式，除了学习到“一些设计模式”，还让我进一步熟悉、巩固了面向对象思想，进一步熟悉了C#语言。。。我曾多次设想，我们如果引入面向对象思想，并结合设计模式来重写或改善我们的系统（必须重写，虽说设计模式只是一种思想，语言只是实现而已，但是选择一门好的语言，无疑也是非常重要的，而VB6在面向对象方面却有很大欠缺甚至不具备其条件），那么我们的系统将会像目前一样需要那么多人来维护吗？

《大话设计模式》一书其实是对GOF的《设计模式——可复用面向对象软件的基础》一书的“翻译”，让人更容易理解，用通俗易懂的语言阐述软件设计过程中的一些“模式”，在某种特定环境下，用最好的设计方法（代码高内聚，低耦合，使其有良好的可扩展性和可维护性）达到我们的目的，或许其方法有很多很多，但是寻找到最好的方法却不是件容易的事，设计模式是对前人的设计经验的一个总结，告诉我们在某种特定的环境下，这样的设计师最好的，学习设计模式有助于我们在设计软件的过程中少走很多弯路。

我对GOF的23个设计模式虽然都有看过，但是只有理解，实现，应用及思考之后，才能真正体会其精妙之处，至今体会较深的有以下几个模式：1. Strategy——封装系列“算法”，让它们之间可以相互替换，“算法”并不是单指数据结构中的算法，在实践中，它几乎可以封装任何类型的规则，这使得策略模式的运用极其广泛；2. Template Method——有人说是用的做多的模式，只要有抽象类的地方，都可以看到这个模式，它通过把不变行为移到父类中去，去除子类中的重复代码，从而提供了一个很好的代码复用平台；3. Facade——提供了对基础架构的统一访问，减少复杂性，在Web编程者中的三层架构，就是此思想，每一层都封装好一部分功能，提供给上一层统一的方法调用，整个Framework体系就是Facade模式的封装，随着1.0升级到3.5，越来越多复杂的高级功能被封装，可以说Facade无处不在；4. Abstract Factory——提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类，咋一看，太抽象了，说个例子，在三层架构中，BLL层对DAL层的调用会直接用到DAL层中的类，如果DAL层是分别对SQL Server，Oracle的访问，BLL层需要根据实际情况决定实例化哪一个DAL层中的类，我们又希望在两种DAL层切换时，BLL层和UI层都不做改变，那么可在BLL层和DAL层中增加接口层（体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现）和抽象工厂（DALFactroy），让它来实例化DAL层中的实例；5. Singleton——确保一个类仅有一个实例，并提供一个访问它的全局访问点，如单件窗体，点一下Menu，弹出一个窗体(实例)，在关闭这个新窗体之前，再次点击该Menu，不会再次出现同样的弹出窗体(实例)。。。篇幅有限，其他模式或多或少都有点感觉。

最后，引用《设计模式解析》书中的一句话：设计模式体现的是一种思想，而思想是指导行为的一切，理解和掌握了设计模式，并不是说记住了23种（或更多）设计场景和解决策略（实际上这也是很重要的一笔财富），实际接受的是一种思想的熏陶和洗礼，等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开发，这一切才是最重要的。