刚写了个东东,欢迎大家提提意见.(文字)(200分)

怎么打开很慢呀

大概看了看， 写的很好。
度确实很重要，但是一般情况， 没有那么简单的逻辑，如果只是个简单的明片管理，学生登记， 当然是简简单单实现就行。 可是实际上很少有这样简单的业务需要。

“严格的说，Strategy其实是Template的一个衍生或者变化。”
------------------------------------------------------
建议楼主好好理解一下，两者是完全不一样的。关于strategy，阐述最详细的是 modern c++ design，你看看什么是strategy。
对于度，你也需要好好的研究一下，根据你帖子里面的划分，用oo的术语来说，那个粒度简直大得惊人。
“请问阁下什么是设计呢?是瀑布形开发模型中完美需求完成后进行的设计么?
或者请描述一下阁下所的设计过程?都包括什么? ”
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
楼主，你当真这样发问？那么显然，你头脑中还存留着瀑布开发模式，也是导致你写出这样的帖子的原因。你问我怎样设计，很简单，坚持设计最小的信息类，坚持设计最小的交互类。不知道楼主是否知道multi programing，了解一下，这个是软件发展方向。例子很就看看boost的graph。先进的思维都是在c++里面，java，c#都是拾人牙慧，而且还差得远。
"就是做三层不能为三层而三层，而应该看具体项目。三层并不是包治万病的万能药，而应该针对不同的项目选用不同的框架。"
--------------------------------------------------------------------------
楼主是很赞同这样的说法，那么你我没有对话的平台，所以没必要多说什么了。真话往往是伤人的。

回复jhwh,
首先我得说，我所看的stragegy是Design Pattern里面的描述
你所指的modern c++ design我还真没看过，因为大学毕业以后的确没有机会接触过C++，所以相关的资料的确没有太多注意。
multi programing的确我也没接触过，最小粒度的概念我有听说，但是没有进行过深入的研究，但是我比较接受敏捷或者跌代里面的先以最简单的方式开发，然后再在该重用的地方重构，去消除bad smell。”对将要发生的事情，就算可以
遇见他一定会发生也不去处理，等到它真正发生的时候再去重构“
也许你看到的角度和我的不同而导致意见的分歧，这我不会有意见，瀑布形出现后几十年，同样有人否定了它的定义，我不指望我的文章能够人人都赞同，也不相信他会绝对正确。
之所以我把写那么长的文章的目的在于，把我的整个思考过程写出来，说明我为什么看到这个度的概念。
里面会有错误，会有误解，谁又能保证在一生中我都一贯正确？之所以把他共享出来，和大家讨论的一个重要原因就是我想去知道我的思考是否正确，或者某些方面是否考虑周到。
让大家也来讨论是不是有问题，如果有我也可以提高，也许有人和我的思路相似，这不为奇怪，有人和我的意见相逆也不奇怪。

但是不管同意或者反对，我所接受的方式是能说明：有问题，问题出在哪里？摆事实讲道理，我会心服口服。
而一个人就能撂下一句，“你不懂！”算什么？或者说“某某大师说了，这又算什么？大师说这话的前因后果呢？大师的环境和我的完全一样么？
看到的人不会说你懂，我难免生气，我也是个凡人。
你就摆两本大书出来，说上面说了，每天那么多的书出版，相反的论点多了去了，你的观点也许正确，正确在哪里，你所说的multi programming也许有道理，有道理在哪？不经过思考，我的确不习惯接受任何人的观点。
到如今坚持瀑布型开发的人还大有人在，我不能说他是错的，他有他的理由，他有他和我不同的项目环境，他有他的思考。我坚持敏捷，也许不对，但是我是经过思考才去体会它的。
这是一个交流的平台，我来这里一直是本着交流为目的。
那位人兄我欣赏他，为什么，因为他給我的回复是经过了细心的思考，细心的琢磨写出来，在里面他的每一个赞同或者否定，都有他的理由，这是一种思考的表现。
我喜欢和善于思考的人打交道。

