终于拜读完《大话设计模式》了从3.14到3.23，历时十天，终于拜读完《大话设计模式》了。确实，学习设计模式有几种
终于拜读完《大话设计模式》了
从3.14到3.23，历时十天，终于拜读完《大话设计模式》了。
确实，学习设计模式有几种境界，第一种是学习了一两个设计模式，就一直想用到自己的代码中去；第二种是学完全部设计模式，觉得很多模式都很相似，分不清楚它们之间有什么区别；第三种是灵活运用设计模式，就算不用具体哪种模式也可以设计也高质量的代码，无剑胜有剑。
我现在完全就是第二种境界了，觉得她们长得太像了，特别是工厂方法和抽象工厂，还有策略模式之类，昏了。
什么时候才能到第三种境界呢？
我的代码该怎样重构呢？
我为什么没有早点学习设计模式呢？
[最优解释]
曾经在我一开始学习设计模式的时候（那时候我还不会C#，用的是VB），我梦想用设计模式编写那些极端通用的，可重用的软件（GoF的设计模式副标题也是这么说的），那时候我经常指着我的代码对别人说，你看，我只要在配置文件里面修改下，我的程序就可以适应不同的需求而不用修改！但是后来我突然惊讶地发现，所谓“极端通用的程序”其实就是在创造DSL。或者简单地说，就是编写一个核心，用配置文件实现装配，配置文件相当于一种领域编程语言，而我的程序核心相当于这种语言的解释器（XML API相当于词法、语法分析器）。
我为什么要费力编写一个脚本语言的解释器呢，当配置文件复杂的时候，程序的配置出现了困难——配置文件的配置方法（市面上的所谓介绍Hibernate或者Spring的书，实质上是介绍配置Hibernate、Spring等等如何编写配置文件的书）的复杂度难过了编写程序——很多小公司为什么总是发明ORM或者IoC框架就是这个道理。
所以，动态的、脚本化的、交互的语言会在这几年突然走红，比如Ruby或者Python，甚至Lisp这种上古时代的语言都重新出山。你不是说程序需要修改吗，我直接修改源代码好了——源代码就是配置文件。
说这些是什么意思呢？其实软件的开发方式在经历一场翻天覆地的变化，那就是程序设计语言已经发展到可以随心所欲地表达程序员意图的程度了。而设计模式也好、重构也好，它们的本质是为了当时软件开发的需要——在那个时候软件生产效率低下，设计和编码是分开的——似乎架构师负责那些“宏观”的设计，程序员负责将设计细化成代码。设计模式的本质是为了避免设计的改动造成代码的重写。所谓重构就是根据代码优化设计。而现在的主流已经淡化了设计和编码的界限。设计就是编码，编码就是设计。程序中没有那些为了实现设计意图而出现的硬编码，程序代码本身既是体现架构师设计意图的说明也是直接可以运行的程序。这是设计模式消亡的根本原因。
以前一个典型的项目组可能是这样的，一个“架构师”+10个程序员。现在架构师自己就能操纵整个程序，程序员呢，下岗了。当然你也可以说，现在的程序员必须懂得架构设计，否则它会在和工具改良的竞争中被淘汰。这就好比以前蒸汽火车的司机一般要3~4个人组成，两个人添煤，一个人看信号，一个人驾驶。后来换成内燃机车，变成两个人，一个人看信号，一个人驾驶。后来的电气火车实现了计算机自动控制，那个看信号的也不需要，只需要一个人驾驶了一样。
[其他解释]
如果有人拿着代码,或者说基于代码来说什么设计模式,
那我很难有耐心讨论如何设计,
即便一个人同时扮演多个角色,也要时刻分清楚自己处于哪个工序;
学习软件设计不能站在程序员的角度,
走到别的任何一个行业去看看设计,都比软件设计来的成熟,都能从中汲取到大量的经验,
比如动画设计(比如:故事本,原画,动画),服装设计(比如:设计,制版,打样);
微软这种技术大腕挂着各种大小新技术走秀的时候,程序员只会照葫芦画瓢的在代码中使用这些技术,
而设计师的眼光截然不同,他们看到.net就能想到MVC,看到DSR,就能想到RuntimeAssembly,这样的设计思路没有一个和具体的代码相关,
当设计师开出工单,程序员哪怕用最笨拙的语句去实现,他们也是实现一个高级的设计
[其他解释]
达芬奇画鸡蛋有用的话,全世界都是达芬奇,
你去看看动画设计,最有技术含量的是storyBook,就是我说的故事本,
那个工序不需要你是个画家,甚至不需要你会画动画,
你只要具备最基本的绘画技能,就能表达你的设计思想,
这就是设计文档接口,以后,原画,动画,修形,上色,布景...等等工序都遵从这个接口
[其他解释]你应该学一种主流的程序设计语言。对于C#来说，C# 4可以部分满足这样的要求。当然，我觉得Python、Ruby或者用这些语言创建的DSL更好一些。
如果在10年前，也许你不得不学UML，因为那时很难找到一种可以抽象到忽略所有细节直接表达用途的编程语言。
[其他解释]张三丰问张无忌“你明白了多少？“
张无忌学“我忘了一多半”
其实设计模式就得这么学，忘的越快越好。心里只需要记得那七个“设计原则”就好了，其他的你能忘多快就忘多快把
[其他解释]所谓设计模式，就是人肉展开高级语言成低级语言的形式。
所以C#几乎用不到设计模式。大部分设计模式已经蜕变成正常书写的代码了。
[其他解释]我也很喜欢这本书。。很通俗。。很好玩。
[其他解释]我附带解释一下我1楼的回复
千万别把我1楼说的当“无招胜有招”，这会被人批为“还没学招就直接奔无招”了
我1楼所说真正的含义是要把设计原则当招，而不是把招当设计原则
[其他解释]策略模式就是一个典型的C#不需要的模式。因为C#支持委托，更进一步，C@支持匿名委托、Lambda表达式。
如果你看到这样一行C#代码
var query = data.Where(x => x.id == 1).SingleOrDefault();
我告诉你这就是策略模式，你不要感到吃惊。
这个代码转化为C# 1.0需要这样展开：
SomeType query = data.Where(new ADelegate(querymethod)).SingleDefault();
...
delegate bool ADelegate(SomeType x);
bool querymethod(SomeType x)
{
return (x.id == 1);
}
如果转化为Java（Java没有委托）是这样的（我用C#语言表示，使用接口）：
SomeType query = data.Where(new MyQueryMethod()).SingleDefault();
interface IQueryStrategy<T>
{
bool Invoke(T x);
}
class MyQueryMethod : IQueryStrategy<SomeType>
{
public bool Invoke(SomeType x)
{
return (x.id == 1);
}
}
假设Where()这个查询内部是这么实现的：
IEnumerable<T> Where<T>(this IEnumerable<T> data, IQueryStrategy<T> where)
{
foreach (T item in data)
{
if (where.Invoke(item)) yield return item;
}
}
你看看是不是就是策略模式。
[其他解释]
所以设计模式就是一些奇技淫巧而已。那些连基本语法都没有掌握的人以为设计模式是“改善设计”，“提高开发效率”或者“使得代码更好维护”的捷径实际上只能是一厢情愿。
[其他解释]
所以设计模式就是一些奇技淫巧而已。那些连基本语法都没有掌握的人以为设计模式是“改善设计”，“提高开发效率”或者“使得代码更好维护”的捷径实际上只能是一厢情愿。
[其他解释]
砒霜是毒，用好是药，用不好是毒
[其他解释]
lz买的书还是？
[其他解释]
设计模式是用来解决设计问题的，没有设计何来设计模式......
[其他解释]
这个解释太给力了...
[其他解释]大话设计模式我也看了几章，但是木有看完，看到后面就混乱了。等我再强大一点再去接着看完把。
[其他解释]没想到我的帖子还能有大神来回复,不胜荣幸.
不过您的观点我不敢苟同,确实现在语言做得越来越完善,有很多设计模式已经嵌入其中,比如foreach用的迭代器模式,但这只是设计模式一个很小的应用.设计模式主要解决的是软件系统架构的宏观层面的问题,而不是具体语法如何实现的微观问题.所以我觉得学习设计模式还是很有用的.当然这是对我们这些面向对象的菜鸟来说的,完全不用模式,程序一片混乱,不便于扩展也不便于修改.而对于您等技术牛人来说,本来就是无招胜有招了,当然不用设计模式了.
[其他解释]买的书,惭愧的是放了一年多才认真看完...
[其他解释]所以正常踌躇中
[其他解释]设计模式都是解决“宏观层面的问题”？那你简直白学了。GoF早就给设计模式作了分类，这个分类写在GoF那本《设计模式》的目录里面，我想你什么都不看，目录看看总可以吧。
还有设计模式可以解决“程序一片混乱”的问题么？你在哪一本书当中看到作者有这样的承诺？这就好比烹饪方法没有把腐败的食物变得新鲜的功能一样。
[其他解释]新鲜的食材是烹饪技巧运用的前提。
设计模式的前提是，你的编码本身过关，“设计”才有意义。否则设计来设计去，只不过是把浆糊又搅拌了下而已。
------其他解决方案--------------------
所以正在踌躇中...
上面写错了，奇怪的是自己写的居然不能编辑，这是什么模式？
晕，一个用户中允许连续回复三次！！！
[其他解释]谢谢您耐心的解释,思索中...
[其他解释]但是不管技术如何进步,基础总是要打的,模式要学习,但是不能依赖,您不也是经过了学习-使用-升华的过程,只不过有您的指导,可能我们完成这个过程的时间会短一些.
[其他解释]设计模式指的是生产方式,与代码无关,
重构就是一种设计模式,它的职责是扩展已有的设计,为企业库增加新的或者更高效的生产能力,
绝不会修改以前的代码
我绝不认同马丁福勒所说的那种"重构",充其量是对垃圾代码的改造,那种行为本身就不符合SOLID或者MVC设计思想,也就是不符合面向对象的设计思想
[其他解释]确实,设计模式只是前人的经验总结,学习他就是照葫芦画瓢,但是你能学达芬奇画鸡蛋没有任何意义吗?
[其他解释]就这一句，我觉得就没必要再讨论了，因为偏题了。lz说的“设计模式”虽然没有特指什么，但是显然说的是《大话设计模式》这本书，进一步地说，是GoF的设计模式。如果你一上来就把这个讨论的范围给修改了，那还讨论什么呢。
如同lz问什么早点好吃，你一发言就是，早点还可以表示earlier。然后谈论我们早上要起早点，不然会迟到，晚上少看电视，早点睡觉有利健康……没错，你说的都对，但是你说这些干吗呢？
[其他解释]有道理,谢谢,但是什么是我的storyBook呢
[其他解释]如果要是可以随便改动讨论问题的前提条件，那么胡说八道也是对的。
我说太阳从西边升起。怎么，不同意？我就解释啦，谁说一定是在地球上看到的？我在金星上，那里自转是相反的，所以太阳从西边升起。
[其他解释]Thank you
[其他解释]有一点是肯定的，那就是随着工具的改进，那些平庸的、注重形式的、人海战术的、拘谨而不思进取的开发者以及企业将很难生存下去。因为一个看似井井有条按部就班的团队（创业公司们将他们称作“委员会”），内部暗藏着巨大的拒绝变革的力量。
[其他解释]当然了，最关键是你的想法。这种想法越抽象，就越难以从具体的学习中获得。这就好比李白醉酒诗百篇，诗歌相比较小说、传记、杂文来说，前者这种近乎白描和粗犷的表达形式更难以从大学中文系中学习到。
[其他解释]该回复于2012-03-26 08:46:47被版主删除
[其他解释]设计模式的大话，去了解下他的一些思想还是有利的啊，现在随着工具的改进，并不需要依造那么所谓的设计模式去画瓢
[其他解释]嗯,谢谢两位谆谆教导,结贴了.
[其他解释]这是一种设计模式,生产模式,
storyBook用一种敏捷的,客户,导演,开发者都能理解的方式图形化的描述了剧本(的需求),
大家都能看到作品(产品)的原型,进一步更加精确的确认需求,
要知道以目前动画领域的落后的生产手段,一旦返工,代价是巨大的,
在这一点上,和软件开发极其相似
还有,你可以看看<喜洋洋>,那是组件化设计的典型作品,那种设计模式几乎彻底节省了动画(补间)工序,
[其他解释]
搞清楚oop即可，何必非要硬套什么设计模式
[其他解释]
这本书却是写的不错，
[其他解释]
嗯,学习了!
[其他解释]最近刚读完,感觉收获挺大的.刚写完一个项目,上万行代码吧,被老总骂了,代码写的一团糟啊.接下来要看一下敏捷软件开发,试着把自己的程序重构...
[其他解释]设计模式之禅也不错。
[其他解释]至今不懂设计模式在干嘛的
[其他解释]很不错吗。
[其他解释]没有读过，不过听人说过这本书、
[其他解释]楼主说的工长方法和抽相工厂，其实根本一点都不像 。他跟模版方法倒有些类似，通常一起用
c#中有些设计模式是已经集成的。比如说事件和委托代替了观察者模式
[其他解释]名词太多了。
[其他解释]我也很喜欢这本书，不过在项目中不要刻意的去用某种设计模式。一般是当你写完了，回头一看，靠，这不就是某某设计模式+某某设计模式么。(*^__^*) 嘻嘻……。
[其他解释]感觉我跟楼主一样，在第二部徘徊，感觉怎么都长得差不多
[其他解释]在哪去看看
[其他解释]现在一想起设计模式这个初恋来， 真是五味杂陈， 不说也罢， 不说也罢。
[其他解释]俺也喜欢这本书。。。
[其他解释]我也是这几天读了《大话设计模式》这本书，这本书确实写的很好。他总是能把那些生涩的东西尽量转化成我们感兴趣的话题。
读完之后除了剩下自己写的读书笔记之外，似乎什么都又还给作者了。但还是有些简单的思想挥之不去的，比如写出来的code尽量能复用，易维护，并不是效率高，能跑通就好了。
[其他解释]null
[其他解释]给力！顶啊
[其他解释]我也在看这本书，开始看的是电子版的，感觉很多东西需要慢慢的琢磨，就买了一本实体书。
说一下我们的开发状态，纯粹的就是手工作坊，一人一个版本的软件，没有任何的复用啊、结构啊的概念，做一个软件能累半天，我感觉设计模式是必须要看，要学习，要掌握的，虽然没有必要去照葫芦画瓢，但是如果能用在自己的代码里面，把过去的代码翻出来看一下，看看那些能改进，这样人才能有进步。
虽然现在的语言已经实现了很多设计模式的思想，但是很多功能性的东西还是要靠代码去写的，大块性的功能如果能用上设计模式，肯定开发效率要高很多！
