关于模式的思考
长久以来，我们对于模式这一九十年代面向对象编程领域的最重要进展，处于一种蒙昧无知的状态。中国在计算机软件开发领域上的落后现状、主体开发人员的缺乏工程实践、语言与知识产权上的壁垒，造成了这悲惨的世界。
感谢机械工业出版社给我们带来了第一本关于模式的著作即四人帮的《设计模式》，但是，非常可惜的是，由于此书的精彩和对解决实际问题的务实态度，再加上其在国内完完全全的垄断地位（很长时间内，关于模式没有新的书籍被介绍进来），造成四人帮的观点从它被宣传的第一天起就占领了全部我们可能认知的模式知识空间。
四人帮的观点并非存在着什么重大的问题，只是由于人的接受能力有限，再加上从英文到中文的转换过程中，很多东西就会莫名其妙的变质，以至于当我们把这些变质以后的观点应用于实际的工作或是真正和那四位作者对谈的时候，就会发生很多可笑的事情。
我们注意到无论是四人帮的著作还是最近机械工业出版社出版的面向模式的软件体系结构一书，都提到了亚历山大的《建筑的永恒之道》，正是亚历山大在这一本书中第一个提出模式语言的概念，并且深入细致的阐述了模式的由来和模式做什么以及模式之后的事情。但非常可惜的是很多学计算机的人因为专业的倾向，并没有把这本《建筑的永恒之道》拿来细细的读上一遍。
最近看到有一本由几个号称青年程序员写的一本论软件工程的书，还把方正研究院的院长先生请来作序。书中充满了艺术情结，并拿出自己有限的编程经历中的一些事情来作为佐证。通常我对国内的计算机书籍的作者都无甚好感，除开几位大牌之外。这一次也不例外，只不过，同为写程序之人，有一些他们在字里行间隐约谈到的东西，我大约也能感受得到，但总觉得不是那么回事。不过，当我看到《建筑的永恒之道》的第一章时，一下子豁然开朗起来，不错，这个就是所谓的无名特质。（很可惜，这个优秀的译法没有在《面向模式的软件体系结构》一书中应用，本来还很想极力推荐大家去看这本书，考虑到此书的翻译实在有扰乱视听的嫌疑，所以还是推荐大家有选择的看看好了。）所谓无名特质到底是什么呢？它是我们在做好一件事情或者是看到一件好东西或是受到某种感动的时候，存在着的某种东西，它并不存在一个实际的表现形式，但有上述的事情发生的时候，它就在那里，而且你可以感觉到它。但是以我浅陋的水平而言，继续就无名特质进行讨论一定会产生扰乱视听的效果。但是，还是要赘述一句，为什么会有模式，就是因为有无名特质的存在。
所以我有一个观点，模式是从自己的体验中来的。怎么说？因为无名特质并不在大师那里，而是到处都有，你看不见它，是因为你违背着自己的天性，并且你害怕服从自己的天性。而当你希望克服这种害怕的时候，你所能采取的方法依然只能是远离无名特质的。
拿写代码来讲，写得好的代码是自然流畅的，你可以从中感受到创作者是如何进行思考的，而不需要借助太多太多的文档和注释。但是，当你远不够成熟，不能发现自己的天性，不能遵从程序代码的天性，不能顺利的融合二者的时候，你害怕随心所欲的编写代码，又无法完全遵从程序二值逻辑的天性的时候，你开始遵循一个别人制定的异常严格的编码规范，而最后丧失了自我的天性，开始写出印度中学生的代码，并以此为傲，说自己的工程化做得好。这绝对不是软件开发者的永恒之道，这是乡下泥瓦匠的生存之道。
所以，当你真正的面对自己，通过模式语言来汲取前人的经验，依从自己的天性来应用二值逻辑的时候，也许模式应用的大门才开始敞开。
坊间还有一个观点，即应用模式即应用前人的经验和思考，可以减少自己对具体问题的思考，而团队应用模式，可以让开发更加规范化，更加标准化。同时对应的还有一个反面的思考是既然大量的应用前人的经验和思考，就意味着大量的应用模式将减少创意的产生，同时由于其普遍适用性，应用到处理一些极其简单极其具体的问题的时候将大大降低效率。这两个观点在过去的我而言，确实是值得赞同的。但在今天，应该说不。
模式的应用，其核心是由于无名特质的无处不在，它总在这里那里以这样或那样的形式表现出来。所以当要应用一个模式的时候，首先思考的是当前的语境中，无名特质是怎样体现的？在这个似曾相识的语境中，无名特质的表现是否依然如故？语境似曾相识，但实际却天差万别的事情不是没有，亚历山大从始至终都在告诫大家这一点。模式应用，要思考的事情不是少了，而是多了，不是浅显了是更深入了。既然思考更加深入，那么创意的增加是很自然的事情。那么，是否因为普遍适用性而降低效率呢？答案显然也是否定的，因为在这件最具体最简单的问题上，也存在着无名特质，如果因为应用了模式而导致了效率的降低，这件事情是违背问题的天性的，因而也就不是模式的正确应用。也许是识别了错误的模式，也许是模式之间的关系不正确，也许是。。。。。。不一而足。
那么，既然模式如此之好，那么我们是否应当努力学习，并且推荐大家去学习呢？答案是不一定，就象学武术，如果根基不打好，学招术就是花巧工夫，碰到个体力扎实点的一样完蛋，如果学了招术不去活用，要生搬硬套，那遇到高手一样要落败。我的看法，如果没有十万行以上的代码经验，对代码的天性是完全没有体会的，对自己的天性也是完全没有体会的，这种情况下来谈学模式，唯一的意义是填鸭式的强记，以后功到自然成。然后如果是真正的高手，也许有自己的模式可谈，那倒也不必去强学四人帮那套东西，完全可以提出来大家传播，因为大道无名，大道无形啊。
看起来上面的文字还是有混淆视听的嫌疑，大家将就看吧，作为一种观点而已。
问题点数：10、回复次数：81Top
1 楼ozzzzzz（希望敏捷）回复于 2003-01-11 22:49:38 得分 0
建筑的永恒之道 翻译的好极了 写的就更加的棒 可惜我们什么时候能有这样的翻译
但是对作者的一些说法表示不太赞同 以后组织好再来贴Top
2 楼xiaodaoren（*）回复于 2003-01-11 23:38:41 得分 0
要看看！Top
3 楼lizongqi（英雄啊）回复于 2003-01-12 00:37:06 得分 0
看看Top
4 楼kangheshui（）回复于 2003-01-14 20:27:11 得分 0
同感，刚开始一头雾水，后来发现原来自己的程序中不知觉的已经应用模式了！哈哈。神仙不过如此！Top
5 楼Schlemiel（维特根斯坦的扇子）回复于 2003-01-14 20:54:26 得分 0
楼主的观点的确只能作为一种观点而已。“模式是从自己的体验中来的”、“无名特质的无处不在”，这种话只能拿来唬人而已。难怪ozzzzzz这样的老家伙要跟你有分歧了，因为你唬不住他嘛。建议你还是不要拿这种东西出来唬人。《建筑的永恒之道》好看归好看，如果看完了还是要自己去悟道，不是跟没看一个样吗？Top
6 楼libi（风自吟）回复于 2003-01-14 21:45:20 得分 0
呵呵，有点意思，把纯技术的计算机提升到哲学的高度。
我对模式也有同样的看法。书本上的模式只是具体的“形”，而真正重要的是这些形所体现出的“义”。不过我们体会“义”还得从“形”入手，但不可为“形”所束缚。
“无名特质的无处不在”，与自相似理论相近，不过我对此并无楼主的把握。
有一点不太愿意同意，学习模式要有十万行以上的代码经验，我连1K都没有，这不是一棍子把我打死了吗！！！Top
7 楼ozzzzzz（希望敏捷）回复于 2003-01-14 23:48:17 得分 0
我不知道如何表述无名特质 不是我不知道它是什么 而是我不知道怎么表示它不是什么 当你在那优美的图片中的时候 你自然就知道那里就有无名特质 当你在这高耸的都市丛林中的时候 你就知道这里没有 我们完全不需要理论 单单凭我们的直觉就可以解决 而当我们上升到语言需要表述时反倒成了困难 但这决不是道可道 非常道 因为无名的特质已经被明白无误的表示出来 也同时可以让你看到它的反动
回到GOF上来 我不知道有多少人觉得GOF晦涩无比 但是我知道有这样感觉的人 一定是那些没有面向对象思维的人 模式是一种在千百人工作的积累基础上现实存在并被发现的东西 不是被什么大师发明出来 而是被他们体验出来 大师已经把体验作出了报告 我们如果也延着他们的道路走下去 我们一样会遇到那个场景 我们一样会发生很大师当时同样的感受 但是为什么我们没有 我们不理解 就因为我们没有走在大师走的面向对象的路上 我们一直在面向过程的路 所以你即使写过1000k的代码 只要你不走面向对象的路 你就不会感到有会心一笑的感觉 你就体会不到那种痛快淋漓的美 你可以看看自己的周围 往往是年纪越大的人对面向对象理解越困难 因为他们的习惯代替了他们的本心 高展先生在中国很有市场就是最好的例子
合理使用设计模式肯定可以减少我们编程中的种种麻烦 也不会减低我们的创造力 但是事情往往不是你创造了什么 而是你完成了什么 只要你完成了你的目的 创造了与否没有关系 我到宁愿我们都收起我们的创造之心 按照程序本来的结构自然流偿的进行 有句俗话人类一思考上帝就发笑
可是合理这个词汇很模糊 我们怎么该如何知道该怎么做 我们不思考是不可能的 但是我们完全不必要去思考那些已经被多少人思考过的事情 因为我们时间紧迫 那我们思考什么呢 我们应该思考的是什么时候不使用设计模式 也就是大师按照无名特质建造了城市 我们应该思考我们怎么做才不会破坏那种无名的美 我们最应该解决的是反模式 因为我们是凡人 我们需要法律告诉我们禁止做什么 这就是我们的目标 大师创造了宗教 我们来创造法律
学习设计模式吧 越早越好 它可以告诉你大师是怎么思考的 可以告诉你面向对象和面向过程是那么不同 告诉你接口是那么灵活的结构 告诉你组合而不是继承才是我们最有利的武器 它会让你知道世界是无数的对象构成的 一切都是对象
无名特质不是无处不在 它存在的地方不多 就像存在无名特质的美丽城市在世界上不多一样 所以与其在黑暗中寻找 不如在光明中探求 与其思考如何把丑陋的都市变成美丽的天堂 不如在美丽的田间耕种自然Top
8 楼ozzzzzz（希望敏捷）回复于 2003-01-14 23:49:09 得分 0
http://www.webendshere.com/javapatterns/faq/faq.html#tech3
看看xp和重构的提出和模式有什么关系吧Top
9 楼cccc2002（cccc）回复于 2003-01-15 08:45:45 得分 0
不懂得用前人总结出的和自己发明的模式的程序员永远大概就只会coding了吧
用模式的最大目的，是将结构上的清晰和合理视为最重要的，一个好的结构确定
下来了， Coding得再烂也好改，就怕是一个烂的结构那就是万劫不复了Top
10 楼stonespace（stonespace）回复于 2003-01-15 12:13:41 得分 0
我看得一头雾水。
我不相信在技术领域，存在无法精确定义，而且又有价值的东西。不过贴主所说的“存在着的某种东西”，我的确能够感觉到它的存在。
后来我想明白了，所谓的“无名特质”如果真正存在的话，它就是模式本身，当我们成功解决某个问题并且有所感受的时候，说明我们体会到了这个解决方案之所以成功（完美）的本质，并且已经意识到在其他地方可以应用这个解决方案的某种成分并且重复当前的成功，实际上就是我们已经把模式识别出来了。只不过这个时候，我们还没有把模式用语言描述出来，模式好像是一种模糊和无法表达的东西，但是它和GOF描述的那些模式没有什么不同。
无名特质不是无处不在---等于说模式无处不在，这个我完全赞同，模式是我们思维的基础，不利用模式我们根本就无法进行理性思维，连最简单问题例如如何搭车上班都解决不了。
一个例子，到一个新的城市出差之前要做哪些准备工作，虽然很复杂，但是对这个问题我们并不需要思考就可以列出该做哪些事情，很明显，解决方案来源于过去成功的经验，虽然每次出差要去的地方不同，具体任务也不同，具体准备的事务也不同，但是我们能够用相同的方式解决问题，实际上就是模式。
有比如，在碰到一个新问题的时候，必须创新的时候，我们还是使用惯用的步骤，分析原因、识别解决方案的线索、最终构造解决方案，每一次都使用大致相同的步骤和方法，即使是创新也离不开模式。
人的思维的基本方法是：抽取模式/应用模式，离开这个方法我们什么问题都解决不了。
关键问题是模式是否能够用某种语言清楚的描述出来，如果能够，则可以在不同的人员之间共享经验。如果一个小组中可以彼此理解对方的思路，这种默契来源于相同的模式。
另外一个关键的问题是，模式有“美”和“丑”的区别，一个人如果做出一个很烂的设计或者很烂的code，其实他也应用了模式，是他的经验，因为没有模式根本就不可能做出任何东西，我们看那些烂的东西，他们也存在很多共同的特点。烂的东西来源于“丑”的模式。
所以我的结论是应该尽早学习模式，如果书上的模式比我们自己的模式要好，用它来更换自己的模式，以后的解决方案肯定会更完美。
另外所谓的体验，不过是从具体的解决方案中抽象出成为“完美”的本质部分，我认为没有必要把它神秘化，可以找到某些方法使这种“体验”更有效。
Top
11 楼mis98ZB（Effective Typer）回复于 2003-01-15 12:41:51 得分 0
嘿嘿，
无名特质，好玄幻的名字啊……
它和本质（essential）的区别是什么呢？没有名字？Top
12 楼mis98ZB（Effective Typer）回复于 2003-01-15 12:59:48 得分 0
模式还是要学的，但是只学会几种模式是不够的。
为什么要使用这种模式？怎样使用这种模式？都要弄清楚。
这种东西才是本质。
正如你在大学里学的微积分、空间解析几何可能在实际工作中用不上一样，
四人帮的模式也可能对你工作的内容没有任何直接的帮助；
但是也正如经过成千上万的数学题锤炼的严密的逻辑思维一样，
关于低耦合高内聚功能分布的思维定向时时刻刻都在帮你把事情做得更好……
Top
13 楼zmzy（zmzy）回复于 2003-01-15 16:47:10 得分 0
道可道非常道，名可名非常名Top
14 楼IQ777（）回复于 2003-01-15 18:32:43 得分 0
和本体论同质Top
15 楼mycode（不写代码）回复于 2003-01-15 20:04:55 得分 0
记得初看设计模式的书时，就有人说过，模式的使用有三种层次，第一层是学习理解模式，第二层次是将模式应用具体的实践中，第三层次就是在模式的基础上进行创新，总结出自己的模式。
如果我们在开发系统的时候，发现自己的设计，符合某种成功模式，表明我们正走上了一条通向成功的道路，我们无意中追随了巨人的脚印。当我们设计新的模式时，表明我们正开拓一条新的路，当它取得巨大成功时，才能表明，我们为别人又提供了一条路。
而实际，也许我们自己设计出一种模式，以为它是新的，其实是在别的软件系统中早就已经使用了，但由于它没有被总结或者推广出来，你不知道而已。提醒我们不要太高兴。Top
16 楼ningIII（小宁）回复于 2003-01-15 20:20:42 得分 0
不大明白在讲什么……
我不知道中国的高手有多少，我只知道中国人写程序很不怎么样！
总是想发挥自己的个性，结果总是问题多多。
事实如此，我不知道我的方向在哪里，我只想生活……Top
17 楼w_rose（w_rose）回复于 2003-01-15 21:04:44 得分 0
“把纯技术的计算机提升到哲学的高度”——如果哲学与科学相悖，那要哲学有什么用？Top
18 楼twinsant124（蚂蚁的天空）回复于 2003-01-16 10:00:54 得分 0
mark
Top
19 楼jhshen（喝水也会胖）回复于 2003-01-16 10:29:44 得分 0
学模式就是学习怎么去思考一个问题Top
20 楼adwork（春夏秋冬）回复于 2003-01-16 11:19:00 得分 0
我现在头脑很疼，看得也稀里糊涂的，但感觉挺好，有空的话还要再看看
感觉写得有些乱，但感觉还是有些内容的Top
21 楼wangjx71（wangjx）回复于 2003-01-16 13:23:54 得分 0
学习！Top
22 楼zhaoyifei1（一非）回复于 2003-01-16 17:38:17 得分 0
upTop
23 楼wanderfellow（英语乞丐）回复于 2003-01-16 18:01:49 得分 0
不错的东西，我翻过，但是还没有好好的看看，好东西是要慢慢品尝的...Top
24 楼smartghost（榴莲居士）回复于 2003-01-16 18:09:23 得分 0
模式无处不在，但不是所有的模式都值得总结。
理解模式需要一定coding经验，难以想象1K代码经验的人能学好模式，就象难一想象才爬两天路的孩子能跑一样。但不是所你不要学习模式，只是说你不要抱太大期望去理解它。所以如果你只有1K代码经验，那么你继续爬行吧。
凡是披上哲学外衣的东西都要让人摸不着头脑，对软件讲哲学是不是一个歧途？
下班了，当我编码编到头脑发昏的时候，什么都不想思考。
Top
25 楼GOUSHIJIE（）回复于 2003-01-17 09:41:50 得分 0
建筑的永恒之道 翻译的好极了 写的就更加的棒Top
26 楼mmyytt_2000（小马）回复于 2003-01-17 10:04:02 得分 0
模式是基础，复用是关键，剪裁创新是关键。Top
27 楼mmyytt_2000（小马）回复于 2003-01-17 10:05:12 得分 0
（敲错了）模式是基础，复用是关键，剪裁创新是核心。Top
28 楼twinsant124（蚂蚁的天空）回复于 2003-01-17 12:49:30 得分 0
Li er hou po zhi, dao zhi da chen ye.Top
29 楼lifr（lifr）回复于 2003-01-17 14:18:41 得分 0
我对模式的理解就是"比较通用的算法".当然这里的算法要更广泛的理解
面向过程的算法是数据结构和加之于上的操作
面向对象的算法是"对象"和对象间"相互关系".
对象和对象间的关系五花八门,但仍可抽取出模式这种具有通用性的算法.运用模式的能力就是对算法抽象的能力.
我想不出还有比c++的"模板"更有力的描述通用算法的武器
所以,stl库使用模板实现了最基础最通用的算法.据说loki库尝使用模板来实现模式这种通用算法,我认为这是个天才的想法.
模式适用于很多地方,这一点相信没有人有异意,所以有一天你也许会使用一个通用模式库,或许不是用模板实现的,但肯定是一个更好的描述通用算法的技术.
我强调一下我要表述的重点: 模式即算法.并稍微做一个预言:面向算法的设计方法会得到重视.
Top
30 楼arfayr（阿飞）回复于 2003-01-17 15:17:44 得分 0
总觉得楼主有点哲学味道
0zzzzz说得很有道理，其实说这些那么玄虚的理论作什么？自己在开发，在应用模式，应用模式并不是让你按照它去做，更多的时候我想都不适合模式一模一样的吧，不同的问题不同的应用模式肯定有不同的特点，只不过本性一致。
想起令狐冲练独孤九剑老是练从小练熟的一招剑法，以为不对，一直想忘掉这招剑法，后来才发现，其实独孤九剑，剑随人心，有招无招不必苛求。模式也是吧，不要非的按照它做，不要非不按照它做，明白了这些模式的内涵，你的出招也就处处是模式的精髓了，也正应了独孤老先生的剑法精要。
模式是思想是精髓是经验，而不是规矩。个人认为模式非常值得一学，只有站在大师的肩膀上才能够看得更远。Top
31 楼yayong（鸭泳）回复于 2003-01-17 16:29:20 得分 0
模式的价值就在于是前人的经验和智慧的结晶
学习肯定是有价值的
但是应用起来要小心
做设计之前，除非很有把握，否则宁可用最简单直接的设计
不为了应用模式而增加无用的代码
所以我比较信奉XP的哲学，简单的设计---持续重构
也学在不断的重构之后，你会发现，这不就是你想要的模式吗？Top
32 楼hefangdotcom（我的帅惊动党中央）回复于 2003-01-17 16:43:29 得分 0
太玄了吧？
你这里误导小青年，觉得很满足是吗？
你把模式那点小伎俩耍得那么玄，有必要吗？
模式都是些不言自明的东西，有人总结出来了，就不要去追究根底了；好比最初有人发现了对称美，你非要再从人体的对称结构去解释一番，或从地球的自转去解释一番，有必要吗？
Top
33 楼Carven（Carven）回复于 2003-01-17 17:39:14 得分 0
我本来只是在写读书笔记，想拿出来和大家分享，发现我的观点的不足之处，然后予以改进，却偏要有人说我是误导小青年。我前面就说了，没有个10万行，不要来谈模式，如果有了10万行的人还不能明鉴我这里的文字都是我的一家之言，是拿来大家讨论的，而要受了我的鼓惑，去穷究编程之道里面的哲学问题的话，那也不是我所希望的。
说到编程之道里面的哲学问题，我认为一定是有的，但是我个人之力无法把握，但是如果说因为无法把握就不去探求，我觉得也不是正确的做法。要去探求哲学问题，然后丢掉了实践的基础，那也是非常教条的。讲了半天，这些不都是废话么？所以说大道无形大道无名啊。
举一个浅显的例子，大凡写程序久的人一定都教过别人写程序，一定遇到过悟性好的学生和悟性不好的学生，大家想象一下，那种面对一个就是听不明白的人，你空有满腹诗书却也报国无门的着急。你是不是在想，为什么他总也听不懂呢？他怎么会想不到这一层呢？你只好说，有时候，学写程序，只可意会，不可言传。不要说模式这种新东西，就是C语言这个老得掉牙的东西，还是有很多时候不可说。
什么是不可说，什么是不言自明，看起来都是叫我们不要讲，但前者是因为很深奥，不是浅显的思考就可以了解，后者是直观得无须说明。Top
34 楼liujiangshan163（羊羔）回复于 2003-01-17 21:06:45 得分 0
废话！
你还不如把你作过的项目给我们分析一下
什么悟性，屁话
你愿意象 〈深入浅出MFC〉的作者一样愿意让大家进步，而不是
怕大家超过你，夺你的饭碗，
哈哈
Top
35 楼libi（风自吟）回复于 2003-01-17 21:27:59 得分 0
Carven(Carven)说的有道理，因为对软件的理解有差异，所以沟通非常重要，所以软件通常只有少数几个人来“生产”，所以模式才重要，因为它可以将大的模块解耦为小的模块，才能由少数人分别独立完成各自模块，以减少沟通的需要量。
1K代码量确实太少，但我已经没有机会接触太多代码，这也是我的遗憾。但是模式对我来说，理解并不困难，只是缺乏体会，没有把握。这种感觉确实不好描述，所以你们不一定明白我的感觉，这也是一个沟通困难的问题。还是举个例子来说吧。
《三国演义》中，官渡之战时，曹操粮草快没了，想撤军。此时，荀或上书分析一大篇，结尾说此生变之机，当坚持下去，最后大破袁绍。《长征》中，红军四渡赤水，有人问毛回头有生路吗，毛只说有机会。这些决策都是战略性的，经历过多次战役的人可以做出这样的决策，如果学过很多理论知识，也许我也能做出这样的决策，但是我决策时并没有必胜的把握。对于模式，我就是这样的感觉，缺乏经验，没有把握，但尚可理解。所以我对诸葛亮在火烧博望坡中表现出如此的镇定感到万分的诧异（呵呵，这是题外话）。Top
36 楼legendcn（吉品黄山）回复于 2003-01-17 22:24:19 得分 0
楼上同志讲的很精彩，引经据典，佩服，不知可否做个朋友Top
37 楼zzzl（不拉拉链）回复于 2003-01-17 22:28:52 得分 0
模式嘛，怎么搞得这么复杂~!Top
38 楼legendcn（吉品黄山）回复于 2003-01-17 23:08:56 得分 0
Carven 同志讲的我也有同感，所谓“无名特质”应该是老子所谓的道。
其实任何的行业或者职业都有道的存在，一番经历之后总会深有感触，
但道是无法说清的，只可意会不可言传。编程也绝对是一门艺术，从入门开始，
一步一步层次精进，对编程的理解越来越深，而且也逐渐形成了自己的风格。
当回首来时路，确实有一种居高临下之感，似乎若有所得，但却无法捉摸。Top
39 楼lizongqi（英雄啊）回复于 2003-01-18 09:42:09 得分 0
up一下Top
40 楼tfp（tfp）回复于 2003-01-18 10:54:40 得分 0
哦，这么复杂
我对程序、计算机的理解个人认为最深刻的是在大二
虽然那时候写代码不多，但一直认为那一刻的顿悟是最有价值的
好的代码，程序就是在做盒子 ，想想寄存器 。
各种 开发工具，开发平台 不都是盒子吗，
我们要做做盒子的人，而不要做用盒子的人
Top
41 楼Sustain（支点）回复于 2003-01-18 19:11:20 得分 0
怎样理解模式与性？
我不知道如何表述性 不是我不知道它是什么 而是我不知道怎么表示它不是什么 当你在那优美的躯体中徜徉的时候 你自然就知道那里就有性 当你离开峰乳肥臀的时候 你就知道那里没有 我们完全不需要理论 单单凭我们的直觉就可以解决 而当我们上升到语言需要表述时反倒成了困难 但这决不是道可道 非常道 因为性已经被明白无误的表示出来 也同时可以让你看到它的反动
回到GOF上来 我不知道有多少人觉得GOF晦涩无比 但是我知道有这样感觉的人 一定是那些没有面向胴体思维的人 性是一种在千百万年大自然的积累基础上现实存在并被发现的东西 不是被什么大师发明出来 而是被他们体验出来 大师已经把体验作出了报告 我们如果也延着他们的道路走下去 我们一样会遇到那个场景 我们一样会发生很大师当时同样的感受 但是为什么我们没有 我们不理解 就因为我们没有走在大师走的面向胴体的路上 我们一直在面向过程的路 所以你即使自慰过1000次 只要你不走面向胴体的路 你就不会感到有会心一动的感觉 你就体会不到那种痛快淋漓的美 你可以看看自己的周围 往往是年纪越大的人对面向胴体理解越困难 因为他们的习惯代替了他们的本心
虽然这样描述对O6Z先生很失敬，但这样伙计们更加容易理解什么是模式，不是吗？
要赞扬模式，何必弄出那么多优美的词汇，应该把它留给性，应该回归自然。
我是极力支持模式的，是它让我体味到了所谓的无名特质--高潮。
我是不会在乎任何版砖的，真正理解了性一定也会理解模式。就这样。
Top
42 楼liujiangshan163（羊羔）回复于 2003-01-18 20:28:01 得分 0
不要玄了
实在一点点，中国的程序要是都这样写
呵呵，能行吗？？
我觉得模式快变成〈法轮大法〉了，
你有能力讲清楚，就讲清楚，
不要烂比喻，借喻，
要知道科学要有理有据，这不是要写论文，可以忽悠
“通常我对国内的计算机书籍的作者都无甚好感”，你呢
连个模式都让人晕，你写书，就。。。。。。。
Top
43 楼monkey_zeng（未来报告）回复于 2003-01-18 21:27:39 得分 0
zzTop
44 楼libi（风自吟）回复于 2003-01-18 22:14:21 得分 0
模式与性，以及禅都有一个共同点，那就是需要实践，讲求体验的。无论看过多少书，多少录象，没有亲身经历过，你都不可能获得真正的性体验，就算你对这一过程中的所有阶段、物理化学反应，以及应付的方法都非常了解。
legendcn(吉品黄山)朋友，只要心里把对方当作朋友，那么交不交朋友又有什么关系呢？:)Top
45 楼yangzhenhai（叉子）回复于 2003-01-19 11:09:18 得分 0
无名特制是什么啊？还是没觉得！
我写的code 10K++ 还要多吧！而且大多数是写类库的。希望能理解一些。
还是说的通俗一点吧！计算机是很简单的东西，不要搞复杂。
O6Z说的一切都是对象的观点，我又有新体会，我们提交的产品，其中的对象，每个人做出来的都不一样，但是越是高手，想法越接近，也许就是找到了无名特制吧！
虽然一切都是对象，但是不同的人划分对象的方式不一样，导致程序出来的质量参差不齐，高手强就强在，能更快的找出最对的方式，而菜鸟就总是反工，最后由于工期限制，勉强提交，结果一塌糊涂。一个高手说过，只有一种做法是对的，其他全是错的，条条大路通罗马是错的，自古华山一条路。有时不惜为了改一个变量名称，重新全盘整理程序。也就是为了靠近这最对的方法。
因此我认为，最好还是集中讨论，如何找到那一种最对的方法。不管用什么办法，我们应该得出的是同一种对象集合。如果不同，那么，有人错了。在得到的对象上，所有的方法，所有的人都是平等的。Top
46 楼jeffyan77（jeffyan77）回复于 2003-01-19 11:28:28 得分 0
呵呵，楼主说：“这是乡下泥瓦匠的生存之道。”这里面就有模式的语言，也就是将大家引导到永恒之道的“门”。请参见Alexander的《建筑的永恒之道》中描述“乡下泥瓦匠”怎样建牛棚的描述。
如果大家都能像“乡下泥瓦匠”建牛棚那样建造软件系统，就离Alexander的永恒之道不远了。呵呵，娱乐娱乐Top
47 楼ajoo（聪明的一猪）回复于 2003-01-19 12:54:07 得分 0
其实，我一直觉得，“模式”只是用来和别人交流的。真正设计的时候应该忘记它们。你所见到的只是需求，需求，需求。
所想的只是怎么能够简洁，精确底描述需求，去掉不必要的假设。Top
48 楼twinsant124（蚂蚁的天空）回复于 2003-01-19 19:51:45 得分 0
I read the first chapter of <Java & Patterns> yesterday from my classmate.
And i don't agree with author his ideas about the QWAN, the gate and the way.
I did think Patterns are just the gate, NOT the way.
The way is different from people to people. You learn patterns (the gate), but you may not find the way to reach QWAN. Or maybe you can? :)
But we must learn the gate, and find our own way.
That's all.Top
49 楼jeffyan77（jeffyan77）回复于 2003-01-20 06:32:21 得分 0
to: twinsant124(蚂蚁的天空)
我的书没有说模式是the way。You read your own ideas into my book.
呵呵Top
50 楼jeffyan77（jeffyan77）回复于 2003-01-20 06:44:55 得分 0
to ajoo:
如果把需求理想化成一个连续曲线，横轴是时间，那么这根曲线有一次导数曲线、二次导数曲线，代表需求的变化、变化的变化。
那么“简洁，精确底描述需求”就是根据曲线本身进行的。设计模式要处理的比这更多一些，还要包括一次导数曲线。这就是我说的系统的可维护性，也就是在需求发生变化的时候，系统设计的稳定性。
软件系统的稳定性是现在西方一个新的研究方向。还没有一个理论涉及到二次导数曲线，呵呵。Top
51 楼ak_47（快枪手）回复于 2003-01-20 08:43:01 得分 0
模式？？？？
对我这从来没算过自己写过多少行程序的乡下人理解。
它就是不让我这个懒人重复劳动的偷懒方法。
无名特质？？？？看不懂你们城里人说什么。Top
52 楼liuty2006（）回复于 2003-01-20 10:09:01 得分 0
没必要这样"玄"....
模式只是一门技术罢了---是很多人技术经验的总结Top
53 楼ajoo（聪明的一猪）回复于 2003-01-20 11:29:45 得分 0
没那么复杂。需求变化了，什么都得变。不可能预测需求的。
不信，你给个关于这个导数的设计例子，什么pattern不是直接基于这个曲线的？
关键就是不要自己假设需求，自缚手脚就够了。Top
54 楼Carven（Carven）回复于 2003-01-20 14:01:53 得分 0
看起来，争论的焦点在于软件开发过程中有没有所谓的“玄”的东西了，换一个说法就是，有没有这样一个抽象的方法论，可以指导软件开发的具体行为。早50年的时候，国内很多学者就在讨论辨证唯物主义对科学研究的指导意义，可惜没有得到一个真正意义上的进展就因历史的冲击而消散了。不过可以确认的是，在美国，PhD是最高学位。
但那是研究领域的东西，和实践领域的事情两码事。我就再向大家推荐一本书，普华永道的《管理悖论》，作为一本经济管理领域内优秀的著作，它谈到了很多具体管理中的问题，最后，如果有人要问，这本书讲了什么？严格的讲，它什么也没讲，它从头到尾都充斥着类似文化变革要雷厉风行也要和风细雨，项目管理要严格要求也要大胆放手这种谁都会讲的屁话。但这并不妨碍它成为经济管理领域内优秀的著作。
所以，我的观点，在象软件开发这样的实践领域中，存在着一种方法论，它看来是不言自明的，实际上是不可说的，而模式，就是通向这个方法论的大门。说到这里，就想起一个我很爱讲的故事：
说有一座山上，有一个老和尚，一个小沙弥。。。。。。。（西瓜皮和烂西红柿开始飞了出来）（不是那个啦）
老和尚很有道行，有别处的僧人或是居士前来讨教的时候，老和尚总是伸出一个手指，求教者都豁然有所得。于是小沙弥想，不就是伸一个手指吗？我也会，于是也开始伸手指，被老和尚看到了，大怒，一刀剁了手指。
我想我大概就是那个小沙弥了，在等老和尚来剁手指。
Top
55 楼lynxliu（lynx）回复于 2003-01-20 14:28:34 得分 0
Carven(Carven):
你真的是把简单的东西搞得复杂了。把技术艺术化，看上去却是很美，就像写字变成了书法。一味的描述，渲染，实际上并不增加信息量。模式的书为什么至今仍然以四人帮的为经典，根本原因就是信息量本来就是那么大的东西，任凭你从不同的角度把玩，观赏，方寸之间感觉震撼，甚至灵魂出鞘，那也就只是那么一点东西而已。很多人喜欢这种游戏，一本红楼梦，竟成了一问学问，连曹氏的二大爷都要搞清楚，但是也没有创造新的价值。它再揭露，再预言，再呐喊最后建立新政权的还不是那些实实在在战斗的人。模式也不过是一种人们希望重用的思想而已，他的价值在于使用而不是观赏。科学历史上没有什么不言自明，不可言语的东西。那种牵强附会的把模式翻过来，调过去的研究实在和红学有些类似，说不定以后这里也有博士学位呢Top
56 楼arfayr（阿飞）回复于 2003-01-20 18:26:40 得分 0
新来的高手的确见解不凡
模式是前人的思想和经验的精华
可以使用
当然更可以创新
当然决不能把模式当作万能之道，硬套
Top
57 楼stonespace（stonespace）回复于 2003-01-20 18:40:14 得分 0
哲学不是玄学，所有的概念都必须经确定义，所有的演绎和归纳都必须自圆其说，而且所有命题的结论也必须符合事实。
模式作为一种技术手段，它存在的价值在于它可以被操作，是否容易理解和应用，应该是一种技术的价值的重要方面，所以如果我们试图改进或者发展这种技术，方向应该是把它变得更容易理解和运用，而不是“玄”化。
Top
58 楼ajoo（聪明的一猪）回复于 2003-01-21 01:06:56 得分 0
jeff:
拿对象猫的reflection工厂做例子。
你觉得这里abstract factory是描述曲线本身还是导数的？
我认为是曲线本身。
作为他的gui, 其需求只是取得一个Widget的instance, 至于这个instance是通过new, 还是通过reflection, 还是通过其它的工厂方法，不是它要关心的范围。
而对象猫的设计，直接用reflection来代替工厂，并不是对需求的预测不完整，而是没有精确地描述需求，他自己做了太多想当然的假设。（假设我的实现者将只使用一些类，并且向我公开一个缺省的拷贝构造函数）
很多设计的问题都是因为没有精确描述需求，没有去掉一些不必要的假设，虽然有些假设是不明显的。
所以，设计时，要考虑的问题，不是什么pattern, 而是要反复思考：什么是我的需求？这个接口是否忠实精确地描述了我的需求。接口的设计对客户和实现者都承诺和要求了什么？而这些承诺和要求都是需求本身的，还是我自己不小心放进去的？
再举个例子；
你要写一个对ResultSet的针对business logic的wrapper. 每一行对应一个business object, MyRecord.
那么，你是遍历这个ResultSet, 最终返回一个java.util.List? 一个MyRecord[]? 还是一个其它的什么客户定义的collection对象？
接口可以是这样吗？
interface Query{
MyRecord[] findRecords(Criteria crit);
}
有时候，也许这个选择无所谓。你可以随便用一个。
不过，不论使用哪一个，你都作了一个额外的假设：
客户需要我返回的MyRecord[], 或者java.util.List.
但从纯的需求角度，你并不知道客户希望把返回的MyRecord放入什么样的容器，你甚至不知道客户是不是想缓存这些MyRecord. 决定怎么存放这个MyRecord, 也不是你的Query接口的责任。
一个更忠实于需求的接口应该是这样：
interface Query{
void findRecords(Criteria crit, RecordReceiver rr);
}
interface RecordReceiver{
void receive(MyRecord rec);
}
此时，如果用户希望把MyRecord放入一个java.util.List, 他自然可以写一个RecordReceiver的实现来做到这点。
总而言之，尊重需求，忠实需求，仔细除掉假设，也就是模式了。Top
59 楼jeffyan77（jeffyan77）回复于 2003-01-21 07:57:14 得分 0
to ajoo:
你强调需求是对的，有很多朋友学习模式常常会忘记需求这回事情，一心一意地将尽可能多的设计模式用到自己的项目中去，不顾系统是否需要这些设计模式。但是光是需求并不够，模式并没有停留在满足需求这一点上。
软件设计需要解决的根本问题有两个：系统的可维护性，代码的可复用性。这两者都是关于软件需求变化的，也就是我前面所说的，软件需求这根曲线的导数曲线。当人们这样说的时候，已经假定了这个软件在某个时刻是满足那个时刻的需求的。
换言之，需求是时间的函数，并不是一贯不变的。软件工程设计的困难之处，就是处理需求的可变性，但是这是一个较为高级的问题。如果一个软件系统距离自己的需求很遥远，那么设计师的问题就是更为基本的问题，解决它的问题谈不到设计模式的高度。
同时，设计模式是重构过程的一部分。软件设计过程可以划分成为建模、重构这两个循环往复出现的两种不同过程，总是处在建模、重构、建模、重构...之中的。设计模式不应当在一开始就进入设计，而应当在重构、重新建模的时候进入设计。我们看一看四人帮之一的Ralph Johnson所说的：
“在87年或88年我阅读《建筑的永恒之道》的那个时候，这本书对piecemeal增长的强调对我的吸引力非常大。piecemeal增长是自然界运行的方式，也是我们如何到达QWAN的方式，它是理想。......很多人阅读《设计模式》，并且认为他们应当在设计工作一开始的时候就是用设计模式。我们没有这么说，他们在阅读的时候，把自己的假设放到了里面。”
在文献PLOP98里面p472，Ralph Johnson又说：
People develop abstraction by generalizing from concrete examples. Every attempt to determine the correct abstractions on paper without actually developing a running system is doomed to failure. No one is that smart.
所谓抽象就是对细节的忽略。一种抽象可以处理很多种被忽略的细节，这就是对变化的支持。
换言之，设计模式就是用在重构过程中的，而不是在第一次设计的时候就进入设计的。这就是我所说的，设计模式是对需求变化的支持。
呵呵，大家切磋Top
60 楼ajoo（聪明的一猪）回复于 2003-01-21 08:08:19 得分 0
jeff, 你的回复就够抽象的。看来一定是考虑到以后问题不论如何变化，你都可以用它来以不变，应万变？：）
能不能请你给出哪怕一个模式的使用，或设计的例子，它是依赖于这个虚无飘渺的需求的导数的？
在我看来，尊重需求和可维护性并没有矛盾。相反，只要你仔细研究需求（这个需求不只是diliverable的需求，它包括各个子模块根据自己的需要定出的需求），去掉所有不必要的假设，你的设计就是对未来需求变化最有弹性的。
没有谁可以真正设计出一个东西，让它应付一切需求变化。但是，你可以最小化维护成本。
怎么最小化？去掉不必要的假设，精确描述需求。
花心思去预测需求？我认为那是浪费时间而已。Top
61 楼jeffyan77（jeffyan77）回复于 2003-01-21 10:19:24 得分 0
ajoo:
呵呵，看来您没有读懂我说的一些话，需求是不能预测的，让我再引用一遍在文献PLOP98里Ralph Johnson说的话翻译过来就是：
“人们从具体的例子发展出抽象化。不开发出一个可以运行的系统，就试图在纸上确定出正确的抽象化，是注定要失败的。没有人那么聪明。”
这里分明讲的就是不能预测需求。其他的我就不重复了。
尊重需求，是指的某一个时间点上的需求，是需求曲线本身。
何谓维护？维护指的是需求变化过程中的对系统的修正，需求有改变才谈得上维护，它是关于需求的变化的，属于需求曲线的一次导数。
我看不出有任何必要给出代码来证明这些想法。Top
62 楼Jim2002Chen（Jim）回复于 2003-01-21 10:29:55 得分 0
大家谈了这么多，有没有哪位大侠想过，怎样把自己个人或团队在以前的开发实践中使用过的解决方案总结一下，形成模式进行组织、存档，甚至用类似于PCML（Pattern & Component Markup Language）之类的语言加以描述和应用，甚至开发适用于本公司软件产品应用领域业务特点的建模工具，借以分析成功案例、提取模式、创建配套的模式库、应用自己的模式来建模并扩展编程与开发环境，实现辅助软件开发的目的，为软件开发提供强有力的支持，促成软件构件的大规模重用，借以提高本公司的软件开发能力。Top
63 楼yayong（鸭泳）回复于 2003-01-21 10:52:56 得分 0
to jeffyan77:
太同意你的说法了, 与其在设计之初考虑模式，不如在重构的时候考虑。
Martin Fowler的一篇文章很不错，我非常赞同
http://www.agilechina.org/MartinFowler/isdesigndead.htmTop
64 楼ajoo（聪明的一猪）回复于 2003-01-22 08:26:14 得分 0
jeff, 我给出了几个例证证明pattern可以只考虑需求本身，而不考虑需求的变化（因为你不可能预测变化）。
我的观点很简单，那就是：精确描述各个模块的需求，就是模式。
感觉这个理论至少比你的需求变化理论的“运用之妙，存乎一心”容易掌握和做到吧？它包含的信息量也比“变化”理论大吧？它也比变化理论容易证伪吧？
剩下的就是它到底对不对的问题了。
你的观点是pattern是用来控制需求的变化的，而不只是适应需求本身。（换句话说，只适应需求本身是不够的）
我感觉我并没有给你出难题啊。你不必证明你的观点，至少应该证伪我的观点吧？
要想证伪也很容易，你只要找到一个pattern, 一个应用场合，说：“看，这里需求是这样，如果你目光短浅，只顾需求，就不会使用这个pattern, 最后造成这样的后果。”
如果你连一个反例都举不出来（科学的特点就是证伪容易，证实难），怎么说我的观点是片面的而变化理论是正确的呢？还是它只是一个不需证明的公理？
Top
65 楼ajoo（聪明的一猪）回复于 2003-01-22 08:38:15 得分 0
jeff, 也许我们又犯了自说自话的毛病了。你似乎在说需求变化的必然性。以及应付需求变化的重要性。
这我都没意见。
我的观点是：需求变化不应该被放到设计的时候考虑。只要你精确描述了眼前的需求，不做任何想当然的假设，它自然就是对需求变化最有弹性也最经济的。用时髦的xp的思想来说：任何时刻，设计的目标只是目前所看到的需求。Top
66 楼twinsant124（蚂蚁的天空）回复于 2003-01-22 12:38:09 得分 0
So we talk about Pattern then we must talk about Refactoring.
I did think Refactoring is MORE important than Pattern.
Refactoring(Process & Methodology) is the way.Top
67 楼ajoo（聪明的一猪）回复于 2003-01-22 16:01:19 得分 0
refactoring嘛，可以认为是，需求变化了，或者需求更明确了，发现原来的方法不合适，采用的一个达到对当前需求最合适的设计的方法。其焦点还是当前所看到的“需求”。
Top
68 楼shshsh_0510（雨下了4年11个月零2天）回复于 2003-01-22 16:17:08 得分 0
有意思，有想法，有水平。
但有问题：
1、你可以从技术，从工作悟你的人生哲学，但重要的是你悟到的体会，而被悟的介质不重要。
2、之所以外国的技术水平较高，是应为他们总是批判前人，发展理论，所以学他们的理论还是要用他们的方式的好，不要想佛、道之类的，只有你悟她的份。
3、没10万的经验没白不了，虽有些绝对，但是实情。我以为只正是其要解决的弊病之一：如何将其使用上的复杂性封装，使人们容易使用。Top
69 楼jeffyan77（jeffyan77）回复于 2003-01-23 11:33:07 得分 10
To ajoo:
发展出设计模式与XP的都是同一组人，他们受到Alexander哲学的影响，进行了两次看上去不同，但是在思想上相互关联的努力：设计模式与XP。
相比较而言，设计模式更接近Alexander对建筑物的描写，XP更接近Alexander对城市发展的描述。
Alexander认为城市的发展不应当有一个Master Plan(总计划)，而应当通过大量的独立设计，经过力的协调按照piecemeal的方式发展，城市的发展自有其模式语言。与此惊人的相似，XP也是一样，放弃长期的可预测性，得到近期的精确预测。每一次piecemeal的发展都不需要一个master plan，但是大量人员参与的相对独立的piecemeal发展会给出最好的整体（the whole）效果。
参见
http://www.webendshere.com/javapatterns/faq/faq.html#tech3
在设计模式、XP之后，下一个努力是什么呢？预测未来是一个很危险的事情，但是如果还是Kent Beck这些人进行的话，我可以和各位赌一百块钱，相信他们还是会从Alexander哲学出发，而且非常有可能与Alexander的新著《The Nature of Order》有关。有人以为四人帮开创了设计模式，其时开创设计模式理论的是Kent Beck，只是因为他又开创了XP，而且在XP方面的名声超过了设计模式方面，加上国内的朋友没有看过他的设计模式开创性论文，反而是从四人帮的《设计模式》一书开始了解设计模式的，所以大家并不知道开创了设计模式、XP理论的实际上都是同一个人：Kent Beck。
如果各位没有读过Alexander的新著《The Nature of Order》的话，这本书仍然是充满了道家智慧，如果你熟悉道家，这本书你读起来一定很轻松，看了上页，你就能猜得出下页讲的是什么。Kent Beck非常醉心于《The Nature of Order》这套四卷本的哲学著作。我相信，如果Kent Beck再推出新的软件设计理论的话，一定是受到这四本著作的启发。
哈哈，我买到了《The Nature of Order》第一册，正在阅读中，告诉大家，就像渴了一整天的人，突然喝到了水一样，一边读书一边感觉到身体的每一根汗毛都在愉快地跳舞。妙啊妙啊妙啊！
to shshsh_0510:
从哲学理论出发，完整地开创出两个软件理论，这在科学史上是罕见的，另一个例子就是马赫哲学催生了爱因斯坦的相对论。国内的朋友可能是出于对哲学的逆反心理（呵呵，我可以理解），见到哲学就敬而远之。
这一次可是例外。看一看Alexander，再读设计模式、XP，就好像头脑中一扇窗子被打开了。而如果你熟悉道家，在读Alexander理论时，你读了第1页，就知道第2页大概会讲什么。不信，你试一试，然后再告诉我，我说得对不对。
to twinsant124:
建模(Modeling）与重构（Refactoring）两个侧面，就像男人与女人一样，两个都重要，无所谓哪一个更为重要。没有模型，从哪里开始重构？没有重构，模型怎能符合需求？
至于什么是“道”，不要这么快就下结论。
呵呵，大家切磋Top
70 楼shshsh_0510（雨下了4年11个月零2天）回复于 2003-01-23 14:35:36 得分 0
to jeffyan77:
1、一个爱思考的人是不可能反感哲学的,不管它是在哪国。
2、你说“从哲学理论出发，完整地开创出两个软件理论”，我不同意。
我看模式的资料不是很多（主要是我认为还不成熟），说错难免，还望指教。
我觉得，其的出现是自然的，到时候了，没你说的那个哲学也该出现了
在建筑领域出现了、在软件领域出现了、在很多领域出现了
我们程序编多了，自然要总结经验，最简单、直观的当然是把可直接运行的库、可直接编译的代码存档、复用。后来，代码编得飞快了，但设计结构时还很费劲，自然要总结一个表示方法来记载这方面的经验了！
现阶段，学习模式的方法为：
新手：
学习一个模式--在实践中运用--失败or成功--随经验积累，知其然、知其所以然，知道什麽时候用，什麽时候不用--完全掌握了
经验丰富者：
已经知道很多“模式”但还没形式化--学到一些新模式，增长经验
问题在于：
老手，增长了经验，水平没有本质的提高
新手，没有模式照样成为老手，只是学习路线受到影响（哪条路好还不太好说）
你会说：对于老手来说，经验的增长，这显然是个好处。
我说：不一定！经验增长到一定程度有可能是水平的降低！（对不同类型问题，并不是经验越多的人解决的越好，比如敏捷方法所攻击的过度设计问题）
一个问题如果太复杂了，以至很难用几条高度概括的指导思想判断时（如集合的公理），人们会总结中间层次的经验性结果（定理），会分类并总结这些分类的目录，但是“度”的问题是困难的。如果我在这个复杂目录中查找解决方案的困难程度几乎和我用那几条公理直接推差不多时，就没劲了。模式就差不多吧。
由几何中定理的运用知道，我们解一类问题时，往往只关注有关的一小部分定理。所以模式的目录还应调整为面向领域的才行，我认为。
不光软件，人类的思想都应该总结成目录。当然，需要一个统一的表示形式（模式在这方面的研究有所贡献）。
于是，以后人们学习、工作的重点变成如何检索这个目录。难啊！
难怪Carven说先得编10K行代码，再学了。我认为还有待发展，才能真正在工程中发挥作用。
Top
71 楼twinsant124（蚂蚁的天空）回复于 2003-01-23 16:43:40 得分 0
-----:)Top
72 楼jeffyan77（jeffyan77）回复于 2003-01-25 03:40:31 得分 0
to shshsh_0510() :
参见GoF自己回忆的历史：
http://www.webendshere.com/javapatterns/faq/faq.html#tech4
Top
73 楼ajoo（聪明的一猪）回复于 2003-01-25 06:01:27 得分 0
好像变成讨论模式历史学，模式考据学了？Top
74 楼telescope（望远镜）回复于 2003-01-27 01:11:20 得分 0
不如看一下《JAVA与模式》，这是我目前看过的学习设计模式的最好的书，易读易懂。
不要以为你用的不是JAVA就不理它，事实上，你总要用一种面向对象的语言来表达设计模式，四人帮用的是C++和什么来着。我也没学过JAVA，但《Java与模式》依然看懂了。
我一直不能很好地理解面向对象，当然也就无法很好地理解设计模式，但是去年9月份开始，我用Rose设计并实施了一个项目（你可能想不到，我用的语言是PHP），项目完成后，我忽然觉得，设计模式变得如此亲切，它回答了我很疑惑，让我舍不得松手，不断地读下去。现在，《Java与模式》我已经读了400多页，我还会继续读下去，直到读完，我还要在下一个项目中运用它，从不用到使用，从用不好到用好，这就是我的想法。
本书的作者也常来这里，我就不说他是谁了，等读了他的书你们就知道了。哈哈哈哈..........Top
75 楼twinsant124（蚂蚁的天空）回复于 2003-01-27 12:33:03 得分 0
-----Top
76 楼Max_LBY（七彩狼）回复于 2003-01-27 14:47:33 得分 0
1、《Java与模式》是一本好书，值得一读，浅显易懂，例子也非常的丰富。虽然也有些许瑕疵。
2、模式与重构 是一件事物的两个方面，纯粹的模式或纯粹的重构是没有意义的。
3、无名特质是存在的。模式是无名特质在某一方面的表现，而重构是使事物包含无名特质的方法。因此，模式更应该是自然而然所表露出的，而不是因为模式而模式出来的。
4、模式的学习是需要积累的。没有足够的经验，没有足够的时间，是无法了解模式的。而模式的应用则更是如此。因此，我对 “学习模式要有十万行以上的代码经验”表示认同。Top
77 楼superhasty（鸟儿自空中飞过）回复于 2003-01-27 15:41:41 得分 0
模式对于需求建模是否有用呢？Top
78 楼Lugonix（溟峦）回复于 2003-01-27 19:55:29 得分 0
一直都没见到这本书，太郁闷了！Top
79 楼twinsant124（蚂蚁的天空）回复于 2003-01-28 12:36:10 得分 0
:学习模式要有十万行以上的代码经验
study it early is better, it's the gate. may be you can't understand it at once.
apply it should 有十万行以上的代码 in one project 经验Top
80 楼shshsh_0510（雨下了4年11个月零2天）回复于 2003-01-28 13:27:26 得分 0
to twinsant124(蚂蚁的天空) :
another choice: study it as late as you can understand it wellTop
81 楼Philippy（一盘菜）回复于 2003-09-03 18:08:28 得分 0
说翻译得不好，我同意，着实原版的易于理解多了，你说的一些别的观点，我不敢苟同Top
