《设计模式》书评

评论测试

非常不错的一本书...........................非常不错的一本书...................................非常不错的一本书...........非常不错的一本书........

书很好，有写例子看好多便才能明白

这本书的确很好，但是完全搞明白其中的模式并不是很容易。很重要的一点：设计模式只是一个思路，一个方法，最重要的是实现代码复用、代码的可维护性、可读性。抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了

建议先看看设计模式解析

没有太多实际经验，gof的书感觉十分枯燥。建议初学者先读读设计模式解析即Design Pattern Explained适合模式入门级的读者：）

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

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

经典永恒

在看完《大话设计模式》之书后，我对设计模式有了基本了解，因为此书是设计模式的开山之作，所以不可不读，读完之后也被作者们的鞭辟入里的讲解给深深地震撼了，我对各个模式的理解也更加深刻了，此书对没有设计模式基础的读者而言可能有一点难度，建议先读《大话设计模式》，这本书是学习设计模式必不可少的一本书，也是程序员案头必不可少的一本经典书籍，值得收藏，向经典致敬。本书唯一的缺点是里面有smalltalk语言的例子，因为我对该语言不熟悉，这些例子就直接跳过了，但是并不影响整个学习的过程。

书是好书

书是好书，讲的东西其实都是已经被证明的、有助于提高代码质量的成功模式。此书的问题在于：一，内容比较晦涩难懂，不知道是原文的原因还是翻译的原因。我读了好几次，每次都因为这个原因没有完成。二，缺乏实例。书中给出的例子过于抽象，和实际项目脱节，对于没什么经验的程序员来说比较难于理解。此书作为参考书不错，简洁，篇幅短小。不适合作为教材。

对此没有入门，呵呵

想看设计模式是刚工作的时候，也就那时看了看，觉得很难懂，呵呵。但也看了前四章，呵呵之前看过《设计模式解析》，两本结合起来看，没什么大的突破，无非就是知道了名词和意图，至于实现技术好像没有精力和能力去深究它。这几天又把这两本书拿了出来，呵呵。觉得《设计模式解析》原来的作用只是让你更好的了解模式，《设计模式》更好的讲了应用的技术，好好研究几个模式的实现呢，呵呵。

看了30遍后至今没再看

这就是书中的阳春白雪。当然，高人是一看就懂。前10遍，只懂几个模式；到20遍，似乎都懂了，但是放下书就不能自己构造一个出来；30遍后，至今没再看。书也看烂了，但是敝帚自珍。读者最好熟悉c++，以及一定的利用c++做开发的经历。否则，最好看别的类似的书。如果希望用oo做架构，认真反复阅读此书是大有裨益的。当然，如果理解了他的思想，你用c也可以做出同样的设计。心中有剑，万物皆可为剑。

软件工程师必读

如果你没有多少开发经验，读第一遍肯定没有什么体会，但是你可以在随后的实践中生搬硬套这些模式，往往会取得较好的效果。如果你已经有不少开发经验，读这本书你会明白自己过去都犯了哪些错误，为什么犯了那些错误，对你以后的编程会有很强的指导作用。

不要看的一本好书

写这个标题绝对不为哗众取宠。因为这本书，我看了也有三次，跟很多兄弟的感觉差不多。说实话，我最后看懂（其实还是不懂）只是明白如何看了，也是在一个兄弟的指点下才明白。因此，如果是自己看，只会越看越晕，越没信心。看这本书一定要有经验，而且是做项目的经验，写了三年以上的代码，自己有能力做过设计，找个兄弟讨论一下，才会容易看懂些。

思想还在模式之上

还记得当年第一次看到这本书的惊艳之感。因为刚好经历了一次可算失败的开发，所以硬着头皮读了下来。看完之后，模式只记得很少几个，但觉其对问题的思考模式，才是真正的无剑之 剑。

反复阅读

适合反复阅读。下面的话都出现在这本书中，第一次看时对这些都无感，甚至没有印象。再看时，一眼就发现了这些话继承与模板注重代码复用接口则强调一个对象是否可以被另一个对象替代面向接口编程尽量使用对象组合而不是继承。。。。。。

设计模式

这本书结合设计实作例从面向对象的设计中精选出23个设计模式，总结了面向对象设计中最有价值的经验，并且用简洁可复用的形式表达出来。书中分类描述了一组设计良好、表达清楚的软件设计模式，这些模式在实用环境下特别有用。此书适合大学计算机专业的学生、研究生及相关人员参考。书中涉及的设计模式并不描述新的或未经证实的设计，只收录了那些在不同系统中多次使用过的成功设计。

OO必看

