经过多年的工作实践后，再重读这本书得到了融会贯通。

设计模式的开山之作，书虽不厚但很难读，书中的例子是c++和smalltalk混着写的，我不是很熟smalltalk，因此让这本书更难读了。难读归难读，里边的好多概念是深刻且重要的，就比如引言中对于框架的解释让我感到豁然开朗。设计模式本来就很难，换本通俗的书读吧，别自己折磨自己了。

刚工作的时候读过一次，当时读完去写代码总是想套用书里提出的模式，后来发现有点本末倒置了，便不再去想这些模式，现在经过了几年的工作，并且也给vscode提了一些pr单之后重新阅读这本书，阅读文本编辑器的例子，发现更加的能融会贯通了，希望以后我还是会忘记这些模式，就和元编程一样，根本没有什么元编程，有的只是编程

2023.6.6-2023.6.27，首次阅读加一轮复习，是有影响到我的书。专门买了小本子重新把所有模式按自己的理解画了一遍，虽然是很拙的学习方法，但初次接触，觉得有必要以此表达敬畏，后面希望通过练习能够达到忘掉模式运用自如的程度。之前花了大概10个月的时间从零做一个产品，虽然只是一个复杂度很低的系统，也是配合别人写特定功能模块完全比不了的难搞，中间在懵懵懂懂中重构过一次代码似乎提升了而一些，但从后期测试结果来看也不尽如人意，架构依然不够漂亮。虽然很多人说我们这种半路出家的程序员如何努力也做不了大家，但我还是相信行业软件还是要行业专家才能做到最好，而且我也有参考过很多所谓程序员的代码，真的……不堪一击……。不管怎样，还是会持续努力的，已经非常期待开始做下一个产品，好好发挥了！

工作了十多年后，终于完整看完一遍，我相信还会看很多遍

啃完了，不熟悉C++，所以其中的一些代码难以理解，之前写过一个设计模式的专栏：https://blog.csdn.net/hotonyhui/category_12091486.html 多多指教

书很薄，但是内容很重要，不甘心做一个CURD程序员。

总于还是开始读这本早就听说的书，就是害怕读不懂，久久不敢开始。还好，读到了一半多了。 现在看，很多后来基于这本书发挥的后继书都可能没有这个原版书籍更简单易懂，更不会让人害怕一些。

GoF这版太经典了，但代码语言偏老，以c++和smalltalk语言为主。其优势在于讲出了设计模式的灵魂。不像其它讲设计模式的在堆代码，而是侧重于讲什么才是设计模式的最优解。也就是要结合所针对的问题及其上下文来判断采用什么模式。另外，通过分类的方式更容易理解和记忆。设计模式按目的课分为创建型、结构型、行为型；按范围可分为类和对象。“目的”+“范围”两两结合涵盖了所有模式，例如属于创建型对象模式的有“抽象工厂模式”，根据分类不难理解其作用是将对象的部分创建工作延迟到子类。

每次看这类书总是受益匪浅，就是需要完全静下来了才能看下去

读了引言，已经有了很多实践后再来读这本书轻松很多，像一本归纳总结的笔记。中文版好难读……接下来还是找找原版

太老了，而且没写过 OOP 的人读起来很吃力。OOP 确实日落西山了，对吧？

为了重构大致过了一遍，写得非常好 但是用到自己工作中还需要大量的思考（ps 不知道怎么用，感觉用哪种都差点意思）

例子有点过时（这年头谁会smalltalk），写得比较高层次，所以我这种智商比较低可能适合读headfirst。。

翻了下，工作需求不打，没看了

微信读书上重读了一遍. 案例已经旧了

结构型模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。一个简单的例子是采用多重继承方法将两个以上的类组合成一个类，结果。老包含了所有父美的性质。这一模式尤其有助...

行为型模式涉及算法和对象间职责的分配。行为型模式不仅描述对象或类的模式，还描述它们之间的通信模式。这些模式刻画了在运行时难以跟踪的复杂的控制流。它们将你的注意力从控制流转移到对象间的联系方式上来。 ...

将系统分解成对象集合。因为要考虑许多因素：封装、粒度、依赖关系、灵活性、性能、演化、复用等等，它们都影响着系统的分解，并且这些因素通常还是互相冲突的。

类型(type) 是用来标识特定接口的一个名字。

动态绑定是指发送的请求直到运行时刻才受你的具体的实现的约束。

进一步讲，动态绑定允许你在运行时刻彼此替换有相同接口的对象。这种可替换性就称为多态(polymorphism)，它是面向对象系统中的核心概念之一。

