眼前一片澄明的境界，——我想写一本书， 给出一个对于设计有指导意义的书，让大家能够动手进行设计。 技术的发展让我们疲于应付，大部分书讲“是什么”，这里要在这个表面上给出一个本质的东西――为什么，什么驱动了软件技术的发展，生物进化论改变了人们对世界的认识，这里讨论软件进化的背后，知道为什么，然后我们应该怎样做？
看了你的“我终于大彻大悟了——面向对象，设计模式和构件”这个帖名，我发现本来脑子还算清醒的我现在已经迷迷糊糊了。 大彻大悟的软件设计难道仅仅在于面向对象、设计模式和构件吗？我建议你先去看看软件工程方面的书籍，把软件工程的知识补一补，然后再去想具有指导意义的软件设计方法（书）吧。 软件进化的背后有什么“为什么”？其实可以简要的概括出来，一是人们对软件的认识的扩展和深入，二是社会、科技的进步导致了人们需求的明确和激化，更重要的是人类不断进取的本质缘由。你的书里除了这些还要写什么？
1年后我就发现原来想的都还是有问题的，1年前你是向问题的本质前进了1步，但却远没有到达终点。随着你阅历的增长，你对同一个问题会不断的有新的看法。
算起来从事软件8年了，设计模式应用也快3年了，赞成你这种看法
这本书中的角色 “与大虾对话: 领悟设计模式”中以两个人对话方式，深入浅出的把Template Method / Visitor这两个模式讲了出来，本文受该讲述问题的模式启发，精心准备了多人对话的模式来讲述问题。 小E：软件行业的Expert，知识渊博，对新事物敏感，是小D的导师。 小D：软件设计方向的Doctor，正在做软件设计的论文，勤于思考。 小C：软件资深工程师，具有深厚的理论基础和理论联系实际的能力，是小B的Coach。 小B：刚刚从学校毕业的软件专业Bachalor，虚心向上，经常看小D，小E的研究论文。 小A：善良可爱的Angle，对计算机很有兴趣，经常听别人的讨论，并把灵感放到有准备的头脑中。 “选择书籍最重要的是看作者：一看他是否具有真正的水平；二看他是否能将技术阐释清楚。国内一些编书或者翻译的人对技术只是一知半解，又追求速度和效益，结果这种书只能是误人子弟。但水平高的人如果只有技术，没有写作和表达才能，或选材过于艰深，或文字晦涩难懂，也很难为读者接受。国内原创图书明显弱点是过于生硬，属于“冷面扑克型，不带任何感情，没有任何技术以外的润滑与承先启後的转折”（侯捷先生语），而且缺乏实用，看上去理论上面面俱到，可实际上却没有什么应用价值，所以国内几乎没有什么知名作者甚至译者，当然这也和出版大环境有关系。”
果然一针见血，含有一定的哲学道理，不过前辈们的书中仔细的研究之后 我想我们也在其中掌握了很多很多。。。。。
抄袭老外的人比较多
那些代码，都不在有人用了。它们都短命，死了。
这么写可以不，提意见： 多态 动物赛跑例子 在现实中，多态可以用下面的例子描述： 在动物运动会上，裁判喊道：“动物们跑”。兔子，乌龟，猴子等一起跑了起来，当然，兔子有兔子的跑法，乌龟有乌龟的跑法。 蹩脚的设计 如果没有多态，在软件世界中生活就没有这么愉快了。针对上面的例子：（欠缺rose图） CArea area; ArrayList animals=area.GetAnimalInArea();//获得某一范围的所有动物 foreach(Canimal animal in animals) //循环每一个动物 { switch(animal.p_type) //判断每一个动物的类型 { case Dog: (CDog)animal.Move(); case Monkey: (CMonkey)animal.Move(); } } 估计在多态世界中生活过的人们再也不会适应这种生活了。 （思考：如果您不知道多态，您认为上面的程序怎样改好呢？） 您经常这么思考吗？恭喜，您已经购买了进入各种软件世界的车票，软件世界也将为您提供热情周到的服务。 Oo发展的最初阶段是不是这样我不知道，也没有查资料。但是这种思考方式导致了多态的出现是一种合理的解释。在我做matlab的设计的时候，突然明白了多态的意义，当时就对产生这种想法的人心存敬意。 多态设计 在多态世界中： CArea area; ArrayList animals=area.GetAnimalInArea();//获得某一范围的所有动物 foreach(Canimal animal in animals) //循环每一个动物 { animal.Move(); } 或者在您的世界中： CArea area; ArrayList animals=area.GetAnimalInArea();//获得某一范围的所有动物 Animals.Move(); 老子有句话，“大道自然”，软件世界亦如此。从最早的机器码到现在的组件编程，无不体现着这个道理。越来越少的计算机特性，而越来越多的人性和自然性。
人法地，地法天，天法道，道法自然
是指刚刚使用面向对象时使用的面向对象技术，我特指继承和多态， 当然封装，隐藏是各种技术都想达到的目标，而传统面向对象是通过继承和继承多态来实现。 设计模式引入了一些有意的指导思想，本质上也是面向对象，我想分成两个阶段更好一些 我构思一种“热”构件，深化设计模式思想，达到一种比较自然的现实世界向软件世界的映射
厉害
看看建筑设计的发展史，建筑设计的现状，软件设计就有方向，也就知道软件的进化驱动力。其实我认为软件设计与其他领域的设计，都有着共性，其个性对其发展规律的影响是有限的，太强调他的个性，软件设计就很难发现其发展规律。愚见愚见！！我从来没开发过软件。很为你们急
高！俺就受害不浅。
一般面向对象的设计是抽象，如抽象到概念级，如洁具，并没有这么一个东西存在，这种抽象在面向对象的设计中体现为类层次，但是存在一个物品不只是一个抽象，如纸可以抽象为洁具，也可以抽象为书写用具，这就需要多重继承，但是所有的这些抽象都可归结为一个“物体”这种很高层的抽象，采用多重继承还有其他问题。传统的继承可以理解为纵向抽象，纵向装配。 纵向抽象和装配存在的问题是，所有的概念之间是耦合的，如果这种耦合是固有的，如物体和洁具之间，也不应该让这种耦合成为实现耦合。 可以用横向装配来代替，如组合实现，更灵活，无实现耦合，让纵向只存在于概念――interface，而装配采用横向装配。
“可以用横向装配来代替，如组合实现，更灵活，无实现耦合，让纵向只存在于概念――interface，而装配采用横向装配。 ” 未必！
如果老兄自己领悟了设计相关性－－高人， 劝你学软件设计 我也准备看christopher alexander的书，可惜没有下载到
关于软件开发流程和设计思想发展的介绍在大多数软件工程的书上都有，你如果想写的话可以拷贝或clone一下，但或许仅对在软件领域没什么研究的人看了有一定的启发意义，因为大多数人都清楚这方面的原理。 设计模式是长久以来很多高手对以往设计经验的积累和重用，就象在很多人都知道练武的原理在于充分发挥人的潜力，但并不是每个人都能悟出“九阴真经”或“降龙十八掌”一样。如果仅仅清楚一点皮毛的道理，自己又没创造出高深的招式，就算上大彻大悟并以此写书的话，我想怕会有误人子第之嫌。如果自己在学习过程中确实有一定的心得和体会，总结记录下来，或许对他人还是有一定帮助的。
想有浅入深的讲，现在在整理我的思路 有什么建议请指教 有些东西现在还不太能说出来， 佛曰：佛说法，即非法，是名为法。“金刚经” 有些经验性的东西讲不出来，可能我的深度还没有达到，不能把道理深入浅出的将出来。想说明白让后来者提高层次不是容易的事情 写书的主要目的是想后来者避免我们走过的弯路，对整个软件的发展过程（从oo开始）有清楚的认识，以及各种技术在实际面对一个系统时如何使用 大家可以帮我阿，经验，意见，建议，等，皆大欢喜 呵呵，当然这里写大彻大悟有哗众取宠的成分
心有戚戚焉， 当年不知看了多少C＋＋的书都无法入面向对象之门， 对抽象，多态、封装有着似是而非的感觉， 实际上还是本着来自C的概念。 只到有一天，看了《设计模式》中对面向对象，对委托等概念的描述， 才恍然大悟， ^_^！！！！
继承中属性冲突 说明：这里的客户端是类的使用者，服务端是类或几个类。客户服务是相对的概念，即服务端A使用类B，那A相对于B是客户端。 多态中讨论的例子说明（第一个问题），服务端设计不好会造成客户端编写程序的不便。同样，客户端需要的方便又会给服务端设计制造麻烦。 早期的oo思想是以继承和多态为基石的，设计出一个优美的继承层次，能够在各种需求变化面前robust是每个设计师的追求。正如refactoring中说的那样，因为包容使用比较麻烦，一般也不太使用。（在早期设计时我很少使用包容）。 流行的做法是针对问题域设计单根继承（也是迎合客户端使用方便），这也是很多软件框架采用的设计方式，比如Java，C#等。注意这里的单根继承不是单继承，是指所有的对象都从一个共同的祖先继承下来。 但是问题域本身的不纯洁性，软件本身的跨平台、安全性等要求，使合理的继承层次之设计相当困难。 蝙蝠会飞例子 （欠rose图）（动物，哺乳动物，鸟的继承层次） 象上一节一样，我们可以： CSky sky; ArrayList birds=sky.GetAnimalInSky();//获得天空中的所有动物 Birds.Fly(); 不错，看起来完美无缺。可是这里存在问题，如果用户对哺乳动物的需求中包括蝙蝠，问题就出来了。 为了照顾客户端的使用方便（多半如此，它们是上帝），通常需要我们对设计进行重构： （欠rose图）（这里把“飞”行为向上移动，为了客户方便移动到“动物”类中 客户端： CSky sky; ArrayList animals=sky.GetAnimalInSky();//获得天空中的所有动物 Animals.Fly(); 怎么说呢，哺乳动物会飞，想起来就别扭。而这种重构在设计中会经常碰到，结果通常一个自认为很完美的设计被这些“蝙蝠”们破坏的面目全非。 针对问题域设计的类层次通常因为“蝙蝠”等问题而丧失了复用性，在另一个问题域得不到复用。通常是这样的，在您发现一个类可以重用，但是又比你需要的内容多（如你需要的动物类不需要飞的行为），可是要去掉类里的一些与问题域无关的函数时会发现很棘手，很可能放弃重用。 这个问题并不是面向对象设计本身的问题，可以在面向对象的框架内方便的解决这个问题，这将在后面章节中介绍。 （思考，怎么才能解决“蝙蝠”问题，使蝙蝠问题在服务端只影响蝙蝠类本身？客户端需要做什么修改？） 举这个例子的目的是客户端的简捷性对服务端提出了多态要求。同样，服务端设计困难又反过来要求客户端的进步。
没有获得好的设计，也要提到这么高的高度。 如今的人，至少哲学都学得不错
视情况而定，那么说了等于没说。至少得有个基本的分类标准吧 如果绝对，我胆小，看见绝对的东东就害怕
还是现在书上的说明都精简了？与时俱进了？
一般的多态说法， 多态性描述的是如下现象：如果几个子类都重新定义了超类的某个函数（都用相同的函数名），当消息被发送到一个子类对象时，在执行时该消息会由于子类确定的不同而被解释为不同的操作。 采用我所讲的客户端定义可能更容易理解一些，
一直以为Thinking系列对这个说得很清楚了，你一排除语言相关，那么我就没有办法了。只能说我错了。反正面向对象开发的语言无关的书，就算设计模式也有C++例子，分析模式则不在乎什么叫多态。其他的更有可能是哲学书。
如果有人非要用一个不适合的设计，谁也没有办法
呵呵，大师与普通人的区别是前者讲求“图难于其易，为大于其细”，而后者讲求的则是“有物混成，先天地生”，这也就是为什么普通程序员，尤其我们中国程序员中，多有“哲学家”，而少有“科学家”的原因。
真是，每次看见别人说大彻大悟是都很羡慕，UML搞的跟修道似的。大家一心求到，捂者能有多少！！！