　　以前在学校也写过一些代码，但是非常的乱，基本上没什么维护性可谈。C++就知道封装有用，看了设计模式才真知道了OO中多态、继承的作用。比如说一直认为很神秘的Undo，换主题啊等等。　　总之OO必看的书了。。。。。。。　　不过感觉如果你没有写过大量的代码或者看过大量的设计很好的代码，这本是很生涩的啦。也就说要有代码好与不好概念的时候才会明白设计模式的作用。　　看一个人是一名程序员还是一位软件设计师，大概可以从他对设计模式的理解。

翻译极差

翻译差，总能发现错别字和概念前后不搭的地方。部分翻译与原版意思完全不同，令人困惑。能看的只有类图和代码。难怪大家都要看几遍才能看明白。翻译差，总能发现错别字和概念前后不搭的地方。部分翻译与原版意思完全不同，令人困惑。能看的只有类图和代码。难怪大家都要看几遍才能看明白。

经典的无法评价

没看过的一定要看，不管你用什么语言。已看过的一定要再看，不管是什么时候。经典的经典。

我想烧了它

他们说精典的书.翻翻,结果:第一次有这样的书让我有这样的冲动.准备放一边.以后有空再看.难道我就不能看精典的书吗?

第二次看

第一次看，明白了概念第二次看，已经过了3年，期间做过若干项目，很有感觉，现在工作中用上一部分，对于很少用的模式还是要常拿来看看，时间长了就忘了：-）

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

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

不能少的模式书

以前在买设计模式相关图书之前,看过无数说该书枯燥难懂的评论.其后看了<C#设计模式>(大致浏览部分模式),Bob大叔的<敏捷软件开发,原则模式和实践>(看了很多遍),还有<设计模式精解>(部分模式详读),此外还在wiki,Blogs上看过许多次.最后还针对做个的一个较大项目分析何处可以用设计模式重构.可是对于设计模式我还只在了解/识的层次,还不能较好的应用所有模式.今天刚拿到此书,目前看了近20页,甚至还没看一个具体的模式,就觉得此书讲解方式不一样.该书从语言实现的角度分析设计以及何处可以使用设计模式.在看的过程中,不断闪现以往编码过程中的情景,乃至想到其他一些看到的东西.用个成语就是不断的----"豁然开朗"我喜欢这种不时有灵光闪现的阅读体验,也预感看完此书之后,对设计模式的理解会加深一层,就像当年看<代码大全>之后编码水平有明显提高一样.当然,此书也有一些问题,比如因为翻译太早部分名词和现行翻译有些不同,但不会影响阅读.我个人做法是在书最后列了一个不同翻译的对照表

不错的书

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

书很好，翻译得不太好

TITLE： 设计模式——可复用面向对象软件的基础\\ENGLISH TITLE: Design Patterns, Elements of Reusable Object-Oriented Software\\AUTHOR： 软件界四人帮 (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)本书共讲了23个常用的设计模式。创建型模式1. 抽象工厂 (abstract factory)2. 生成器 (builder)3. 工厂方法 (factory method)4. 原型 (prototype)5. 单件 (singleton)结构型模式1. 适配器 (adapter)2. 桥接 (bridge)3. 组合 (composite)4. 装饰 (decorator)5. 外观/表面 (facade)6. 享元/轻量级共享对象 (flyweight)7. 代理 (proxy)行为模式1. 职责链 (Chain of responsibility)2. 命令 (command)3. 解释器 (interpreter)4. 迭代器 (iterator)5. 中介者 (mediator)6. 备忘录 (memento)7. 观察者 (observer)8. 状态 (state)9. 策略 (strategy)10. 模板方法 (template method)11. 访问者 (visitor)每个模式我都读了两遍，基本掌握了，剩下的就是练习。感觉收获很大，对分析现有的软件系统更有信心了。在实现自己的应用时，也会好好设计一番，看看能否用上一招半式。“针对接口编程，而不是针对实现编程。”这句话对我启发很大。本书是一本好书，但机械工业出版社翻译的中文版并不太好。可能由于翻译者的水平，一些专业术语翻译得不好。另外排版问题也不少：错别字，丢字，重复字，丢标点符号。这些低级错误应该有不下十处。2014-01-23 Thu

书很薄。但内容很厚

买了本。扔柜子里了。看了几页。结论。一页顶一本书。以后看吧。现在先把菜鸟的基础弄扎实再说。不难。不过现在用不着。不是说内容不难，而是把难得的东西用很简单的语言描述出来了。经典就是经典。国内的书真的太烂了。至今没看到一本号称经典能比得上国外的经典的。

略显枯燥的经典