呃...本来是路过发表下看法,没想到把我搅进去了.
在这里我大胆推测jhwh兄没有参与过实际的用户需求调查。我想大部分做过需求，和实际用户打过交道的人，都会不知不觉养成一个习惯，说话直接了当，不奢望别人对自己模棱两可的话会有某种默契。对有可能造成歧义的话特别敏感，会考虑到对方可能对自己的话会有其他理解，因此会在说的时候注意澄清。有句话说，“别人对你的所说所做会作出各种各样希奇古怪的理解，不要低估别人的这种能力”
言归正传，jhwh兄说“楼主是很赞同这样的说法，那么你我没有对话的平台”是指我说“就是做三层不能为三层而三层，而应该看具体项目。三层并不是包治万病的万能药”。对此我有三种理解：
第一种，jhwh兄觉得这句话本身是对的，但是是废话，因为人人都知道，根本没有赞成或反对的价值。就好象，我说“告诉大家一个秘密，老婆是女人，山是石头海是水”，有人说“不错，坚决赞成”，结果其他人一听：“两个傻子，懒得跟他们说”。
第二种，jhwh兄觉得这句话无所谓对错，因为我们在最根本的公理性的问题上没有共同语言，因此“没有对话的平台”。就好象，把欧氏几何的定理放到非欧几何体系里去研究，把量子力学放到牛顿力学体系里去研究一样。
第三种，jhwh兄觉得这句话是错的，而且是常识性错误。不明白的话随便找本书看看，随便找个人问问就知道。jhwh兄不想在此浪费时间。
如果是第一种，那么我们的最终结论是一致的。只是各人对自己的定位有所不同而已。傻子自有傻子的层次，只要没有误导听众，高人们大可高抬贵手。有句话说："Never argue with a fool, people might not know the difference. "
(不要和傻子争吵，因为别人会分不清谁是傻子）
如果是第二种，那么就的确是“没有对话的平台了”。我说“平行线必无交点”，你说“如果平面扭曲的话其实是有交点的”;我说“质量守恒”，你说“速度极高质量极大时会有质能变换”。根本说不到一起。只是，明明我只是想用相似三角形法测量一下建筑物高度，有人跑过来跟我说“你根本不懂什么叫非欧几何，你测量时没有考虑到重力对空间造成扭曲的修正系数”。又或者，明明我只是想算算苹果掉在头上会产生多大压强，有人跑过来跟我说“你根本不懂什么叫质能转换，苹果在下落过程中有1E-100克的质量变成了能量”。如果jhwh兄觉得这样合情合理的话，我们倒也真的是“没有对话的平台了”
但如果是第三种，我就有点好奇，错在哪里。莫非jhwh兄觉得“任何项目不论规模都应该一律用三层”？很可惜暂时来说我没有在任何资料里看到有任何权威人士提出这样的观点。当然，可能是我孤陋寡闻了，那么希望jhwh兄能告诉我在哪里可以找到相关资料，我会去认真研究一下。
退一步来说，就算一时之间没有实际资料，而且如今这个世道权威也未必可以尽信。那么也希望jhwh兄能在这个问题上稍微详细展开讨论一下。任何相反意见对开拓思维都有很大帮助，希望jhwh兄能不吝赐教。至于伤人，jhwh兄大可不必担心，只要是有据（有无理均可）的意见，对我们就有益处，就算我不赞同，最多也就是反驳一下，绝不会捶胸顿足以头抢地自伤性命。jhwh兄可以放心。
====================================================================
说完我的部分，对于jhwh兄对楼主的建议，我有以下看法
1. 就我理解，楼主是在说三层架构的利弊，或者有些人可以看作是在反对滥用三层。但论述对象是毫无疑义是三层架构的适用性，不是面向对象。而jhwh提出的"坚持设计最小的信息类，坚持设计最小的交互类"是面向对象分布系统的设计原则，不知道跟探讨分层结构的适用性有何关系。希望能详细展开论述一下。而且设计原则跟设计方法是两回事，即使一个系统做到了“坚持设计最小的信息类，坚持设计最小的交互类”，只要表达层代码有一个地方直接访问了数据库，它就是个楼主所说的“单层系统”（我觉得应该是C/S两层系统）。另外，设计原则与软件生命周期也是两回事。即使一个系统做到了“坚持设计最小的信息类，坚持设计最小的交互类”，但在其生命周期中没有有意识有计划地提供让用户修改需求的插入点或者迭代模式，那么就是瀑布开发模式（又或者连瀑布开发模式都不如）。
2. 关于multiprogramming. 可能是这几年少看书有点脱节了，multiprogramming有了新的含义。至少据我在两年前所知，甚至现在按www.whatis.com上的解释，multiprogramming指的是 "a rudimentary form of parallel processing in which several programs are run at the same time on a uniprocessor."。说的是单处理器分时系统，平行进程方面的东西。希望jhwh兄能提供一些关于multiprogramming新定义的资料，不胜感谢。(不知是不是指多用户访问multi-access方面，但在jhwh兄未点明之前就不展开讨论了）
3. 关于瀑布开发模式。个人觉得虽然现在倒瀑布开发的呼声一大片，但实际上在用的人也不少，并非到了jhwh兄所说的必须将其从头脑中完全抹去的地步。而且其实说到底，瀑布开发模式与三层应用没有实质上的冲突，开发模式是说软件生命周期，三层是说系统架构。一个是时间，一个是空间。虽然说敏捷模式做面向对象三层系统会比较对口，但对于需求变动不大的分布式项目，用瀑布模式做三层也未尝不可(理论上需求变动不大的项目没必要做成三层，但实际上要考虑到客户或项目老总的特殊嗜好，现存系统的架构等等问题)。如果说楼主突然问jhwh兄是不是用瀑布开发模式设计有点离题的话，jhwh兄回答“那么显然，你头脑中还存留着瀑布开发模式，也是导致你写出这样的帖子的原因。”就完全让我摸不着头脑了。希望jhwh兄能详细说明一下其中的逻辑关系。

还不懂。。。。。看来 是田兄的 刀快，非我令狐的 剑快了。。。。
学习中。。。。。。。。。。。。

一不小心又看到了其他人的回帖。本来不想写什么，但是从回帖来看，不理解设计的人太多，也就说一点了。
先说说瀑布。一说到瀑布开发，大家的影响就是死板。按照严格的顺序来完成开发：需求分析，设计，实现，测试。如果需求确实完全确定了，而且就一次性的买卖，那么这么做显然没问题。当然也就是你说生命期。但是根据上下文看，” 请问阁下什么是设计呢?是瀑布形开发模型中完美需求完成后进行的设计么?”，这里的瀑布，显然指设计这一环。说明了问题，现在不用再多说瀑布了吧？

“就是做三层不能为三层而三层，而应该看具体项目。三层并不是包治万病的万能药”。
“论述对象是毫无疑义是三层架构的适用性，不是面向对象。”
语言有内涵、外延和语境，如果非要扣字眼，是没有任何办法进行对话的。这里讨论三层，确切的说，就是指的对象的设计和使用。否则还提什么层次划分， orm。看看楼主帖子上的图和文字，还有你的回贴，三层含义明确了逻辑层，数据层的划分，二层的含义就是逻辑层与数据层放在一起。这样的含义，和oo的粒度划分什么区别吗？然而你这里又来说讨论三层构架的适用性，不是面向对象。不知道你这样说，是为了辩论还是没搞清楚什么是设计？看看引用的两句话，第一句的万能药与软件有什么关系，第二句是病句，但是我们都能明白它的含义，就是因为语言的内涵、外延和语境。如你所言，“说话直接了当”才算“参与过实际的用户需求调查”，那么有多少用户在谈论需求时能“说话直接了当”，还不是要靠调研人员的推导、提炼，反复询问。但是我毫不怀疑你是“参与过实际的用户需求调查”的。你不能从我的第一个回贴里面看出什么东西，是技术上的差距造成的，而不是字的多少。
项目的需求更改，需求的深入变化，谁能完全确定？这样的情况，难道真的还直接对数据库进行存取？难道又祭起C/P/M大法？修改一个东东，难道又要到处search/modify？如果再做一个相似的项目，数据库字段不同，那么是重新写相似的东东，还是copy这个项目，然后又全部查找修改，再次调试？如果你喜欢搞这样的事情，那就走你自己的路，让我说去吧。确实没有任何人说只能三层。但是看看现在软件开发，你看看又有谁还在推荐二层？现实就是最好的例子，是不需要什么权威的。更何况，认为还有“做三层不能为三层而三层”这样的东西存在，很显然的的没有理解oo的根本：类是用来表达概念。好好体会一下这句话，90年代初就由老外的一个大牛明确的在论述oo的书中写了出来，在it界也算一个很久远的话了。如果真的搞明白这句话，就没有必要大段大段的说这么些废话。但是现在不能，还得继续说些废话。
“即使一个系统做到了“坚持设计最小的信息类，坚持设计最小的交互类”，但在其生命周期中没有有意识有计划地提供让用户修改需求的插入点或者迭代模式，那么就是瀑布开发模式（又或者连瀑布开发模式都不如）”再次友情提醒：注意语言的内涵、外延和语境。
“希望jhwh兄能提供一些关于multiprogramming新定义的资料”
很遗憾，这个概念是1998年就有老外正式提出了，不是什么新概念。好好搜索一下，找得到的。当然，这个概念现在还不流行，因为和oo的是有很大差异的。采用这样的概念设计，需要用GP才自然。正如我前面提到的，都是c++，而不是拿java，c#来说明，原因很简单：java，c#用oo实现这些东西很困难。至于这2个的语言GP，了解不多，也就不能拿来说话。更何况用它们的gp来做的类库。而c++已经采用了这样的概念来实现类库。boost的graph就是multi programming 的方式。使用方便，扩展方便，让人赞叹不已。
“首先我得说，我所看的stragegy是Design Pattern里面的描述”
我说的modern c++ design这个书，也就是深入挖掘了 strategy 的概念，比 design pattern 里面的详尽，但是根本是一样。楼主是没有理解strategy含义而已。
“你就摆两本大书出来，说上面说了，每天那么多的书出版，相反的论点多了去了，你的观点也许正确，正确在哪里。。。。。。”
c++ modern design 是c++设计的一个里程碑，公认的。
boost不是书，是c++的一个类库集合，进入这个集合，是要通过c++标准委员会这些牛的审核的。是准标准库。也就是说，c++以后的库，基本都是从这个库来的。这两个东东都存在很久了，所以无论如何，这本书和库，对于软件开放人员来说，不知道名字是不应该的。对了，顺便说一下，c++世界里面，从98标准大会开始，也就是oo如日中天的时候，c++已经不讨论oo的话题，都是GP了。对比一下这些语言，如果要追踪新技术，还是要靠c++的。
《重构》这本书是不错，但是你看看他说什么时候进行重构，显然是没有逃离：类就是表达概念这个根本原则。不管bad smell也好，good smell也好，也一样逃不掉这样的根本事实。当然，还需要搞明白惯用法，也就是 design paterrn。如果能达到只购买新概念专题的书，而不是某种已有概念的高级专题的书，那么就算明白了设计了。正如比较火的ruby，python，只需要买语言说明的书籍就足够了，而不需要什么高级编程什么的。最后提个建议，多看看其他类型的语言，诸如c++， lisp，prolog，而不是一味的抱着oo，这样会对你的思维有着大的提高。

呃。。。在讨论具体问题之前，我想先对jhwh兄的表达方法提出一点请求。并不是说我的习惯就好，jhwhx兄的习惯不好。是因为我脑筋实在太慢转不过来，要笨人去适应高人是很有难度的，因此想麻烦高人委屈一下迁就下笨人。
我与jhwh兄沟通的最大困难在于，jhwh兄的思维跳跃得实在太快，喜欢在因果关系中直接说果不说因，又或者说因不说果，又或者因果联系比较松散，但又没中间过程。
例如一开始说“我觉得楼主不懂什么叫设计”，没了下文，叫我辈怎么能猜得到原来有着这么长的一篇文章为基础呢？
又例如在上文说，“再次友情提醒：注意语言的内涵、外延和语境。”，然后没了下文。而笨人如我，本是希望jhwh兄在下一段会简单或详细地说说对“坚持设计最小的信息类，坚持设计最小的交互类”这句“语言的内涵，外延和语境”的理解的。结果是，jhwh兄认为我没有尝试去理解这句话的“内涵，外延和语境”，而没有考虑到我可能尝试过去理解，但与jhwh兄的理解不同。可能这个问题要留待jhwh兄下次一不小心看到了我这篇回贴时再作解答了。
再例如，jhwh兄说

“认为还有“做三层不能为三层而三层”这样的东西存在，很显然的的没有理解oo的根本：类是用来表达概念。好好体会一下这句话，90年代初就由老外的一个大牛明确的在论述oo的书中写了出来，在it界也算一个很久远的话了。如果真的搞明白这句话，就没有必要大段大段的说这么些废话。但是现在不能，还得继续说些废话。”。

从一句很久远的“类是用来表达概念的”，一下跳跃到“认为还有...存在，很显然的的没有理解oo的根本”。“类用来表达概念”跟“不能为三层而三层”有什么直接关系呢？可能jhwh兄对于中间过程有独到的看法，但不说我怎么知道呢。最后说，“还得继续说些废话”，我本心头一振，但下一段，却又只顾提醒我辈注意说话的“内涵，外延和语境”了。莫非jhwh兄所说的“大段大段的废话”，是指“好好体会一下这句话，90年代初就由老外的一个大牛明确的在论述oo的书中写了出来，在it界也算一个很久远的话了。”这一句？
(顺便说下我对"概念"与"分层"这两点的理解是：理解一个问题可以从许多个不同方面去切入，还有所谓“粒度”的问题。足够简单的问题，可以用一个概念去表达。稍微复杂的问题，要把大的概念分解为小的概念去理解，也有横向（分层）和纵向（分功能模块）的区别。更复杂的问题，才必须要同时从横向与纵向去分离。而这一点，恰恰是现在讨论的关键)
令我想起，一个我中学时的同桌做几何证明题。他有一招很管用，先从题目往下顺推。推到推不下去了，再从求证结论往上逆推。推到推不上去了，在中间写“显然由此可证”。通常10分里都能混个7分8分，因为老师是知道答案的，觉得他只是少了一两步。但对于原来不知道的答案的人，却是完全不知所云。
因此，希望jhwh兄能屈就一下，在推理的时候能一次性把因、果、逻辑关系都说一下。不详细没关系，简单说下就好。
======================================================================
ok, 现在开始讨论学术问题。
1。 谈谈瀑布问题的内涵，外延和语境。
语境是：楼主问jhwh兄指的设计是不是瀑布；jhwh兄说原来楼主脑子里还有瀑布，怪不得写出这样的文章来；然后我问“脑子里有瀑布”跟“写出这样的文章”有什么关系。从文章上看，楼主是个敏捷编程的支持者，并不支持瀑布，但因为jhwh兄上来就一句“楼主不懂设计”然后没了下文，于是问jhwh兄你觉得什么是设计呢？难道是瀑布吗？jhwh兄的回答令我不解之处在于，jhwh兄觉得瀑布连反对也不行，必须从脑子里完全抹掉，楼主光反对没抹掉，所以才写出这篇文章来。那么，即使jhwh兄指的是瀑布里的设计环节，我还是不解，为什么一定要把瀑布抹掉？
2。谈谈三层与面向对象的内涵，外延和语境。
首先，我觉得我和楼主所说的三层与面向对象是不同的概念。不是在扣字眼，因为这是楼主与jhwh兄根本分歧所在。在jhwh兄看来，我们似乎成为反对面向对象技术的反动分子了。
我认为楼主说的单层，内涵是指在表达层代码中直接使用了数据逻辑，例如SQL语句。但无论从形式上或是概念上，这种前提下仍然可以使用面向对象的理论与技术，正如按我上面所说，按纵向的功能模块概念划分对象。当然，这样的对象，从某种意义上说是粗粒度的。但无论如何，用了面向对象技术，不等于就是三层;用了三层，不等于就是面向对象。两者没有必然的联系。
其次，关于最小粒度与最小信息类。做三层不一定要做到最小粒度与最小信息类，但从某种意义上说，做到了最小粒度和最小信息类就必定做到了三层，甚至更多层，视乎对“最小”的判定标准了。为了达到“最小”，表达，逻辑和数据必定是要分开的。
于是问题就在，楼主在讨论三层适用性的时候，你在说你已经根据面向对象的“最小粒度”分到了三层以上了（而且不是直接了当的说，我是好不容易推敲到这一步的。。。T_T）。请问这跟三层适用性，以及懂不懂设计有什么关系？jhwh兄言外之音似乎是“懂设计的人必定会将类设计到最小粒度”。因为jhwh兄没有提出“最小”的标准，所以我的理解就是小得不能再小，绝不可再分的地步。但某些未来需求变动有时会影响粒度划分，不知道jhwh兄是否将这些情况考虑在内。
jhwh兄未指出这是否他的本意，所以在此暂不展开。
另，对于jhwh兄对我两句话的疑问，我稍作回答，与学术无关，没兴趣可以跳过本段。第一句，“万能药”是用了中文中一种叫作暗喻的修辞，不过并不是指“软件”，故此的确和软件没关系。全句的本意是“三层架构并不是解决一切问题的绝对最佳方案”。第二句，这里的确是个病句，但个人觉得要理解它跟内涵，外延和语境关系不大。“...是毫无疑义是..."这几个字，即使没有任何语境，内涵。只要有语法知识，就能明白原意。聪明如jhwh兄，甚至应当可以推出我一开始没写“毫无疑义”几个字，后来为了加重语气又画蛇添足地补上去，结果弄巧成拙。但我在此并不否认内涵，外延和语境的作用，例如我理解楼上“一说到瀑布开发，大家的影响 /*印象*/ 就是死板。”这里时就是靠着内涵，外延和语境才过关的。
言归正传，
3. 谈谈关于“说话直接了当”的内涵，外延和语境。
jhwh兄似乎误解了我的文字。我没说过要求用户“说话直接了当”，反而是因为用户说话太不直接了当，才要求需求分析人员更要直接了当。甚至在有些概念含糊而对实际操作人员有利的时候，实际操作人员甚至会故意含糊其词，这时更需要分析人员直接了当地问清逻辑关系，消除歧义。所以习惯成自然，我问题也就不免多些，希望jhwh兄见谅。当然在这篇贴子里我承认我技术上还是有一定差距，不过如果jhwh兄居然认为我可以从第一篇回贴中从技术上看出楼上回贴洋洋千字的内容，却又是太抬举我了。
4. 谈谈“项目的需求更改，需求的深入变化，谁能完全确定？”的内涵，外延和语境。
我在我第一篇回贴里多次强调“如果你能预见到....，就....”的情况。其中就包括假如你能预见到项目需求变动比较频繁，这种时候我绝对赞成用三层。但如果你预见到你开发时间不够，后期人员不会继续保证三层规则，这样用三层有何意义？又或者你能预见到你做的项目只是个使用周期半年不到的过渡性产品，难道你还去考虑几年后的需求变动？回过头来说，这正是我说“三层不是包治万病的万能药”（这里用了个暗喻修辞，不理解的话请回头看之前建议跳过的部分……）的原因。或者我改成这样会顺眼一点，“三层是包治需求频繁变动，重用性需求强的项目的万能药”，但话说回来，我又不赞成“世上所有项目都是需求频繁变动，重用性强的”这一论调。
另外，顺便问下jhwh兄，你实际上真的遇到过做了一个项目，下一个项目只是改一下数据字段，其他什么都不用改就交货的情况吗？我做的三层项目就那么不幸没碰过这种好事。。。T_T 。不过如果真有这样的好事，原系统又符合我之前所说选用单层的原则，（“业务逻辑并不极其复杂”）的话，全项目查找替换一下也就是了。至于调试，莫非jhwh兄的那次好事，改了字段不做调试就交货了？那就真是好到家了。。。
5. 谈谈“现实就是最好的例子”的内涵，外延和语境。
现在我所见到的现实是，写文章的时候，单层没人推荐，双层还有些人说说，三层是基本要求，不是多层分布式加多应用服务器负载平衡都不好意思跟别人说。实际工作的时候，许多人在用瀑布式开发单层应用，可惜他们现在都在闷头闷脑接项目赚钱，打一枪换一个地方，没空上来论坛跟我们辩论了。而且，正如我在上面提到过的“酒与污水原理”，一个做得很烂的单层系统，还算是个系统。一个做烂了的多层，就什么都不是。莫非jhwh兄觉得现在做开发的兄弟都有jhwh兄的水平，事无大小一律“最小粒度”?
6. 其他
关于multiprogramming，我是很有兴趣，也搜索过。但搜到的都是关于CPU分时的。jhwh兄能否具体说下是什么书，又或者给个网址之类呢？谢谢。boost是个库，里面应该不会提到multiprogramming的概念吧，我也打算忙完这段过年闲了去看看源程序，但觉得还是先看看理论上的前因后果比较好。
关于c++ modern design，不知道是不是指《Modern C++ Design: Generic Programming and Design Patterns Applied》，作者Andrei Alexandrescu，Addison Wesley出版。侯捷译的中文版。也正好是几年前我的一个同学做研究生论文时用到的书。虽然对于C++商业应用，我是在懂看不懂写的水平。但本着“侯捷出品，必属精品”的原则，当时也认真看了。当时我身在国外，只能找到英文版，不知道书中上半部通篇重点在说的policy，是不是在中文版里译成了“策略”。因为最近我重看，翻阅全书，也找不到"strategy"的字眼。下半部在说用模板实现设计模式也没有与strategy相关的章节。这本书主要是通过分析loki库去展示利用GP技术设计类库的技巧。之所以说“技巧”，是个人觉得该书并没有提到大局观的东西，而是主要是应用C模板的技巧，以及用GP实现Design Patterns的具体方法，不涉及架构设计，模式用法上的问题。甚至很着意通过模板技巧，把一些本应在运行期出现的错误提前到编译期报错。个人觉得这本书有独到之处，也是C++开发模板与类库的必看书籍。而且里面提到许多“代码习惯套路”(idiom)，也是对我这种对C++只看不写的人必看的。但把它放到strategy与temporlate两种模式的对比上，其实说明不了问题。思维跳跃能力如jhwh兄，或许可以从policy看到小型strategy模式，再从loki库对policy的应用技巧，推敲出strategy设计模式的真义吧。如果属实，希望能深入与jhwh兄讨论一下，我另开贴给分。（说明一下，我个人并不支持"strategy"是"temporlate"的衍生一说，因为两者的最终作用并非完全一样，某些情况下甚至是不能互换的。）
当然，我看的书叫Modern C++ Design, jhwh兄所说的书叫C++ Modern Design，可能不是同一本。这就不是内涵，外延和语境可以解决的问题了。只能盼望jhwh兄下次不小心看到回贴时告知了。
说点题外话，关于GP与Design Pattern。在我记忆中，Design Pattern应该是比GP要晚出现的概念。早期面向对象刚刚兴起的年代，用面向对象技术做项目极其容易出现类泛滥的情况，那时人们还在费尽心机去理解继承与封装，还没有“面向接口编程”“以组合代替继承”的观念。作为面向对象的先行者（以及最为其他语言垢病的多重继承的实施者），C++最先引入模板、泛型编程。以求改进代码重用性来缓和类泛滥，并减少对动态绑定方法的需求，以提高性能。（当时C++的模板是编译期预处理的。.net我只用C#，对于C++模板只能看懂，具体实现机制不了解）。但后来Design Pattern所谓面向接口编程，优先组合替代继承的观念出台后，Java等后续语言就没有必要跟进使用泛型了。在我看来Modern C++ Design此书的一个重要意义在于思考以C模板来实现Design Pattern，从而充分利用C模板编译期处理的优点，来实现一些单用Design Pattern要费较大力气才能做到的东西。Java在近两年开始引入模板，应该是终于承认模板有其独特优势，值得为此投入资源了。现在JAVA模板的后台实现是在虚拟机级别使用对象，跟C++的纯编译期处理的模板有所不同，不知是否能达到同样效果。
我想说明一点是，C++中的概念，许多已经存在了很久，例如多重继承，例如泛型编程，其他语言所以不跟进，并不是因为其太先进。而是因为这些技术在一定历史条件下有其局限性或者替代品，其他语言在观望而已。C++社区几年前就将重点从面向对象转移到GP，是因为C++面向对象技术在当时已经到达了瓶颈，而GP在当时是突破瓶颈的救命草，如此而已。面向对象技术就其本身来说，其实多年来就没有什么质的发展，发展的是理念和平台。98年已经没有谁在大吹面向对象技术了，java在标榜跨平台，后来标榜J2EE。.net标榜多语言大一统。只有delphi在说面向对象，现在也不干了，borland公司全力去发展企业级平台。OO当时如日中天，是因为它成熟了，已经占领市场了。对于前卫的社区与商家来说，成熟的技术本身还有什么好谈的。
至于语言，经历了从basica（Dos 3.3自带）到logo（一种控制小海龟画画的玩具语言）到pascal到c到c#与java的转变，同时要对汇编(80x86时代)，vba (包括office对象模型),java script (包括IE与NS对象模型),php,perl等经典语言保持个“能看懂，勉强能写”的能力，我觉得已经够累了。与其去学新语法，不如在已知的领域精益求精。而且现在每天都有新的平台，框架，标准，理念出台。象我这种喜欢考虑前因后果中间逻辑而不懂跳跃思维的人，实在不敢去想当什么新技术的先行者，只能奢望在新技术成熟取代旧技术之前能跟上时代了。

不错 学习中

好贴，学习…………

田兄：
文章已下载，容我慢慢研读。
我个人认为，能三层就尽量三层，即使三层存在着某些缺点，也只有我们在实践过了以后，
自己来克服这些缺点。当然，分的越细，粒度越小，可能会适得其反，这就需要好好把握
“度”。
我最近也写了一个项目，逻辑上分了三层。期间实现的一些细节，基本上是我闭门造车，
很多还是经不起推敲，因为项目时间紧，有些东西，还是凑出来就行了。没有深入的研究
O/R Mapping 等东西。所以总觉得还不太过瘾：）
我也写了一些东西，希望能还你探讨。
http://www.delphibbs.com/delphibbs/dispq.asp?lid=3601454

写得很好，谢谢！~我收藏了！~

回贴很放了一些暗箭，但是这些暗箭射的方向都错了，因而力量也就白费了，也就显得毫无意义。呼，这个话说得清楚，我想你应该能看懂了。但是写得我好辛苦。本来我写的是“回贴很放了一些暗箭，然而方向都错了，毫无意义”，不过一下想到你说得“我与jhwh兄沟通的最大困难在于，jhwh兄的思维跳跃得实在太快，喜欢在因果关系中直接说果不说因，又或者说因不说果，又或者因果联系比较松散，但又没中间过程”，我也只有增加几个字了，以免又产生误会，又在这些地方进行纠缠。
““万能药”是用了中文中一种叫作暗喻的修辞”
对，用的暗喻。“第一句的万能药与软件有什么关系，第二句是病句，但是我们都能明白它的含义，就是因为语言的内涵、外延和语境。”这个是我的原文。我真的没想到这也能引起问题。难道非要我这样写：万能药的原义是指甚么病都能治的药，外延就是什么都能对付过去，在“三层并不是包治万病的万能药”的语言环境下，万能药就是指各种情况都能适用的开发方式？改精简点：“万能药与软件开发之间的关系，在当前的语境下以及万能药的内涵外延，我们都能明白。”我真的没想到，很普通的并排句式，居然你把第一句的“有什么关系”看作了问句。也许你还奇怪，为什么这后面不用问号，而用逗号吧？我对于中国人这样不理解中文句子的现象，很感到无奈。这里没有任何讽刺的意思。也许是你英文环境呆久了的缘故。不要求弘扬，真诚希望你花些精力看看我们自己的文化吧。说一句，中文语句中的标点是与句子含义大有相关的。看来，这也是误会的一个原因。这个不是讨论的本体，略过不提了，如何。
“你不能从我的第一个回贴里面看出什么东西，是技术上的差距造成的，而不是字的多少。”
这个是我上个帖子得原话，你得这个帖子，更坚实得显示出了这一点。只是话稍微改一下，改为“你觉得思维跳跃，是技术上的差距造成的，而不是因果关系没写明白。”
“从一句很久远的“类是用来表达概念的”，一下跳跃到“认为还有...存在，很显然的的没有理解oo的根本”。“类用来表达概念”跟“不能为三层而三层”有什么直接关系呢？”
我说得很清楚了，三层二层，本质是oo的粒度划分。“用类来表达概念”是oo的根本，都是oo，怎么没有关系？除非你认为三层二层不是指oo的粒度。那么我倒是想知道，你怎样看待三层二层的。
瀑布、敏捷、rup以及设计的融合。
在瀑布中，需求的改变，需要花大的精力倒退。而敏捷rup，花的精力小得多。然而最根本的原因，就是设计的问题。瀑布中，由于需求暗示了所有都是正确的，人的惰性导致必然的只是写出达到需求的功能的代码；而敏捷rup，提出需求是不确定的，那么人的惰性，自然在设计的时候会考虑扩展性，以便以后的修改。那么无论敏捷怎样宣称随时重构，设计的时候，人是免不了要考虑扩展修改的。这样一来，瀑布也好，敏捷也好，rup也好，都显示出设计的共性来了：对象粒度的大小，对象行为的方式。显然，你和楼主看到的只是oo，而不知道其他，那么也就只有问我是否采用瀑布了。这个问题，说明白一点，就是贯穿整个讨论之中。我的观点：这些开发方式产生的设计改变，也就是对象粒度的划分，对象行为的划分的改变。基于这样的观点，我帖子里面谈到的问题，都是能从这个基准上进行讨论的。显然，这是基准，一切方式都围绕着它，该重构就重构，该抛弃就抛弃，并不是说一上来就能搞成这样。“坚持设计最小的信息类，坚持设计最小的交互类”，我的原话，我从来也没有说过能一下搞定。坚持里面就包含了反复的概念，就像说坚持学习一样。反复中，你认为没有重构这些事情？
这就是我们技术上的差距。我能够用统一的方式进行，而你们认为这些是各不相关的。
你说粒度到最小，就必定做三层，很好，支持了我说的：三层二层之类，就是对象粒度的划分而已。所以，粒度的大小，就是跟三层，设计是紧密相关的。这里的懂，是指做出好的设计，不是软件能运行就行的意思。不能够区分粒度大小，也就不能区分类的划分，这样的例子你马上就列举一个出来，就是关于“最小”这个概念。“最小”不是“小得不能再小，绝不可再分的地步”这样一个简单的概念。现在的“最小”没有标准，得靠经验。根据类本身特征，以及当前的目标，做到这个类本身应该做的事情，而不考虑其他，大概就这样。不过度，粒度越小，重用性越高，这是大家都知道的。所有，懂设计的人，知道怎样的类是粒度最小，什么时候设计什么粒度的类。而不是你的推论：“懂设计的人必定会将类设计到最小粒度”。同样，粒度问题和“类就是表达概念”是一致的。这句话是根本，其他的是衍生物。好了，如果还没明白，我确实说不出更多了，不然就不会有牛人写厚厚的一本书来阐述了。
很清楚了，我这里没有什么三层二层多层的分别，就是一句话：“类就是表达概念”。
好了，oo谈完了，再来谈谈strategy, multi了。
谈到这个问题，也就谈到了你的疑问：“你实际上真的遇到过做了一个项目，......只是改一下数据字段，其他什么都不用改就交货的情况吗？......至于调试，莫非jhwh兄的那次好事，改了字段不做调试就交货了？那就真是好到家了。。。”
显然没有。我上面帖子说的意思，是指我不想重新做这那些已经做过的事情。不是你说的这个意思。oo强调对interface编程，在gp里面能很自然的实现。Design Pattern只是惯用法的总结，只是出书晚而已，和gp是不同意义的东西。用oo的术语来说，不是同种对象，没办法比较。从你看 modern c++ design（一下简称 mcd ）的说明来看，你没明白什么是gp。“例如泛型编程，其他语言所以不跟进，并不是因为其太先进。而是因为这些技术在一定历史条件下有其局限性或者替代品，其他语言在观望而已”。这是你对gp的看法吧。而且你认为 mcd 就是“技巧”，里面的smart pointer，visitor，multimethods等等，一次编写，到处使用，难道没有大局？不是构架？构架本来没有一个好的定义，但是并不是非得做一个庞大的东西才能称为构架的。退一步来说，不是构架把。这个书除了前面的具体技术外，通篇讲的是怎样进行设计，居然你认为是没有讲设计？不是能认出 template<class T>就是懂了gp，根据三层二层的讨论，我觉得你对oo还要进一步了解，还是再等一等才看c++的库。
mcd 里面讲的是 traits和policy，而traits着重于类的特征，policy着重于类的行为；oo里面没有区分，interface只是区分了行为，这样造成 n 多的代码，实现很繁琐。strategy说的就是操作时要明确区分出不同的类。显然，traits + policy就是strategy的一个类。这就是我说的 mcd 就是讲的strategy。不过由于gp的特性，这个strategy与design pattern的strategy有了不一致的地方，traits + policy 就比 oo 提出的 strategy 要更好用，因为在不同的 policy 上施加不同的 traits，就能更好的组合，而oo是不能的。 好了，如果 对traits进行划分，对policy进行划分怎样？ok，boost 的 graph库就是这样做的，它对 traits 进行了划分，但是对 policy 没有。而multi 对policy 也进行了划分。看到没有，这个和 aop 是不是有相似的地方？但是aop玩的是事件顺序，与这样的设计不可同日而语。我对aop一点也不感兴趣。好了，假设采用这样的设计，而且也设计出来了，那么看看，这样的重用性有多高！而这些都是通过gp来实现的。现在的设计，是对结构进行重用，用建筑打比方，gp就是骨架，而oo的实体类，比如说通过名词找到的类，就是砖头，随便换就是了。这样的东西是太理想了，具体做下去，又会有很多东西语言没有提供，那么就是你看到的到处需要使用“技巧”。到处都是技巧，很容易让人花眼。好了，这下明白了gp是先进的了吧，当然也不够成熟。所以我一直很讨厌java c#针对c++来说事，“先进的思维都是在c++里面，java，c#都是拾人牙慧，而且还差得远”，这就是我的认为。因为你我考虑的层面是不一样的，所以我觉得没有对话平台。我做设计，关键地方我自己写，然后给开发人员使用。他们想知道为什么这样设计，我就给他们讲，平时确实不需要他们明白这些。
“多看看其他类型的语言，诸如c++， lisp，prolog，而不是一味的抱着oo，这样会对你的思维有着大的提高。”
这是我说的，显然你误会了。c++ 看gp， list 看函数式语言，prolog 看逻辑设计，这才是我的意思。你说的语言类库，大多数就是oo的衍生物，如果真的明白了“类就是表达概念”这句话，其实看它们也就那么一回事了，没有必要进行更多的关注。用它的时候，也就1周的时间来熟悉就好了。

我看不到图啊```

首先，想第一个说说万能药，kidneyball兄说的万能药，其实在业界早就存在，所谓万能药，如果用英文也就是silver bullet，没有银弹这篇文章已经在人月神话中存在，这点其实我想大家都不会有什么争议。适度是我这篇文章的关键，在开发过程中设计过程中提出一个度是我的目标。
有没有必要谈，接下来说。
第二，谈谈，为什么会提出这个题目？有人也问过我，回想我写这篇文章的初衷，从去年回到中国开始，到现在有了一年多接触国内软件界的时间，见识过很多各种软件公司的开发模式，有些甚至是国内很知名的企业。
要么一种，还是 复制 + 粘贴 的开发方式，项目在开端的时候看似很好，但是越维护越困难，最后没有人愿意从事维护这个软件的工作，纷纷辞职，项目崩溃。这点先不说了。
要么就是烂用三层，烂用模式，也很现实，本来很简单的一个项目，很简单的一个数据库直接的增删改查，做得所有的开发人员都脱了一层皮,
为什么？把简单问题复杂化了，这样的项目连发布有些时候都成问题，更别提需要的维护工作量了。
说一个我经常和人交流的例子，这个例子其实是直接导致我写这篇文章的导火索，曾经处理过那么一个事情，数据库中有三张表，一张表示Users,一张表示Roles,一张UsersInRoles表示Users和Roles的多对多关系。
现在要用一个程序,Windows程序，实现UserInRole的维护功能，界面那种，看来是简单得很，直接写SQL不会超过十行代码，我随便抓了个有一年多开发经验的人来实现，我所预计的开始时间不会超过1小时，结果，开发周期超过了7个小时，因而我做了他的code review,发现其中一个致命的问题就是他架构了数据访问层，逻辑层，加表现层。代码行超过200。
接下来，第二天我接到了需要修改这个需求的信息，也是很简单的一个修改，由于数据库中有类似信息的冗余，我们需要在这个操作界面中同时操作另外一套类似的信息表，我向他提出了维护需求，同样也是一人天的工作量。
这引起了我的思考，从而回顾了很多见过发生过的项目中的故事，发现了那么一个度。所以我认为有这样一篇文章存在的必要。
第三，谈谈&quot;类是用来表达概念的&quot;
我不是完全同意这个概念，这得看情况而定，这同样是个度的概念。
其实你不是第一个和我谈这个问题的人，曾经就和不少人讨论过，“OO的目标是什么？”，见过一种答案，“为了架构。”，也许和你的表达概念的目标相似（我片面的理解）.
那么我再接下来问一句，“架构的目标是什么？难道为了架构而架构么？”。同样的问题对于你&quot;为什么用类来表达概念的?&quot;
有一半以上用架构造的人回答不出来，只听过一种答案，“为了高内聚，低偶合”,也许你有其他的答案，也听听。。
再问“为什么要高内聚低偶合？”,目前我还没听到过超过三个人以上回答出这个问题。
一个最直接的答案，为了增加代码复用，增加了代码复用，可以增加开发效率和软件质量，同时增加软件的可维护性可扩展性。
从总体看，如果达不到这个目标，我认为任何的方法，包括你所指的&quot;类是用来表达概念的&quot;，都一文不值。这个整体将涵盖于整个软件存在的生命周期。
除了可以拿出来夸夸其谈以外，如果不提高效率和质量，这些方法还能有什么实际的用处？
第四，谈谈什么是复用。
所谓复用，当切仅当是在被超过一次以上的地方被使用称之为复用，而如果构造出来任何形式的代码只在一个一个地方被使用，就算采用了你所谓的最小粒度，没有被用两次，也不称为复用。很简单的例子：我需要构造一个计算 a + b的函数，你需不需要去考虑如果加号换成减号的时候能复用这个函数的方法呢？
这其实也是形成我第二个论点strategy vs. template的一个重要方面，strategy的可复用功能，如果都不轻易被其使用者使用，那么其复用又在哪里呢？
第五，谈谈你所指的设计。
当第一次看到你回贴的时候，我还真不明白你所指出的设计。
查查软件工程的书里面，软件设计包括很多，流程设计，类设计，架构设计(这里包括逻辑架构设计，物理架构设计)，数据库设计，UI设计.....
不才，我做过六七个超过100个人月的项目，不管是我带项目还是别人带我做项目，我还真没见过一个设计师哪怕是在项目结束后完成了这些所有的设计文档的，更别提在编码前。
所以的确很有兴趣知道你所指的设计，更想知道如果你能做到，而且是在编码前，我个人认为是个壮举。这也是我由你的话发生的问题的第一反应。当然有生气的成分，在前面的贴子中我已经说过。
我也不想和你谈所谓跌代和瀑布的模型了。
第六，再谈回三层，我在文中首先就支出了，在Martin Fowler的企业级架构中，单层也是三层的一种形式，包括在一个函数内实现数据访问，逻辑处理，相关展现的所有功能也是三层，不同的只是他没有分出Package而已,分出类而已。
况且，我也不完全否定三层的方式，后面的章节就指出了三层带来的一些好处，我的项目我就在推进分层，至少分出数据访问层，为什么，因为数据结构非常复杂，团对内如果每个人都去搞清楚整套数据结构的来龙去脉会花太大的成本开销。
分层可以解决这一问题，虽然，这会带来一些其他的负面影响，但是我觉得，利弊权衡发现分的好，所以选择分层。
最后，谈谈interface & C++
interface是我最喜欢的一道对于层次稍微高一点的程序员的面试题目,在此摘录设计模式里面的一段话&quot;Class inheritance defines an object's implementation in terms of another object's implementation. In short, it's mechanism for code and representation sharing. In contrast, interface inheritance( or subtyping) describes when an object can be used in place of another.&quot;
Interface本和所谓的不带成员变量纯虚基类没有功能性的区别，它的关键是实现了对象对于另外一个角度的抽象。
1995年原版的Design Pattern,我指的是英文原版，也有指出，在不支持Interface的语言，如C++,中，用继承Pure abstract class来实现和Interface的一个相同的概念。
C++和其他语言C#, Java，就其语言本身，不考虑其类库的支持来说，除C++支持多继承，以外在OO方面我没发现他有些什么不同，而Design Pattern中提出的所有概念也并非存在于多继承的概念当中，我就实在搞不明白C++和Java, C#语言对这方面的讨论有任何的意义。

To: chinaplate兄，
非常感谢你的回复，不管你是支持还是反对，我们可以一起来研讨这个问题。
其实以我的经验，当然只是个个人经验，我发现，如果在开发中坚持几个原则，第一尽量去避免重复设计，重复编码，第二坚决制止在任何代码中的复制粘贴，第三坚持重构，层在适当的时候会自然出现，我发现我写代码时候的一个很奇妙的现象。
尝试固然不是坏事，不过我觉得还是那个原则最重要，方法的目标是要提高开发和维护效率和质量，如果达不到这个目标就得仔细酌韵。
O/R Mapping工具你可以在网上搜索一下有很多的。。。不过好象各个工具有不同的评价，具体也说不清到底那个更好一些。
当然，如果以学习为第一目标，也不为怪，每个事件，每个人的目标会不同，你也会从中得到很多的启示。。。。。。

呃。。。jhwh兄，这就是你的不对了。大家好端端的在讨论学术问题，放什么暗箭呢。看了这里，我又用暗箭的眼光回头去看了看之前的贴子。还真是好理解了一点。所谓暗箭，就是要中的人不知哪里放的（有果无因）；看见你放的人都不知道你要射哪里（有因无果）；就算中的人知道是你放的，也不知道箭是怎样飞来的（有果有因没中间）。在此，我收回之前关于jhwh兄表达方式的所有说话并表示抱歉。说到底不是jhwh兄一时疏忽没有关照过我的理解水平，也不是我的理解能力极其低下。其实是jhwh兄的暗箭水平高超，有意为之而且完全达到了目的。自然在面对客户进行需求分析时能做到收放自如。
不过话说回来，以jhwh兄的中文功底，难道真的觉得将“然而”改成“但是”，“暗箭”前面加上“这些”（前面已经提过“一些”了，因此已经知道是复数），“毫无意义”之前加上“力量白费了，也就”，会有很大分别吗？看了这段话，一般人着意的地方是“到底有哪些暗箭”？jhwh兄又没说，也许这段话本身就是暗箭吧？
我觉得我们讨论到现在，我对jhwh兄一开始声称“楼主根本不懂设计”背后的原因已经比较清楚了。虽然对jhwh兄的某些观点还是有点疑问，有些地方不敢苟同。但这已经是枝节问题。记得我在第一篇向jhwh兄发问的贴子里提到过关于“没有对话平台”的三种可能。现在我已经基本可以确定，是属于第二种情况。因为从回贴看来，深得OO真义的jhwh兄已经是站在神的位置去宣布“尔等凡人皆有原罪”了。被神一般的人物说“你不懂设计”，根本无损于我们凡人原本的标准。这的确是我现在心中所想。因此，我觉得已经没有必要在这个问题上进行更为深入的讨论了。毕竟我占着楼主的场子与神对话也快有三四千字了。到了现在这个深度，一来我觉得已经大致了解的jhwh兄要表达的意思和建议，二来对于观众来说原来不懂的地方还是不懂，原来已经懂了的，在这个层面上也未必就肯轻易接受我们的观点。发展下去不免要变成毫无建设性的侃大山了。我是问题不大，正好练习中文能力。但纠缠不休不免惹人讨厌。如果jhwh兄不怕浪费时间，楼主也没有意见，我还是乐意继续讨论下去的。看楼主和jhwh兄的意思了。
不过既然已经成为jhwh兄暗箭的靶子，就此溜走好象有点滑头。我看这样吧，我这次尝试去找出jhwh兄的暗箭，看看对不对。在楼主未表态之前，不再回贴了。（关心技术问题的朋友，本贴不涉及技术，不想浪费时间可以跳过了）
暗箭一：
“万能药与软件开发之间的关系，在当前的语境下以及万能药的内涵外延，我们都能明白。”
字数少，结构清晰，逻辑清晰。但jhwh兄故意不用，而用
“第一句的万能药与软件有什么关系，第二句是病句，但是我们都能明白它的含义，就是因为语言的内涵、外延和语境。”
这种转折关系长句加插入从句再加因果关系的复杂句式。在简明的表达方式下，关于“第二句是病句”这个插入语的表达完全不见了。
以jhwh兄对中文标点的水平，不会不知道中文插入语一般用破折号。但jhwh兄特意选用了英文长句一逗到底的方式。令我以为后面的“它的含义”是指“病句”，而没想到原来是指隔了半个屏幕宽度之前的“万能药与软件的关系”。
至于把逗号当问号，我倒没有犹豫过。jhwh兄引用的这一句，前面其实还有一截：“看看引用的两句话，第一。。。。”，于是下文的“第一。。。”“第二。。。”都变成了“引用的两句话”的宾语补足语，按中文惯例，标点应该跟随主句语气。所以jhwh兄在这里虽然字面上用了逗号，但我无法判断“第一。。。”这个从句的实际语气。这一箭水平高超，我完全上当，以为“它”是指“病句”。所以前面关于第一句的东西就与主题意义无关了。于是只好发挥之前把“影响”还原为“印象”的容错能力，私自根据我所理解的内涵外延和语境把逗号“还原”成问号了。而jhwh兄放着有“万能药与软件开发之间的关系”不用，而用“有什么关系”，令我以为是问句，也许也是暗箭吧。
暗箭二：
“改为‘你觉得思维跳跃，是技术上的差距造成的，而不是因果关系没写明白。’”
如果我有神一般的技术，在jhwh兄最初一篇“楼主根本不懂什么叫设计”的时候就应该彻然大悟了。但是我没有，因为技术差距所以我对jhwh兄的因果关系不太明白。我强调一下，是“我弄不明白”，不是jhwh兄没写明白。jhwh兄不是在写，是在放暗箭。但我开始时不知道，所以尝试去理解。既然技术问题是硬伤，我只好老实说，“jhwh兄你的因果关系我不明白，能不能说清楚点呢”，这样我才能学会技术，去理解你的因果关系。但我当时不知道，神的职责并不是要去引导凡人脱离困惑，而是要去警示凡人：你只不过是个凡人，不要企图仰视神明。
暗箭三：
从“有什么直接关系呢”（我的原话）到“怎么没有关系？”（jhwh兄的话）。两句相减，差为“直接”。
我从来没有否认过“类是用来表达概念”这句话的正确性，也没有否认过它跟分层有一定关系。于是后面的“除非。。。”就成为了暗箭。讨论到现在，大致上我觉得jhwh兄的思路是1. “类是用来表达概念的”，同时2.“表达层，逻辑层和数据层是三个不同概念”，所以3.“任何应用程序一定要分成三层”。关于1和2，我多次说过，我认为面向对象和分层没有必然关系，不用面向对象方法，也可以分层。用了面向对象方法，未必就是分层。而jhwh兄对这个问题并没有正面讨论过，不过我大概可以想象出，jhwh兄会说“如果你真的这样认为，那么你还没理解OO与分层的根本”，而我会天真地问“那么OO和分层的根本是什么呢？”，jhwh兄会傲然回答“根本就是‘类是用来表达概念的’”。于是又绕回去了。
“类是用来表达概念”这句话是绝对正确的，因为一开始面向对象中类的概念就是这样创造出来的：将概念设计中属于同一概念的数据与操作捆绑封装起来。这句话的寿命可以说与面向对象历史一样长，而并不是某些OO之神在后来通过经验总结出来救世真言。这句话从一开始就伴随着面向对象而来，如果它能解决一切问题，我们今天也不会在这里讨论这些东西了。根本问题就在于，“概念”这个东西本来就是主观的。许多概念可以用一个大概念来概括；一个概念也可以拆成许多小概念。也就是所谓“粒度”的问题。粒度的划分也是主观的，正如我问jhwh兄，何为“最小粒度”，jhwh兄说：

“最小”不是“小得不能再小，绝不可再分的地步”这样一个简单的概念。现在的“最小”没有标准，得靠经验。根据类本身特征，以及当前的目标，做到这个类本身应该做的事情，而不考虑其他，大概就这样。不过度，粒度越小，重用性越高，这是大家都知道的。所有，懂设计的人，知道怎样的类是粒度最小，什么时候设计什么粒度的类。

点击展开...

说到底，就是主观的经验(*不是我的看法*)。于是jhwh兄实际的推理是：
1.“类是用来表达概念的”，
2.“概念的划分是要靠经验的”，
3.“懂设计的人知道怎样的类是粒度最小，什么时候设计什么粒度的类”，
4.“我是懂设计的人”
5.“我觉得任何时候都要分开表达层，逻辑层与数据层”，
6.“因此任何应用程序一定要分成三层”
（其中第4点，鉴于jhwh兄是OO之神，此条是公理，毋须证明）
关于，“好了，如果还没明白，我确实说不出更多了，不然就不会有牛人写厚厚的一本书来阐述了。”，虽然希望渺茫，但我还是希望jhwh可以告诉我这本支持你论点的书的书名，作者，出版社。你的论点——也就是我的论点“不能为三层而三层”的反命题——是“任何商业应用必须使用三层”。
（或者按jhwh兄的习惯写成: 你的论点，也就是我的论点“不能为三层而三层”的反命题，是“任何商业应用必须使用三层”。）

===================================================
暗箭我能明显看出的就这么一些，其他还有一些也是枝节问题，没必要谈了。但看到jhwh兄热心地为mcd一书写了大段评论，忽略不提不太好。因此简单列出一些不同意见。
1. “我上面帖子说的意思，是指我不想重新做这那些已经做过的事情。不是你说的这个意思。”，我想具体问一下，当时那个项目，总复杂度有多大？如果总复杂度很大，那么不在讨论范围，我强调过这种情况下应该用三层。如果总复杂度不大，那么你的三层项目改数据库字段的实际的改动复杂度有多大？在这些改动的复杂度中，有多少是因为这个“应变机制”本身造成的呢？请注意，我说单层，是指“在表达层出现数据逻辑，例如SQL语句”而已，并不是一堆乱七八糟的源程序到处复制粘贴。
2. “从你看 modern c++ design的说明来看，你没明白什么是gp。”， 这与jhwh兄最初的贴子，“从楼主的文章来看，楼主不懂设计”一样，对不起，由于我的技术水平有限，看不懂前因后果。(下一句引用的句子不是我看mcp的说明，是我对C中一些技术的先进性与历史性的看法而已。)
另，你问“这是你的看法吧？”，答，是的，因为我那时是看着这些概念产生和发展的。当然，OO之神如果认为对于一介凡夫的看法毋需举证反驳，只要说一声“你有这样的看法，看来你没明白其他语言为什么在GP出来那么久一直不引入GP的原因。”，我完全接受。
对于“Design Pattern只是惯用法的总结，只是出书晚而已，和gp是不同意义的东西。”。我没说过它们是一样的东西，只是说他们的出发点是一样的。Design Pattern（特指由GoF总结成书的Design Pattern）是通过OO本身特性来缓和类泛滥，GP最初的出发点是通过加入语言特性来缓和类泛滥。Design Pattern在总结成书之前有许多人零零散散在用，但在成书之前，并未形成可以推广的整体概念。因此我以出书日期来计算。但出现先后并不是“先进性”的关键，其实我也很想问问jhwh兄。你对“语言先进性”的判定标准是什么？别告诉我是“最先使用某种技术而这种技术最后变成行业标准”，符合这个条件的语言多的是。又或者是“该语言的社区最先讨论某种新兴技术，即使这种技术只有这个语言在用”。神请饶恕我问出这些愚蠢的问题，因为我的确还不了解明白什么“语言的先进性”，我甚至认为语言之间不存在“我比你先进”的关系。
3. “里面的smart pointer，visitor，multimethods等等，一次编写，到处使用，难道没有大局？不是构架？” MCD一书是研究如何写类库的，当然类库里有其框架，但细节与应用程序框架毕竟不同。因此不错，我认为此书所说的不是大局观，也不是我们通常意义上的“框架”(Architecture)。当然到了OO之神的“类是用来表达概念”的层面，所有事物都是共通的。太极生两仪，两仪生四象。。。。。
4. &quot;这个书除了前面的具体技术外，通篇讲的是怎样进行设计，居然你认为是没有讲设计？&quot;. 根据语言的内涵，外延和语境，我讨论到现在，习惯性的把“设计”局限在“框架设计”“概念设计”上了。如果jhwh兄觉得系统详细设计，程序设计的技巧在讨论之列，那么只能说“我们没有对话的平台”了。但如果jhwh兄所指的设计是“框架设计”或“概念设计”，请问哪一章哪一节？通篇？也就是字里行间？我要看完全书，把精神境界上升到“类是用来表达概念”的层次再去悟出其“概念设计”的精髓？嗯，我层次有限。。。。但你确定这是作者的原意？
5. &quot;这就是我们技术上的差距。我能够用统一的方式进行，而你们认为这些是各不相关的&quot;
在“类是表达概念”的层面上，我认为万事万物都是相关的。在具体问题上，我认为划清直接相关性有助于理清思路。例如“三层适用性”与“面向对象粒度”并不是直接相关东西。当然，凡人们可以通过推理，把不直接相关的东西建立起相关性。而大神们直接可以说：“所有事物都统一于‘类是表达概念的’，因此都直接相关——什么？概念是主观的？嗯，以我的概念为准。”
6. “‘先进的思维都是在c++里面，java，c#都是拾人牙慧，而且还差得远’，这就是我的认为。因为你我考虑的层面是不一样的，所以我觉得没有对话平台。”， 赞成。
7. “好了，这下明白了gp是先进的了吧”。不是“这下明白”，我从来就觉得gp是个好东西，不然我也没那么无聊去看一本讲GP应用设计的书。也很高兴现在java加入了gp特性。但这跟“一切先进的思维都是在c++里面”搭不上界。按你的逻辑，我是不是可以说“你看，java里面的类元素可以用反射机制按名访问。向正在运行的项目中添加一个类（例如Strut的Action类）完全不用重新编译已有的类，直接把.class文件复制到对应的运行包目录，reload项目就行了。好了，这下明白java是先进的了吧？一切先进的思维都是在java里面。c++连牙慧都拾不起来”？（请注意，这不是我的实际想法）
8.

“多看看其他类型的语言，诸如c++， lisp，prolog，而不是一味的抱着oo，这样会对你的思维有着大的提高。”
这是我说的，显然你误会了。c++ 看gp， list 看函数式语言，prolog 看逻辑设计，这才是我的意思。

点击展开...

嗯，这其实应该归到暗箭篇去讲。很感谢jhwh兄的建议，我忙完这段会看一下这两种语言。但是为什么在第一篇回的时候不直接说呢。难道你觉得，一个要你推荐才去看这些语言的人，会知道你的意思是看list是为了函数式语言，看prolog是为了看逻辑设计吗？不过，如果是暗箭。。。豁然开朗。。。

公道自在人心，我不喜欢jhwh的做法。
>>那边说了一次，这里再说一次：楼主水平相当的差，完全没明白甚么是设计。
真话有时是伤人，但是大多数这样的真话，能会使别人受益。
但是，象jhwh这样的“真话”，除了伤人，毫无益处。

精彩！！精彩！！！
kidneyball,jhwh的论点都很精彩啊！！
自己还要在设计方面多下功能啊！！！！

对于三层的代码量，我确实存在同楼主一样的困惑。把一句话分成三句话来说，确实有些冗长拖沓。而且在写同一层中的相似类时，免不了进行一些复制/拷贝操作。
但目前，我还是三层的坚定支持着，
1。正如一个好人所言，楼主的例子过于简单和缺少一般性，大多数情况下，需求的变化更可能是某个算法和流程的改变。即使需要增加一个字段，也不会简单的增加与其它业务都无关的一个性别字段，更有可能，增加一个字段会影响到其它的很多业务对象，通过分层，这种改变将在逻辑层中被消化掉，较少的影响到表现层。
2。我认为分层主要的优点就是使得程序员精力的集中，
当处理表现层时，应该非常关注与用户的界面交流，怎样才能最好的表述功能，令用户使用方便。
当处理业务层时，更注重实现需求的功能，各个业务对象之间的关系。不理会业务对象由谁进行如何调用，也不理会数据从哪里来，存到哪里去。
当处理存储层时，更关注与具体数据库如何打交道，如何永久化业务对象。