设计模式解析读后感10篇
《设计模式解析》是一本由ALAN SHALLOWAY / JAMES R.TROTT著作，人民邮电出版社出版的16图书，本书定价：45.00元，页数：296，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《设计模式解析》读后感(一)：设计模式入门最佳书籍
如果你认为GOF的经典名著《设计模式》太晦涩难懂，《Head First Design Pattern》又太不技术书籍了，那么这本《设计模式解析》非常适合你！这本书每章结束时都有小结和启发性复习题，可以帮助你更好地了解自学得如何了。本书只介绍了几种比较常用简单的设计模式，因而在学习过程中会很有成就感。（额，这番言论真像是书托）
发现设计模式相关的书籍都是先讲OOP设计思想然后再引入设计模式，有空的话就会顺带讲解下敏捷开发、重构，这几种编程方法论之间真是关系紧密呀。
书摘：
1， 功能分解，分而治之
2， 找到变化并封装之
3， 抽象、封装、多态、继承
4， 对象组合优于类继承
5， 针对接口编程
6， 高内聚、低耦合
7， 模式就是“在某一背景下某个问题的一种解决方案”，作用：复用解决方案、确立通用术语。
Facade模式
为子系统中的一组接口提供一个统一接口。Facade模式定义了一个更高层的接口，使子系统更加容易使用。
Adapter模式
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使原本由于接口不兼容而不能一起工作的类可以一起工作。
trategy模式
定义一系列的算法，把他们一个个封装起来，并且使它们可相互替换，Strategy模式使算法可独立于使用它们的客户而变化。
ridge模式
将抽象与实现解耦，使它们可以独立变化。
Abstract Factory模式
为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。
Decorator模式
动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式比生成子类更为灵活。
Observer模式
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并自动更新。
Template Method模式
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。不改变算法的结构而重定义它的步骤。
ingleton模式
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
Factory Method
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。
《设计模式解析》读后感(二)：模式在理解
遇到这本书是一个偶然的经历，但是很幸运他没有从我的指尖溜走。这本书，不是教科书，是思想的演进，是思想的讲述。很多人，在学习编程的时候，只是停留在传统教课书的水平，虽然做了很多年，但是无非就是理解了更多的API或者封装库，但是自己在编程的时候，思维水平仍然停留在初级，无法更加进一步的去前进。对于很多人，其实更多是跟谁高手，一起工作，渐近学习高手的思维方式，从而提升自己的。但是很遗憾，并不是每个公司都有高手，也并不是每个公司都有机会跟高手学习。这本书就是一个你身边的高手。
1.面向对象
作者对面向对象的理解，完全是从真正实用的角度在分析。对象就是职责体，封装是为了隐藏，而不仅仅是为了数据和行为的隐藏，可以是任何隐藏，继承是为了多太，本质也是隐藏，对象要求，“高内聚，低耦合“ 因此，需要注意的是，对象可以使用组合，去解决继承爆炸的问题。（这是标准面向对象的弊端），除此以外，因为有了组合，可以进一步做到”职责的单一“。
2.面向对象比较
标准面向对象分析：问题域中寻找”名词“创建类，寻找”动词“创造方法，另外，利用名词创建继承。（造成了继承爆炸）
新的对象分析方法：寻找”职责“创建类，具体方法为职责的执行内容即可。另外，”利用变化创建封装，利用共性创建概念类，概念类包含可变类“
模式的推演方法：（上述话的更进一步理解）
1） 寻找变化，并将它封装在一个单独的类中。
2） 将这个类包含在另一个类中。
3.问题域的分析方法
1） alexgender的方法，也是建筑学方法，步骤：
. 需要解决的问题域有哪些，哪些模式可以解决
c. 设计模式的背景推导关系。
2） CVA分析法，也叫做 共性与可变性分析，步骤：
a. 领域内有哪些概念
. 概念的共性和可变性有哪些
d. 不同概念之间的关系
3） 矩阵分析的方法，步骤：
. 每一个问题，确定具体概念
c. 罗列所有问题，形成概念矩阵
d. 行使用模式实现，列是具体实现
e. 模式之间的关系
4. 以 设计模式的思想 从事开发：
2）不同模式之间的组合或者说，不同模式之间的关系。
5. 其他模式的讲解，感觉就有点凑数了。但是还是有几个思想很好的：
1） 工厂方法，实现了”使用“与”创建“的隔离
2） 桥接模式，其实现了”概念“与”实现“的隔离
《设计模式解析》读后感(三)：设计模式解析
优秀代码的目标：
* 高效
* 健壮
* 灵活
* 无冗余
* 可读
* 可测试
面向对象的一些原则和方法
* 内聚性（cohesion）：例程中操作之间联系的紧密程度
* 耦合性（coupling）：两个例程之间联系的紧密程度
* 软件开发的目标：高内聚、松耦合
* 发现变化并将其封装
1. 寻找变化，并将它封装在一个单独的类中
2. 将这个类包含在另一个类
* 当一个类处理越来越多不同变化时，代码的内聚性就会变得很差。即：它处理的特殊情况越多，可理解性就越差。
* 设计的两步法：1> 抽象类（共性）—— 需要什么接口来出来这个类的所有责任？2> 派生类（可变性）——对于这个给定的特定实现，应该怎样根据给定的规约来实现它？
* 处理新需求的选择： 1> 分析瘫痪；2> 放任自流； 3> 考虑变化的设计
* 考虑变化的设计
* 原则：针对接口编程，而不是针对实现编程
* 原则：优先使用对象组合，而不是类继承
* 原则：考虑设计中什么应该是可变的
* 防止“分支蔓延”
* 一条规则，实现一次
组合起来：用模式思考
* Alexander: 设计应该从问题的一个简单陈
* 述开始，然后通过在这个陈述中加入信息，使它更加详细（也更加复杂）。一种基于模式的方法（《建筑的永恒之道》），
1. 从整体的概念性理解开始，以理解需要实现的目标
2. 找到整体中出现的模式
3. 从为其它模式创造背景的那些模式开始
4. 从背景向内：应用这些模式，找到新的模式，并重复
5. 最后，通过每次应用一个模式，改进设计，并在所创建的背景中予以实现
* 用模式思考的过程：
1. 找出模式
2. 分析和应用模式
* 按背景的创建顺序将模式排序
* 选择模式并扩展设计
* 找到其它模式
* 重复
3. 添加细节
* 考虑背景时候的一条规则：先考虑系统中需要什么，然后再去关注如何创建它们
* 背景和被使用的关系：当一个模式使用另一个模式时，被使用的模式就处于使用模式的背景中
设计模式的策略：
* 从背景设计
* 在类中封装变化
设计模式的原则：
* 开闭原则——模块、方法和类应该对扩展开放，对修改封闭。换言之，软件应该设计成不加修改缘由代码就能扩展功能。
* 依赖倒置原则——其背后的理念是在设计细节之前先创建总体概念。高层模块不应该依赖底层模块。相反，它们都应该依赖于抽象。
* 理性怀疑原则——小心过分依赖模式。概念层次的模式和模型都是真理的抽象。它们是已往经验和教训的结晶。使用它们来帮助我们思考摆在前面的问题。
共性与可变性分析（CVA）：
1. 先寻找共性
2. 从这些共性创建抽象
3. 从共性的变化寻找派生
4. 看共性之间的关系如何
分析矩阵：
1. 找到某种特定情况中最重要的特性，并用矩阵将它们组织起来。用特性所表示的概念为每个特性标记。
2. 继续处理其它情况，安需要扩展这个矩阵。处理每一情况时应该独立于其它情况。
3. 用新的概念扩展该分析矩阵
4. 用行发现规则
5. 用列发现实现
6. 从这种分析中确定模式
7. 得到高层设计
对象创建和管理规则：对象应该要么构造和/或管理其它对象，要么使用对象，而不应该兼而有之。
常见的设计模式：
* Facade
* Adapter
* Strategy
* Bridge
* Abstract Factory
* Decorator
* Observer
* Template Method
* Singleton 和 Double-Checked Locking
* Object Pool
* Factory Method
《设计模式解析》读后感(四)：设计模式解析-第二版(中文版) 翻译的较差;
13.2
系统能够分析出和提取金属板材各部分的CAD/CAM描述;
My system must be able to analyze and extract CAD/CAM deｓｃｒｉｐｔions of pieces of sheet metal.
(分析出,为什么要多个'出')
最初应该关注的是金属板材零件;
Initially, I am concerned with sheet-metal parts.
('应该'是从哪里来的)
每个金属板材零件可能有多种部件.
Each sheet-metal part can have multiple kinds of features,
(features能翻译成'部件'吗);
13.3
quot;小傻瓜"
quot;You idiot!"
(太暧昧了吧)
13.5
然后根据每个模式如何为其他模式创造背景进行选择.
I then select them based on how each pattern creates the context for the other patterns.
('背景'一词翻译错误)
...
《设计模式解析》读后感(五)：授人以鱼，还要授人以渔
工厂，工厂方法，抽象工厂，桥模式，装饰，facade，适配，观察者，策略，单例。
学习了一招厘清复杂需求头绪的方法，叫做“分析矩阵”，在书中第16章，将来工作中遇到这种时候可以试一试。
感觉这本书后面翻译的没有前面好，不知道是我看累了还是译者翻译累了。。
很赞同书中125页的一段话：
//-------start---------
当人们开始学习设计模式时，他们经常把注意力放在设计模式提供的解决方案上。这看起来似乎很合理，因为设计模式被广为宣传的一点就是能够为实际问题提供优秀的解决方案。
但是，这从方向上来说就是错误的。在尝试将某个解决方案应用到一个问题之前，应该先理解问题。这种只是寻找在何处应用模式的方法，只能告诉你“要做什么”，但是不能告诉你“什么时候”或者“为什么使用”。
//-------end---------
有的朋友觉得这本书很罗嗦，有些章节讲的东西太抽象，但我却觉得那些很抽象的内容才是这本书的精华，就像武林绝学和内功心法一样，那些讲述思维方法的文字都是心法，具体的模式是穿插其中的案例而已。
我觉得作者从头至尾都在强调不仅仅要知道“怎么做”，更要知道“为什么这么做”，貌似老外的书都喜欢讲这些。
《设计模式解析》读后感(六)：如何思考代码
遇到这本书是一个偶然的经历，但是很幸运他没有从我的指尖溜走。这本书，不是教科书，是思想的演进，是思想的讲述。很多人，在学习编程的时候，只是停留在传统教课书的水平，虽然做了很多年，但是无非就是理解了更多的API或者封装库，但是自己在编程的时候，思维水平仍然停留在初级，无法更加进一步的去前进。对于很多人，其实更多是跟谁高手，一起工作，渐近学习高手的思维方式，从而提升自己的。但是很遗憾，并不是每个公司都有高手，也并不是每个公司都有机会跟高手学习。这本书就是一个你身边的高手。
1.面向对象
作者对面向对象的理解，完全是从真正实用的角度在分析。对象就是职责体，封装是为了隐藏，而不仅仅是为了数据和行为的隐藏，可以是任何隐藏，继承是为了多太，本质也是隐藏，对象要求，“高内聚，低耦合“ 因此，需要注意的是，对象可以使用组合，去解决继承爆炸的问题。（这是标准面向对象的弊端），除此以外，因为有了组合，可以进一步做到”职责的单一“。
2.面向对象比较
标准面向对象分析：问题域中寻找”名词“创建类，寻找”动词“创造方法，另外，利用名词创建继承。（造成了继承爆炸）
新的对象分析方法：寻找”职责“创建类，具体方法为职责的执行内容即可。另外，”利用变化创建封装，利用共性创建概念类，概念类包含可变类“
模式的推演方法：（上述话的更进一步理解）
1） 寻找变化，并将它封装在一个单独的类中。
2） 将这个类包含在另一个类中。
3.问题域的分析方法
1） alexgender的方法，也是建筑学方法，步骤：
a. 明确整体背景，明确整体目标。
. 需要解决的问题域有哪些，哪些模式可以解决
c. 设计模式的背景推导关系。
2） CVA分析法，也叫做 共性与可变性分析，步骤：
a. 领域内有哪些概念
. 概念的共性和可变性有哪些
c. 确定具体的概念类型的继承关系
d. 不同概念之间的关系
3） 矩阵分析的方法，步骤：
a. 领域问题，情况和流程
. 每一个问题，确定具体概念
c. 罗列所有问题，形成概念矩阵
d. 行使用模式实现，列是具体实现
e. 模式之间的关系
4. 以 设计模式的思想 从事开发：
1) 设计模式本身的约束，处理的问题域，限制条件。
2）不同模式之间的组合或者说，不同模式之间的关系。
5. 其他模式的讲解，感觉就有点凑数了。但是还是有几个思想很好的：
1） 工厂方法，实现了”使用“与”创建“的隔离
2） 桥接模式，其实现了”概念“与”实现“的隔离
总结，我觉得这本书中最重要的特点是告诉你，如何进行重构代码，应该考虑的就是，职责，基于变化的职责分离。