经典就是经典，GoF在本书中提出的设计模式，至今仍被人津津乐道。很多人自称高手，自以为的那些所谓高手，基本的一条就是懂得若干设计模式。很多人说这本书很枯燥，虽然GoF的思想很好，但是书写的挺差劲，很容易让人昏昏欲睡。确实是的，如果不能潜下心去研读，只会看到很多不知头绪的东西。一个模式一个模式的罗列，大约就是本书的特点。所以，不要在劳累的时候当做消遣地去读，除非你对这些模式已经了熟于心，否则那样的话只会让你更加迷糊。

恰当的时候看恰当的书

曾经听人说过，看不懂一本书，不是由于书写的不好，而是你无法领悟其中讲述的内涵。只有你经历过与作者类似的经历，才能明白作者所说。《设计模式》自从面世而来，经过多次再版，经久不衰。有人觉得内容很抽象，无法理解。三年前，我第一次接触设计模式时，同样对里面的实例和定义一头雾水。现在，翻起这本书，其中的23种模式，都能在做过的项目中找到踪影。这本书并不适合多年前的我，却适合现在的我。

一本好书的厚度

1. 现在的计算机书已经厚到令人发指。比如这学期的《操作系统》教材，厚度堪比辞海。2. 学术论文也一样。一个人写自己在巨人肩膀上看到的风景，一定要从自己爬巨人时看到的腿毛开始描写。3. 这本书254页，可是取其精华远多于那些学术垃圾。4. 因为考试原因，两天看完，酣畅淋漓，哈哈。最后拿了A。要不是考试，我也不会这么快把这本书看完。人都需要一点外在的压力。5. 我是Flyweight的粉丝！我是Prototype的粉丝！6. 压力问题。其实我能读完《论美国的民主》，能读完《理想国》，都是因为选了课或去旁听。7. 人要培养自觉。8. 软件工程比傻逼学术好玩。9. 豆瓣收留我吧！！我毕业了要去你那上班！！！我要抛弃.NET/Java！我现在起开始学Python，学Rails，好不好？10. 泪奔。刚才打了半天的内容没了。重新打的感觉很无趣。

第一遍-读后感

经过一段时间痛苦的阅读，终于将此书简略的读完了一遍！痛苦在于，自己水平有限，看这个书感觉看不出亮点，老是走神，导致看完了之后，依然不清楚它讲得到底是些什么东西。简略在于自己为了克服不能专心看书的问题，将一些内容看的非常简略，只看了大概的思想方面，具体的一些细节直接略掉了。尽管如此，依然感觉收获颇丰。本书非常简洁，总共就6章。前两章是总纲，我看的特别仔细，基本上看了3遍都不止，写的还是挺清晰的，总领了整本书。也正是因为我读的细，所以感觉这个书的结构非常的清晰，更进一步的锻炼了我的写技术性文章的思路。我觉得以后技术性的文章都可以按照这个模式进行撰写，可以很好的将技术给讲清楚。并且还锻炼了我的思维逻辑性，使得自己看书的效率能够得到提高。后面的3章讲了三大类模式。此书的核心是对于一些编程模式的介绍，希望程序员在以后的开发过程中，可以有更好的习惯，编写出质量更高的程序。如果理解了“模式”二字的含义感觉应该对此书有了模糊的印象了。我在看这些内容的时候，由于自己经验不足，或是可能其他的一些原因，总是不能很好的认真的去学习；甚至还有一些内容自己根本无法专心的去看，很是无语。其中一些模式讲得还是很好的，像什么工厂模式、桥接模式等，还是很能启发思维的。对于自己以后阅读他人的代码也会有很大的促进！就凭我现在的水平，根本无法理解此书的精华。通过阅读一些其他人的读后感，有一种说法是“看此书需要最终达到无招胜有招之境”。我深有同感。对于我而言，这是一本随着自己水平提升，才能从中吸取更多精华的书，因此需要多看，有了心得就需要再看一遍！

说实话，真没有怎么看懂！不过让我知道了一些初期的模式思想~

说实话，真没有怎么看懂！不过让我知道了一些初期的模式思想~这本书需要在一个人静静的沉入的才能看，不然肤浅的看的话会糟蹋了这本书的！建议这本书应该有个讲师一样的大牛给我们讲解一下，不然我们会很乱的

非常不错

非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错非常不错

请忘记什么是模式