抽象类(abstract class)（与之对应的还有非抽象类称为具体类(concrete class)。）的主要目的是为它的子类定义公共接口。一个抽象类将把它的部分或全部操作的实现延迟到子类中，因此，一个抽象类不能被实例化。

子类能够改进和重新定义它们父类的操作。更具体地说，类能够重定义(override)父类定义的操作，重定义使得子类能接管父类对请求的处理操作。

混入类(mixin class)是给其他类提供可选择的接口或功能的类。它与抽象类一样不能实例化。混入类要求多继承

针对接口编程，而不是针对实现编程。

优先使用对象组合，而不是类继承。

一个对象可以有许多类型，并且不同的对象可以共享同一个类型。

对象的某部分接口可以用某个类型来刻画，另一部分接口由其他的类型来刻画

Program to an interface, not an implementation
Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class

This dependency limits flexibility and ultimately reusability. One cure for this is to inherit only from abstract classes, since they usually provide little or no implementation.

Favor object composition over class inheritance

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receivingobjects and pass the
request along the chain until an object handles it.

1. Reduced coupling.The pattern frees an object from knowing which other object handles arequest. An object only has to know that a request will be
handled"appropriately." Both the receiver and the sender have no explicit knowledge of each other, and an object in the chain doesn't have to know about the chain's structure.
As a result, Chain of Responsibility can simplify object interconnections. Instead of objects maintaining references to all candidate receivers, they keep a single reference to their successor.
2. Added flexibility in assigning responsibilities to objects.Chain of Responsibility gives you added flexibility in distributing responsibilities among objects. You can add or
change responsibilities for handling a request by adding to or otherwise changing the chain at run-time. ...

关于Builder的协作过程：
1、客户创建Director对象，并用它所想要的Builder对象进行配置。
2、一旦产品部件被生成，导向器就会通知生成器。
3、生成器处理导向器的请求，并将部件添加到该产品中。
4、客户从生成器中检索产品。

Director notifies the builder whenever a part of the product should be built.

C++中的工厂方法都是虚函数并且常常是纯虚函数。一定要注意在Creator的构造器中不要调用工厂方法——在ConcreteCreator中该工厂方法还不可用。

Factory methods in C++ are always virtual functions and are often pure virtual. Just be careful not to call factory methods in the Creator's constructor—the factory method in the ConcreteCreator won't be available yet.

Design Patterns: Elements of Reusable Object-Oriented Software

我感觉看这本书，有几个层次，每个层次对应着软件开发方面的境界。 第一个层次，看不懂。所谓模式，就是在长期写代码的过程中总结出来的一种经验。这在刚毕业或者工作一两年的软件开发的工程师中，很多就反应这本书很深奥，难看懂。一方面，书中的例子是C++写的，而且时间比较...

请忘记什么是模式

误解1：设计模式只有23种 GoF在前言中就说到“We don’t consider this collection of design patterns complete and static; it’s more a recording of our current thoughts on design.”这本设计模式领域的开山鼻祖，第一扩展了人们的面向对象设计思路，第二则启示人们用模...

GoF —— 一本被误解很深的书

第一次看，看了40页，实在枯燥，看不下去了。 第二次看，是一年后，期间做了个项目，项目十分糟糕，偶尔又翻了这本书，感觉实在不错。这次总算看了大概。 第三次看，又是一年后，这次当参考书来了，呵呵呵  我的建议，一定要有不成功的开发、维护经历，这本书才能够让你深入理...

不错的书

1. 现在的计算机书已经厚到令人发指。比如这学期的《操作系统》教材，厚度堪比辞海。  2. 学术论文也一样。一个人写自己在巨人肩膀上看到的风景，一定要从自己爬巨人时看到的腿毛开始描写。  3. 这本书254页，可是取其精华远多于那些学术垃圾。  4. 因为考试原因，两天看完，酣...

一本好书的厚度

如果你觉得这本书不知所云，那说明你其实不懂编程  如果你觉得这本书对你裨益甚多，那说明你开始了解编程  如果你觉得这本书不过如此，那你不是高手就是完全的外行

这本书其实可以当作一个指标

作者坦言，书中描述的23种模式并不是他们创造出来的，他们只是进行了总结和归纳。  这本书并不适于初学编程的人，甚至是没有相关知识背景的熟练程序员。因为其对概念的描述太过简洁和学术化，其C++的例子也不是很好懂--我自己就愣是没有看懂，后来还是通过另一本以Java为例子的...

一统天下

