设计模式的艺术

设计模式读后感: 一: 这应该算是我看的第四本设计模式的书了，我在2017年购买了经典之作“设计模式—可复用面向对象软件的基础”（GOF设计模式），记忆犹新，学术性太强，当初啃得非常痛苦，没有啃完，接着当然就是压箱底了．随着时间推移，在疫情期间，我选择了程杰所著的《大话设计模式》，这本书以其轻松的语言风格给我留下了深刻印象，每个模式的概念都能轻易理解，然而在合上书后，由于缺乏实践支撑以及对整体框架的系统性认识，这些模式在我脑海中尚未形成有机联系．后来，我投入两个月时间研读了厚达600多页的《Head First 设计模式》，也在日常工作中，强迫并促使自己积极践行设计模式的原则。至前年重读GOF的著作时，对其内容的理解和阅读体验变得流畅了许多。 二: 在2024年，我开始使用微信读书，机缘巧合的向我推荐了刘伟教授所著的《设计模式的艺术》一书，该书备受网友推崇，被誉为“神作”。刘老师加了简单工厂模式进来，总共就有２４种设计模式了．我决定每天抽出一点时间专注一种模式，并在三月份期间逐步完成了全书的阅读。接下来，我分享一下此次阅读后的心得体会。 １：加深了我对常见UML的用法，以前用的可能并不是很规范 ２：在阅读过程中，挺喜欢刘老师这种清晰的教学方式，善于从具体的需求出发，先展示一种常见的、看似合理的实现方法，继而揭示其中存在的问题，从而引出设计模式的必要性。通过这种逐步引导，让我更加深刻地理解了每一个模式的价值所在，包括它们的不同应用场景、优缺点以及多种变形应用 ３：在这次研读的过程中，我抱着每日只阅读一个模式的明确目标，心态尤为从容不迫。刘老师在书中精心设置的思考题与练习题目，我都一一付诸了实践，让我感受深刻的是，理论转化为实践时，会面临许多意想不到的新挑战，但是在实践的过程中，也会涌现出许多新颖的认识，特别是，各种模式间关联性上的见解． ４：回顾四本设计模式书籍的学习历程，如今面对需求或者问题时，就会下意识主动思考背后的业务背景，它的约束条件是什么？要解决怎样的问题？我们应该采用什么方案？一旦选定某种设计方案，我便立即评估其潜在的效果，剖析方案的优点与不足之处．尤为重要的是，我会将开闭原则作为衡量设计方案质量的重要标尺，因为我发现这一原则在日常工作实践中起到了犹如通关密钥的作用。倘若设计方案未能充分满足开闭原则的要求，我便会继续追问：是否有效地采用了面向接口编程手法？是否遵循了替换原则和依赖倒置原则？每个类的职责划分是否足够单一？封装性是否得到了妥善处理？是否过度依赖继承，而忽视了组合的优势？对于调用者而言，接口设计是否友好易用？接口之间是否实现了必要的隔离？此外，类之间是否是松耦合？是否避免了不必要的大量交互？以及是否遵循了迪米特法则以降低耦合度。 ５：对于书中提到的设计模式乃“心法”之论，我个人的理解略有不同。我认为设计原则才是支撑起整个设计思维体系的心法，而23种设计模式则是依据这些原则演化出来的实战招式。遵循设计原则的设计方案，无论最终呈现出何种形态，实质上都能找到与设计模式的内在联系，它们或是某一模式的标准形式，或是某种模式的变异形态，均指向了一种更为合理且易于维护的设计架构。

终于碰到一本比较容易读下去的设计模式书籍，说说本书的几个优点： 1）每种设计模式都标有 学习难度&使用频率 星星等级(这个太重要了)，让我可以毫无心里负担的先去挑读某些章节； 2）每种设计模式都配一个很生动的生活化的场景示例和一个扩展的源码场景示例，让你一下子对该种设计模式有一个体感； 3）有应用场景的简洁的UML结构图。 结合自己开发过程中，从最高频的几个设计模式开始挑读，建立阅读信心！ 1）. 创建型模式 6种 1. 单例模式 （高频）：确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。 2. 工厂方法模式（高频）：定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。 3. 抽象工厂模式（高频）：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。 4. 简单工厂模式（中频）：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。 5. 原型模式（中频）：使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。 6. 建造者模式（低频）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 2）. 结构型模式 7种 1. 外观模式（高频）：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。 2. 适配器模式（高频）：将一个类的接口转换成客户希望的另一个接口。适配器模式让那些接口不兼容的类可以一起工作。 3. 组合模式（高频）：组合多个对象形成树形结构以表示具有部分-整体关系的层次结构。组合模式让客户端可以统一对待单个对象和组合对象。 4. 代理模式（高频）：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。 5. 装饰模式（中频）：动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。 6. 桥接模式（中频）：将抽象部分与它的实现部分解耦，使得两者都能够独立变化。 7. 享元模式（低频）：运用共享技术有效地支持大量细粒度对象的复用。 3）. 行为型模式 11种 1. 迭代器模式（高频）：提供一种方法顺序访问一个聚合对象中各个元素，而又不用暴露该对象的内部表示。 2. 观察者模式（高频）：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。 3. 策略模式（高频）：定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法可以独立于使用它的客户而变化。 4. 命令模式（高频）：将一个请求封装为一个对象，从而让你可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。 5. 模版方法模式（中频）：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 6. 状态模式（中频）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。 7. 责任链模式（低频）：避免将一个请求的发送者与接收者耦合在一起，让多个对象都有机会处理请求。将接收请求的对象连接成一条链，并且沿着这条链传递请求，直到有一个对象能够处理它为止。 8. 中介者模式（低频）：定义一个对象来封装一系列对象的交互。中介者模式使各对象之间不需要显式地相互引用，从而使其耦合松散，而且让你可以独立地改变它们之间的交互。 9. 备忘录模式（低频）：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。 10. 访问者模式（低频）：表示一个作用于某对象结构中的各个元素的操作。访问者模式可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 11. 解释器模式（低频）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