我感觉看这本书，有几个层次，每个层次对应着软件开发方面的境界。第一个层次，看不懂。所谓模式，就是在长期写代码的过程中总结出来的一种经验。这在刚毕业或者工作一两年的软件开发的工程师中，很多就反应这本书很深奥，难看懂。一方面，书中的例子是C++写的，而且时间比较早，例子有点过时，另一个方面，自己经验不足，没有切身体会，对于其中的模式，无法联系到实际情况去理解。第二个层次，往上靠。不管实际需要不需要，非得用上几个模式，觉得这样代码才漂亮，才上了档次。其实，用模式，是一种好的现象，但是希望在用的时候，问自己两个问题，用有什么好处？不用会有什么问题？如果回答上来了，则用;回答不上来，则不要用。大部分人，处于这个层次，我见过很多。最大的问题就是，把简单的问题复杂化，复杂问题简单化。第三个层次，已忘记。会游泳的人，在游泳的时候，可能没人会想起游泳的注意事项以及要领。手脚和换气的动作，已经变成了肌肉的条件反射了。什么时候能够把模式变成你的手指的条件反射，那离编程高手就不远了。要达到这个层次，没有别的办法，不写几十万的代码是很难达到的。如果有志于编程，这本书应当是一本床头读物，学而时习之，时不时的拿出来看看，会有新的收获，编程是一种实践的工作，只有不断的coding，才能够提高，当已经达到忘了什么是模式，什么是架构的时候，已经可不看这本书了。

ＲＥ

大概的翻完了这本书，还行吧．之前对设计模式也没什么概念，翻完了书，也让我有了些新的认识．还是叫不出那些模式和具体的概念．呵呵，只是有一个大体的思想存在与脑子里．

难得的好书

学习C++的必看书之一。书的长度适中，可以在短时间看完，但很难在第一遍看懂。当你在做项目的时候，偶尔想想这本书的内容，你就会觉得收益颇多，回过头来再看第二遍，感觉就不一样了。当你需要用到某个具体模式的时候，回过头仔细再看某一章和相关的章节，你对设计模式的理解就又深入了一层。当你反复看了多遍后，只有一个感觉，那就是感叹这本书就是设计模式这个领域的Bible！

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