在支持函数式的动态语言里， 绝大多数design pattern都变的简单直接，以至于你甚至感觉不到它们的存在。 在面向对象的限制之下，敞开的大门不走，偏要爬窗户。 比如strategy pattern的本意是通过composition而非inheritance，使能够在运行时（runtime）动态绑定某对象的成员方...

毁了一代工程师

这就是书中的阳春白雪。当然，高人是一看就懂。  前10遍，只懂几个模式；到20遍，似乎都懂了，但是放下书就不能自己构造一个出来；30遍后，至今没再看。书也看烂了，但是敝帚自珍。  读者最好熟悉c++，以及一定的利用c++做开发的经历。否则，最好看别的类似的书。  如果希望用o...

看了30遍后至今没再看

经典就是经典，GoF在本书中提出的设计模式，至今仍被人津津乐道。很多人自称高手，自以为的那些所谓高手，基本的一条就是懂得若干设计模式。很多人说这本书很枯燥，虽然GoF的思想很好，但是书写的挺差劲，很容易让人昏昏欲睡。确实是的，如果不能潜下心去研读，只会看到很多不...

略显枯燥的经典

由李英军同志翻译的中文版我是无论如何读不懂。  本来这本书GOF就是以学术专著的形式写成，所以晦涩啊，艰深啊，再加上中文翻译的不准确性，就造就了该书中文版被芸芸众生顶礼膜拜为天书的壮观景象。  不过还好，机械工业出版社自己都觉得问心有愧，遂直接出版『影印版』，于是...

读经典要读原版

这本书很适合，有一定编程经验的程序员来看， 不太适合刚刚入门的程序员。 设计模式有好多种，本书阐述了27种（我记得是） 我们还可以自己总结一些其它模式，这样就更有意义了。

基于已有模式，探讨新模式：加油哦！Dev

软件行业从业者必读的经典，从我就业以来就一直想把这本书看一遍，但是之前一直在搞Linux开发，玩的是C语言。没有什么模式可言。直到近期我做点QT的开发，才有这样的机会。  直接拿起这本书看觉得有点费劲，所以先看了《Head First设计模式》，并把书中的所有模式都用C++实现了...

非常经典的一本书

书绝对是好书，但是译者的翻译给理解本书的原本含义造成了巨大的障碍，对翻译的理解的障碍甚至大于对于设计模式本身理解的障碍。  要读就读原版，否则可能越看越不懂。看不懂得时候，不一定是自己的智商低，多想想别人的智商。  没有10万行代码勿读，少儿不宜。

强烈建议读原版，翻译真shit

但是发现现在所谓模式的滥用比用好的比率大得多。 反复思考，到底OO和模式将给偶们带来什么？ 不能为了模式而模式。

好书，不过很难读。

这篇书评可能有关键情节透露

                        由于翻译得太烂，逼得我只能去看原文，由于翻译得太烂，逼得我只能去看原文 由于翻译得太烂，逼得我只能去看原文，由于翻译得太烂，逼得我只能去看原文 由于翻译得太烂，逼得我只能去看原文，由于翻译得太烂，逼得我只能去看原文 由于翻译得太烂，逼得我只能去看原文，由于翻译...

觉得这本书的翻译是坨屎的点赞

曾经我会特别注意系统/网络/算法相关方面的学习，但老是觉得软件工程方面的书不用看太多，自己从经验中总结就行了。 前段时间有空随意翻看了这本书，有一句话特别打动我，大意就是模式术语其实是一次抽象，而开发生涯中抽象能力是非常重要的。阅读时起时也是获得经验（间接经验...

书很好，翻译得不太好

铜弹      二十五年前，弗瑞德.布鲁克斯“没有银弹”的论文让古老的迷信成为了现代软件工程领域家喻户晓的时髦比喻。八年之后，《人月神话》二十周年纪念版发行，他谈了对面向对象编程的看法。面向对象仍然是从次要复杂性（外在技术的复杂）去解决复用的问题，还没有从软件项目...

设计模式与动态语言－－读在十八年后的世界

计算机科学丛书

可复用面向对象软件的基础

这不是一本拿来就能套用的模式字典。许多读者第一次翻开时会被C++与Smalltalk交织的例子劝退，也曾在初学阶段把每个设计都硬套进模式里，结果本末倒置；正是多年实践之后重读，才真正体会到书中那句「要结合所针对的问题及其上下文来判断采用什么模式」的分量。它不堆砌代码，而是逼你思考封装、粒度、依赖、灵活性这些相互冲突的因素如何权衡，讲清的是设计模式的灵魂而非现成答案。适合那些不甘心只做增删改查、愿意反复啃读的人——薄薄一本，值得读很多遍。

设计模式：可复用面向对象软件的基础