基于面向对象编程的26种设计模式的案例性详解，对于有一定编程经验积累的读者，应该会很有帮助。这个前提，也就意味着如果没有相关经验，那可能读起来就比较痛苦，甚至难以形成直观理解。 不过，所有这26种模式，在实际的软件工程或者项目管理中，往往不是如书中那样条理分明，界限清晰的。反而是在日常系统维护和更新时，需要快速解决问题时，大家会本能地采用一些已经非常熟练的套路。而这些套路往往就是这些模式中的一种或者几种的组合。 但从我个人的经历看，如果能从项目起始阶段，就有意识地以这种模式化的思考，对项目需求和功能进行梳理定义，效果肯定会好很多。但这也往往意味着前期要投入更多时间和资源，与大量准备工作。这些工作相比于同期可见可量化的可交付成果而言，肯定是不成比例的。所以，最终就是在骨感的现实中，继续用那些模式小技巧去打补丁，才是最常见的日常。但即便如此，这本设计模式的速查手册，也非常值得反复阅读。

本书涵盖了所有的设计模式，讲得通俗易懂，每个模式都给举了不同的例子来给大家进行描述，并讲解每个设计模式的原理以及代码，每篇最后还附有设计模式的优点和缺点以及使用场景，还有一些思考问题和例题来供我们思考，发散思维。

每种设计模式以一个实际问题场景的描述，非最佳设计出发进行分析，然后再给出最佳设计模式的对应，从基础的设计模式到该模式优化过程，整体层层递进，读起来还是挺舒服的。 落到实际开发过程中对具体问题分析抽象的能力，还需要自己动手绘制UML框图揣摩、体会

简单、易懂、真诚，是一本好书。看得出来作者喜欢金庸武侠，而喜欢金庸武侠的，我想都不会太坏。里面有很多UML都画得挺用心，代码详略得当。看完书才发现，竟然有60+w字，但读下来主观上感觉好像只有20w字，这大概是“读起来不枯燥”最好的佐证（很多设计模式的书，翻开没看几秒就不想看了）。 这里没有批评其他书的意思，但市面上很多技术书，为了讲故事而讲故事，反而把设计模式讲得更糟糕，还不如直接开门见山谈模式本身，辅以实际案例。

非常一般，看似专业详细，其实是啰里吧嗦抓不住精髓

需要耐心阅读，带着问题收获很大。

刘伟的《设计模式的艺术》一书，主要讲的是是23种设计模式。设计模式说的是“前人经验的积累，它能让软件变得像一个艺术品，不再是一堆难以维护和重用的代码”。 首先是以 创建对象为目的的 5种常用的“创建型”设计模式： 确保系统中只有一个类的实例的-单例模式、 将对象的创建和对象的使用分离，集中式工厂体现-简单工厂模式（它不属于设计模式范畴）、 通过不同的工厂来创建不同类型对象的多态工厂的实现的-工厂方法模式、 能够创建一系列产品（产品族）-抽象工厂模式、 通过克隆创建一个一模一样的对象-原型模式、 复杂对象的组装与创建的--建造者模式。 创建型模式中的 5中设计模式 能帮助我们 更好的管理对象的创建过程提高系统的灵活性、可扩展性、性能和可维护性。 接着是 以 组合为目的的 的7种结构型的设计模式： 适配器模式：不兼容结构的协调，在不修改现有系统的前提下重用没有原码的第三方类库； 桥接模式：避免在多层继承结构中类的个数出现爆炸式增长，处理更多维度的变化； 组合模式：用面向对象的方式来处理软件系统中的树形结构； 装饰模式：不通过继承的方式，扩展了对象的功能； 外观模式：为复杂子系统提供一个统一的入口； 享元模式：实现对象的多次复用以节省系统的资源； 代理模式：对象之间的间接访问； 结构型模式中 7种设计模式：更好的组合和管理系统（对象）的结构，降低耦合。目的也是提供系统的灵活性，可扩展性能，便于维护和开发。 最后是以交互为目的的 行为型的11种设计模式： 责任链模式：让多个对象都有机会来处理同一个请求（请求的链式处理）； 命令模式：将请求的发送者和请求的接收者完全解耦； 解释器模式：自定义一个语言的实现成为可能； 迭代器模式：间接遍历一个聚合对象中的元素； 中介者模式：协调多个对象之间的相互调用； 备忘录模式：撤销功能的实现； 观察者模式：对象之间的联动（一对多的联动）； 状态模式：设计和实现一个具有多个状态的对象（状态及其转换）； 策略模式：算法的封装与切换，在不修改现有代码的情况下更换另一种算法； 模版方法模式：为一个复杂算法的某些步骤提供多种实现方式，定义算法的框架； 访问者模式：操作复杂对象的结构，运行一个或者多个操作应用到一组对象上，解耦操作和对象本身。 行为型模式中的11种设计模式：更好的处理对象之间的交互和职责分配，也是提供系统的灵活性和扩展性，可维护性，可复用，效率，性能，可靠和安全。

懂的都懂，不懂的还是不懂，看了没什么长进（捂脸哭）