铜弹二十五年前，弗瑞德.布鲁克斯“没有银弹”的论文让古老的迷信成为了现代软件工程领域家喻户晓的时髦比喻。八年之后，《人月神话》二十周年纪念版发行，他谈了对面向对象编程的看法。面向对象仍然是从次要复杂性（外在技术的复杂）去解决复用的问题，还没有从软件项目针对解决的问题本身的主要复杂性（内在业务逻辑的复杂）上去解决问题，当然，面向对象仍然是一颗有助于代码和算法级别复用的铜弹。人们似乎永远找不到银弹，因为之所以需要雇佣程序员，就是我们要解决问题。如果问题的业务逻辑本身就是复杂和全新的，就不太可能存在重用的万能方法来提高效率。四人帮但是我们仍然可以从相似问题的成功解决方案中归纳经验，设计模式的概念就是从实际设计问题的解决中涌现的。绰号四人帮（gang of four）用来戏称《设计模式：可复用面向对象软件的基础》一书的四位作者，同时方便将他们最初的圣经和其它的关于设计模式的书区别开来。《设计模式》一共总结出了23种成功的设计思路，按不同的标准进行了分类，以便比较、启发我们提出新的模式。设计模式的概念标志着开始有更多关注在主要问题的解决上而不仅仅停留在技术问题上。模式依据目的可分为创建型、结构型和行为型三种。创建型模式与对象的创建有关，结构型模式处理类和对象的组合，行为型模式对类或对象怎样交互和分配职责，通常涉及类方法。我将模式按照相关的主题进行分组，综合上述两种分法，可以得到一个如下的表格：| 创建型 | 结构型 |行为型组合 | Abstract Factory |Bridge |Visitor层次 | | Composite |Interpreter| | |Iterator| | |Chain of Responsibility集中 | Singleton | Flyweight | Mediator| |Facade | Command| | |Observer解耦 |Factory Method | Decorator | State| Prototype |Proxy |Strategy| Builder |Adapter |Template Method序列化 | | | Memento组合爆炸在设计模式时，第一个要考虑的问题是类的组合爆炸问题。当一个抽象有多个具体实现时，通常用继承来协调。但是，如果问题包含有多个层次的抽象，机械的使用单一的继承策略来对应所有的组合会产生大量难以维护的类。为了让代码易于修改扩充，应该将不同的抽象部分分离开来，分别继承，然后通过对象间的引用来组合。例如，在抽象工厂模式中，有两个方面的抽象问题，一个是工厂的抽象问题，不同的工厂在不同的情况下会采用不同的具体标准构造产品类，另一方面有产品类的抽象问题，不同的一系列产品需要一个产品抽象类来统一他们的构造、使用接口。整体上，每一个具体的工厂都会引用每一个不同的具体产品对象。在结构型模式中，桥接模式也通过分离两个不同的抽象来实现，两个抽象通过基类的公共接口间的桥接整合在一起。行为型模式中的访问者模式解决这样一个双分派问题：对于一个具体的方法，不仅跟接受访问的对象类型有关，还和访问者的类型有关。这些模式最终产生一个拓扑结构像矩形的二维组合，每个组合都对应一种具体的完整实现。层级设计类的层级结构应该尽量简单。树形拓扑结构是一种常用的数据结构，适用于复杂问题的分而治之。静态的继承来对应对象间的动态的树形关系并不灵活。组合模式将代表叶节点的类和容器的类继承于共同的构件类，统一两者的接口，容器类返过来引用其基类构件类。对象通过递归组合，灵活的构成一个树形的拓扑结构。运用对象间的引用而不是类的继承，可以减少所设计类的层次，同时增加灵活性。职责链模式将对象引用连成一条链，请求被依次传递，直到有某个对象的方法处理为止。对于层次复杂的聚合结构，使用迭代器模式能提供按一定顺序访问元素的方法，解耦程序的复杂性。另一与复杂层次有关联的模式是解释器模式，它用于定义并执行一个文法的解释。由于文法通常可以由较短的BNF表示且结构较为固定，因此，解释器的递归组合可以直接用继承来对应。集中某些模式体现出集中抽象的特点。在创建型模式中，单件模式可以保证类在实例化后只有一个全局集中的访问点。在结构型模式中，享元模式中少量类的享元对象被反复引用，大量的引用者集中于一个享元，外观模式则将子系统的一组接口集中于一个高层接口，使得这一子系统更加易于使用。在行为型模式中，多个对象之间的行动协调往往有一个指挥中枢，命令模式的中枢是命令类，观察者模式则是被观察类，中介者模式则是中介者。这些模式都是单分派机制的实现：对于一个具体的方法，只跟一个对象的类型有关。在中介者模式和命令模式中，具体方法由发送请求的对象类型决定，而观察者模式，则是由接受请求对象的类型决定。接口编程好的面向对象编程应当对接口编程，而不是对实现编程，这样做使得客户无须知道使用对象的类型或实现，只需用抽象类中定义的已知接口操纵对象，这将极大地减少子系统实现之间的相互依赖。构建型模式中的原型模式可以无须知道所创建对象类型，构建者模式利用接口指导复杂对象的构建，无须知道创建对象的具体实现，工厂模式定义一个创建对象的接口，将一个类的实例化延迟至子类。在结构型模式中，代理模式和装饰模式都将一部分的功能分离，委托内部实际实现或由外部的装饰器一步步的增加功能。适配器模式则将一个类的接口转换成客户希望的另一个接口，这对于复用已有的代码十分有用。在行为型模式中，模板方法模式定义一个操作中的算法的骨架，将一些步骤延迟到子类，方便修改算法的某个特定步骤。因此，它使用的是钩子操作，父类方法空缺，由子类实现，而不是抽象操作，子类调用父类的方法。策略模式和状态模式收集所需的全部上下文，然后通过基类接口，委托具体的策略类或状态类来实现实际的功能，用户可以方便的替换策略或状态的实现。观察者模式其实是一种回调机制，而备忘录模式现在常常被称为序列化。语言无关设计模式是从“设计思路”的角度研究编程，理论上是和语言无关的，但是实践中由于设计模式是从具体的案例总结而来的，因此在成文过程中不可避免的与特定的语言相关联。由于C++、Java，设计模式通常是在上述的语境下所讨论的。如果从今天的角度看，有些设计模式，与其说是发挥语言的特点，倒不如说是在克服语言设计本身的不足。多年来计算机硬件飞速发展，动态语言逐渐流行。动态语言的特性，使得不少设计模式得到许多精简。动态语言：一等公民在动态语言中，类型是一等公民，不需要再通过继承抽象类的方式预留公共接口，而且类的构建也是动态的，很多情况下不需要设计工厂类来构建，所以抽象工厂模式、享元模式、工厂方法、状态模式和指责链条模式这六种模式可以简化甚至不需要设计。同样，函数在动态语言中也是一等公民，命令模式实现更容易，另外策略模式、模板方法模式、访问者模式这四种模式都能简化。广义函数机制Lisp这种动态语言的对象系统，即CLOS标准不是基于消息机制，而是基于广义函数机制。定义一个抽象的广义函数后，通过特化滚广义函数类型参数来定义一个具体的方法。这意味着方法不是属于类，而是实际上属于广义函数。更关键的是，广义函数的参数数量没有限制，本质上是一种多分派机制，不仅不需要设计访问者模式来支持双分派，而且可以实现任意多的分派。多分派特性又被称为多重方法。构建者模式完全可以用多重方法来实现，因为构建函数的具体方法不仅与读入标记对象的内容有关，也和标记对象的类型，被构建对象的类型有关。方法组合当广义函数特化被调用时，它会自动将符合特化条件的方法收集起来，并且按照最特定的匹配优先或者指定的顺序来执行。这种特点提供了一种叫做标准方法组合的技巧。中介者模式、观察者模式这样本质上单分派的机制，可以用方法组合代替，比如在主方法的请求执行后，用after:的辅助方法响应执行。宏与元编程Lisp的宏定义具有“元编程”的特点。它可以在普通代码运行前的宏时间预先处理代码。这为编程语言提供了语法上的抽象，可以直接设计BNF范式对应的宏来代替解释器模式。Lisp正因为这个特点所以有众多方言。Mathematica没有宏，但是可以通过Hold和Release操作在代码运行之前，对其进行操作，或者用ToString/ToExpression的组合，将代码转化成字符串，用正则表达式处理之后在转化回表达式运算，可以代替宏的功能，实现元编程。动态语言往往有模块机制，这样我们可以建立统一的接口却不再需要设计外观模式,不需要要生成对象。多范式编程动态语言除了传统的指令式、递归式的编程范式外，还支持其它多范式编程。Mathematica支持函数式编程，基于lambda演算的函数式编程具有无副作用的特点。符号和方括号的组合可以看成是面向对象编程的部分支持。不过，Mathematica并不需要传统意义上的面向对象系统，因为动态语言不需要继承一个公共的接口，一切都是动态加载的，方法和符号的关系可以用“广义函数”的角度来看待。逻辑编程Mathematic支持逻辑编程，即基于规则的编程。在Mathematica中，每一个:=语句都会对符号对象生成对应的:->匹配规则，可以简单的利用Mathematica内置的许多数学规则进行:=语句定义，也可以直接对符号联系的所有:->匹配规则进行修改，自定义的方式来进行。

用过里面的模式才说好

以前曾看过此书的一部分，感觉就是看不明白或者以为自己看明白了却不知道怎么用。工作半年后，偶然间拿起这本书再看，觉得他说的就是我想要的，软件模块如何复用，类之间怎样组合才有灵活性，不同的目的选用不同的设计模式，设计模式的适用场景，如何协作。这些收获当然与一段时间的工作经验和对工作的思考分不开，我不是那种不做事，想一想就能明白的人。GoF用简单的语言解答的很好，本书原版没有看过，只看了中文的，翻译水平可以认可。此书是看过《程序员修炼之道》之后的必读之物。

又爱又恨的名字

设计模式， 每天编着无聊的代码， 总想着超越俗气的coder， 多用设计模式和算法让自己的代码，看起来无比的牛。但是，什么时候才能掌握这些编程的精髓呢。。。。

一统天下

作者坦言，书中描述的23种模式并不是他们创造出来的，他们只是进行了总结和归纳。这本书并不适于初学编程的人，甚至是没有相关知识背景的熟练程序员。因为其对概念的描述太过简洁和学术化，其C++的例子也不是很好懂--我自己就愣是没有看懂，后来还是通过另一本以Java为例子的书来帮助理解的。我以为学设计模式，切不可太生搬硬套--这是初学者常犯的毛病。而应该更深入的理解其内涵，更多的研读现实中成功产品的源代码，以理解这些模式是如何实际应用的。设计模式并不是什么新的东西。有些模式，你或许已经在实际项目中应用了很多年了，只是不知道人家原来是这么称呼它的！所以，这本书最大的贡献应该是统一了术语，从此全世界的圈内人士交流再无障碍，GOF一词也因此成为了经典。

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

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

看不懂to恍然大悟

设计模式，只是编程的一些固有的规律，原则，书中描述的也只是作者多年经验的归纳及总结。所谓模式，原则，这些东西都是需要自己去体会才能明白，不是看看就行的，要动手，没几万行代码量看这书等于白看，今天看明天就忘了。

短小精悍,内容充实

用了10天左右看完了，说实话不像人们说得那么枯燥。相反我觉得写得相当有趣，让我有一种停不下来的感觉。本书从开篇到尾声都提到了“抽象“两个字，看书名里面也出现了element（元素），你可能就会觉得本书是一本非常形式化的书，可是实际上除了每一个模式中结构一节出现的类图外，几乎没有任何抽象的东西（即使是这一点，也有一张完全由实际元素构成的类图与之配对，所以说：尽管本书在讲如何抽象，可本书却一点不抽象），相反充满了各种实例：界面设计，编译器（解释器）设计，文本编辑器设计，网页设计……稍微夸张点说，这本书就像是软件工程的概览，带你到那大千世界里走一遭，然后从中提出些共同的东西引起你的思考，读书的过程会成为你的一趟奇妙之旅。当然如果你对这些实例毫不了解，那可能在看本书时就只能去看那些“抽象”的部分了，这样的话就会觉得就好像在观看空中楼阁。如果是这样，我建议有时间有精力的可以先读读《计算机程序的构造和解释——Structure and Interpretationof Computer Programs》（麻省理工那本著名教材），当然其他途径积累的知识也可以啦。

内涵深刻的书

很早以前就买了这本，当时看了几个模式就看不下去了，感觉很晦涩。现在看来是自己缺乏实际经验。其实23个模式都是从历史上很成功的项目里提炼总结出来（比如NEXTStep，也就是Steve Jobs二次创业时创立的公司NEXT的产品）。模式都是经验的总结，所以对于缺乏实际开发经验的人看起来就很难理解，一个if else的事为什么要用Responsibility Chain或 State模式解决？实话说，虽然看过一遍对很多模式都只停留在肤浅的理解上，真正掌握还得在实际项目里有意识的实践应用。引用篇尾引用建筑师C h r i s t o p h e r A l e x a n d e r所说：以一种松散的方式把一些模式串接在一起来建造建筑是可能的。这样的建筑仅仅是一些模式的堆砌，而不紧凑。这不够深刻。然而另有一种组合模式的方式，许多模式重叠在同一个物理空间里：这样的建筑非常紧凑，在一小块空间里集成了许多内涵；由于这种紧凑，它变得深刻。

据说此书乃设计模式的经典，但我看的很吃力

《设计模式》可复用面向对象软件的基础。老大说这本书好，说要多看几遍。我问他看了几遍，他说看了二遍。据说此书乃设计模式的经典，但我看的很吃力，还好之前看过二本设计模式相关的书籍，不然对于里面写的理解起来更为痛苦。我是不想继续看不下去了，相对而言最近看的另外一书《敏捷软件开发》感觉写得特别好，易读易懂，也非常深入。所以建议如果是初学者换一本书相关书籍学习。如果是高手，或许可以读读。

设计模式---优秀的程序员必读之作

这不是一本第一次就能读懂的书，这不是说本书有多糟糕，只能说明你的水平有多糟糕而看不懂此书。虽然它的厚度令人发指，但你却找不出哪一句应该省略。呜呼，何为经典？呜呼，此为经典也!

设计模式：改善既有代码的设计

23个设计最基础的设计模式，每每读起如醍醐灌顶！不愧为经典之作！创建型1. Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类2. Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示3. Factory Method：定义一个用于创建对象的接口，让子类决定实例化那一个类。Factory Method使得一个类的实例化延迟到其子类4. Prototype：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象5. Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点结构型1. Adapter：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作2. Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化3. Composite：将对象组合成树形结构以表示"部分-整体"的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性4. Decorator：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式比生成子类给为灵活5. Facade：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得子系统更加容易使用6. Flyweight：运行共享技术有效地支持大量细粒度的对象7. Proxy：为其它对象提供一种代理以控制对这个对象的访问行为型1. Chain of Responsibility：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止2. Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作3. Interpreter：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子4. Iterator：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示5. Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互6. Memento：在不破坏封装的前提下，捕获一个对象的内部状态，并在对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态7. Observer：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新8. State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类9. Strategy：定义一系列的算法，把他们一个个封装起来，并且使它们可互相替换。本模式使得算法可独立与使用它的客户而变化10. Template Method：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤11. Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作

我来评评

这本书的翻译完全就是不怎么行，推荐一本英文版的《设计模式解释》，深入浅出，归纳出设计模式的本质就是“抽象变化”，其实万变不离其中

晦涩难懂，不过绝对是好书

第一次看，是刚毕业的时候，根本是看不懂的。不过随着经验的丰富，每看一次都会有收获的。不建议新手看。

我不知道我的想法对不对，请给与指教！

看了《设计模式》这本书，让我有一种做小学生的准备了！我记得我小时候老师总是（记住这个“总是”这个词）让我做着几个算术题：1+1=2；1+2=3；。。。我那时候还想老师这么傻呢，为什么老是让我们做这个有规律的东西呢！接着，到了好像是二年级还是三年级的时候，老师就告诉我们1*1=1；1*2=2；1*3=3；那么1*2是怎么来的呢~，老师就循序渐进的告诉我，在一年纪的时候老师就告诉你了，1+1=2；1+2=3；。。。其实1*2=1+1；1*3=1+1+1；1*4=1+1+1+1。。。所以乘法看起来一点也不复杂啊。于是，我现在想起来，应该感谢我的一年级的老老师了，是他让我把坚实的数学基础打得很牢很牢，即使是1+1=2这么简单幼稚的算术题！那个“总是”一词就是让我们坚持打牢这些数学基础的保证！反过来说说《设计模式》吧，这本书总是告诉有23种设计模式（或者将来还会有人继续增加很好的模式思想），但是GoF并不是一下子告诉你所有的，而是一种像一年级老师一样的老循序渐进的告诉，如果更深的往下学习：先学习工厂模式、单元素模式、观察者模式和策略模式；只有这些基本的模式学好了，才能继续的往下学习。。我不知道同学有没有这个体会，剩下的19种模式都是可以分解成工厂模式和单元素模式来实现的，或者这4个基础模式的不同的组合，就可以完成了剩下的所有的设计模式的搭配，从代码的优美来说，是一种代码的艺术性编码风格！就像是老师一样，让你从1+1=2来学习，让你在无限宽大的未来学习中总是由这个基础来奠定数学领域的上一层学习；所以设计模式中把工厂模式、单元素模式、观察者模式和策略模式基础打的牢牢的，你再仔细的看剩下的模式，你会发现：这些都是非常极致、非常艺术的完美的代码模式和思想者！！

应该读一下

最近刚看完，大师们的思想中无处不闪现着智慧的火花。以前接触过不少开源的项目，其中不少地方不太理解为什么要如此这般，现在回想一下原来如此。感觉看一遍还不能完全理解其中的内涵，以后碰到问题还需要时常翻阅。

感觉很垃圾的书

看到大家都说这本书好，怀着赤诚的心读了一把，发现写的真是晦涩难懂，作者完全没有考虑读者的感受，完全自己在一个尽的卖弄自己的技术，真是垃圾中的极品，真心不建议大家看这本书，我认为，真正的大师，应该用浅显易懂的语言解释深奥的道理，而作者显然没有理解的太深入，达不到这种境界，我知道肯定会有人喷我，毕竟被很多人奉为经典，在那里供为圣经，但不是我一个人有这感觉，我身边不少人都觉得写得很垃圾，相反看了其他的大话设计模式和headfirst设计模式之后，感觉好多了，所以我特意发帖来骂这本垃圾书

精炼 书，应该这样

再一次翻阅——是翻阅 这本书很大的优点就在 当你第一次认真读完之后允许你用翻阅的方式迅速拎起渐渐忘去的内容a nice refined book虽然初读时很觉枯燥——现在也是 书中的例子很多我都没看下去 但是 精炼 都说《深入浅出设计模式》非常优秀，我相信。 几次动念头去深入，却未能深入，总是浅出——不是厚积薄发——还没看进去，姑且说是浅出吧。太厚了，只是喜欢简洁。也许《深入浅出》要表达更多的东西 不过我想GoF现在对我来说已经够了

有些难懂

怎么说呢？这本书是最经典的设计模式。。。可能也是最难懂的设计模式吧。。。我买的是中英对照的，有点亏。。。英文看不懂，去看中文。。。中文看不懂，又回到英文上去。。。看这样的书，很累。。。

没有看过

没有看过这本书。这段时间一直在看《java与模式》，不知道二者有什么相关的东西。看后者的收获是：上面介绍的设计模式虽然自己没有用到几种，但是对自己把握一个程序的架构起到很大的帮助作用。“面向抽象编程”，对于一个程序，从他的基本的抽象类和接口上，就应该能找到他的大体架构，骨架已经搭起，剩下的就是加上血肉了（怎么这么血腥，汗！～）

书很薄。但内容很厚

买了本。扔柜子里了。看了几页。结论。一页顶一本书。以后看吧。现在先把菜鸟的基础弄扎实再说。不难。不过现在用不着。不是说内容不难，而是把难得的东西用很简单的语言描述出来了。经典就是经典。国内的书真的太烂了。至今没看到一本号称经典能比得上国外的经典的。

很棒,很经典

上学的时候看过,当时感觉自己还没资格看啊.现在不知道会有什么体会.推荐一本容易上手的《设计模式：Java语言中的应用》结城浩著.感觉小日本写的书也不错啊.至少不中国的垃圾书强许多啊.

读过次数最多的模式书籍

从大三开始，这本书翻了至少4，5遍，作为经典，其地位和含金量的确不容质疑。但是，正如很多朋友评价的那样，缺点就是很多内容的确比较抽象，加上代码示例是用C++写的，造成很不少理解上的困难。个人感觉是，如果能在了解模式前，尝试去了解一些基本的OO的原则，比如OCP，LSP等，可能对阅读有一定的帮助。