转：表设计兼一些设计分析的讨论

http://www.cnblogs.com/guaiguai/archive/2008/04/13/1151761.html

一个兄弟的问题：

1. 比方说有一个学生选课系统，设计老师，学生和课程等实体，是不是为了扩展或者说为了灵活性亦或为了更OO应当在实际的应用中加上person这个基类？
2.再有比方说老师有教授和讲师，他们有各自不同的属性，如果不考虑数据的持久化，那么这个好像很好设计，但涉及到保存到数据库的时候，好像就很难处理了，在现实中我们应该不会有教授表老师表和讲师表，也许只有一个老师表，而会出现标志位的字段判断是否是讲师，是否是教授，但如果这样一个类对应一个数据库表应该是不错的选择， 这样的话，实体类就应当有一个老师类就可以了，教授类和讲师类就没了存在的必要，那么OO继承的优势何在？对于这样的问题解决方法是什么呢？

关于建表和对象继承：

首先， 我觉得如果你对面向对象设计的信息系统感兴趣， 可以看看Martin Fowler的《企业应用架构模式》。简单的说两句， 对于一个继承体系， 至少有三种建立关系模型的方式：

1. 一个老师表， 但是这个老师表， 同时有字段对应教授和讲师的属性， 一个教授的行， 其讲师的字段是空的， 一个讲师的行， 其教师特有的字段是空的。 对于很多现代数据库来说， 其冗余的Cell是不会占用存储空间的。

2. 假设没有老师这一具体职位（也就是说老师是抽象的基类），一个讲师表， 一个教授表， 这两个表具有一些相同的字段， 既教授和讲师共同具有的属于老师的特性的字段。

3. 有老师表， 讲师表， 和教授表三个表。 讲师表仅存储讲师的特性， 教授表仅存储教授的特性。 继承体系可能是这两种（讲师<- 老师 -> 教授），或（老师->讲师->教授)， 但无论是哪种， 子类通过父类的ID， 和父类表向链接。 比如， 无论多了一个教授， 还是一个讲师， 老师表里都会增加一条老师记录， 如果是讲师， 同时在讲师表里插入讲师特有的信息， 如果是教授， 则同时在教授表里插入教授特有的信息。

所以， 对于一个继承体系来讲， 不见得在现实里只有一个表。 另外一点， 我个人认为， 这些不同的表的划分方式， 其实即使没有面向对象设计， 也是合理的， 同时自有其判断依据： 比如方式3， 有些场景， 我们仅仅需要老师的那些特性， 所以仅存取老师表即可； 有时候我们可能仅处理教授的特性， 而那些作为老师的共同特性反而不关心。 一旦我们关心全部特性， 我们可以将表连接起来。

以上三种方式， 都有一个前提， 既讲师和教授， 都有比起其父类， 更多的特性。 如果讲师和教授， 仅仅是身份不同， 像你说的， 最多有一个标志为标识其身份，我们不谈面向对象， 就谈对这件事的认识。

在 现实生活中， 讲师和教授也许是有很多不同点， 以至于我们必须明确的分割这两种身份。 但是我们就我们所处理的任务的角度， 他们或许没什么不同： 系统内部只关心他们作为老师的一些特性； 而一些差异， 则仅仅是是一个子特性， 没有必要甚至不能够，上升到让这两种身份在*任务的视角上*产生真正的差异。

比如： 我们给不同身份的人发不同的工资。 这些仅仅是我们根据特性展开的， 其具体内容属于另一范畴的东西， 对于老师这一个概念来说， 身份只是一个很普通的标志， 就好比他是男还是女一样。 因为大多数关心的主要任务和这个属性关系不大， 所以就不会在系统内部设立两个不同的概念。 比如男的上男厕所， 女的上女厕所， 这是一个额外的规矩， 是在与人这个概念关系不大的其它部分进行的； 但是如果我们任务关心的问题， 就是女人和男人的差别， 情况则不同了。 比如女人和男人的体貌、 行为、 性格， 这些特点如果是我们要处理的， 很显然， 我们应该明确划分这两个概念。 从面向对象、特别是继承的观点来看， 我们需要至少两个对象； 当我们有时候同时关心男女共同为人的特点时， 我们还需要一个叫做“人”的基类对象。

在建表时， 也就会产生我上面所说的三种方式的不同差异。 至于三种方式的优劣， 暂时不能逐一展开， 不过Fowler那本书里都有提到； 不过读哪本书时， 可千万别当成什么金科玉律， 肺炎的种类很多， 不是吃茴香都能治的。

闲谈：

不 过我们至少可以看出， 我们如何建表， 如何找到合适的模型， 并非是照搬现实生活里存在的概念的； 而是从我们的任务的视角上看过去， 存在哪些概念。 后者的判断， 在于我们关心些什么， 关心的这些内容， 造成了哪些程度上的不同， 有很大不同的时候， 我们需要不同的表达， 没有不同时， 我们就采用统一的表达。 而类设计和表设计， 只是我们表达的体现而已。 那么， 你所面对的问题， 从各方面来看， 需要几种表达方式才能完善呢？

同时， 我们在这时候， 不要过多的去考虑全局到具体， 而是把问题割裂开。 这个事情和谈恋爱正好相反，粘在一起的东西， 扯开比较费劲； 而把东西粘起来， 则相对容易。 这是因为我们人脑同一时间可以理清的东西有限。 所以我们要明确的认识到， 哪些东西可以规划到“男人上男厕所， 女人上女厕所”这样的外部规则， 哪些东西满足“男人和女人不同的特征”。 如果一时不容易分清， 至少我们在信息的量上可以做把握(不过这样把握的方式其实不是实质性的， 随着理解的深入， 就要放弃了)， 后者往往涉及到一系列信息， 而前者中“男”“女”仅仅是一个用于填入规则的标志。

当然， 我们设计了一个表， 其中有一个字段存储“男”、“女”， 进行面向对象的设计的时候， 我们照样可以弄出一大堆类， 继承人这个类。 当我们调用， 人.上厕所（）时， 就各去各的厕所了。 面向对象一般鼓励以这样的方式， 去给出统一的接口（比如这个例子里“人”）。 其优势在于， 当我们多出其它性别时， 比如“半男半女”、“不男不女”， 那些调用“人.上厕所()”的代码， 全都无需改变。

这里有一个假设， 在于“人”这个接口， 比如具有一些属性， 具有一个“上厕所”的方法， 这个接口是稳定的， 不会改变的。 当我们在进行设计时， 要衡量这个假设是不是成立的。 比如上厕所这个行为， 有可能在未来变化为“上厕所（带手纸）”， “上厕所（没带纸)”， 这样一个接口的变动。 很多面向对象设计只所以问题连连， 就在于做出了时效性太强的假设。

为什么这么说呢？ 因为接口是有很大概率会变化的， 其区别仅仅是一个月之内就变， 还是这个系统用了3年才变。接口一旦发生变动， 我们往往就要为当初获得的好处埋单了。 所以如何设计， 有时候不是一个绝对化的问题， 而是一个想办法付出最小代价的问题。

对 于上厕所， 我们可以统一的把上厕所的具体问题外包出去， 比如针对各种情况可能采取的各种方式， 这样我们就产生一个“上厕所的办法”这样一个外部概念。 我们可以想像， 当一个人脑子里有这个概念的时候(“人”这个类别的对象持有某一“上厕所策略”）， 就可以根据判断“我是女的， 我上女厕”、“我没带纸、找张报纸”进行行为， 你可以说这些是这女的想的， 但是你也可以认为这些仅仅是外部规则， 这女的只是按照规则机械的行动而已； 这后一种看法， 实际上使得我们容易在计算机上设计。

这时候， 我们无需使用继承的体系， 而是采用“人.上厕所（策略）”这样的接口， 那么如果我们所关心的“男”、“女”， 和带纸没带纸一样， 仅仅是上厕所策略用以判断的素材而已； 这样， 我们就不需要男人类和女人类了。

从 以上例子来看， 类的设计和表的设计， 不是说一定要有必然的联系。 因为既然我们写了非存取的代码， 就说明我们除了可以记录下来的特征， 还关心其它的非可固化性质的行为， 那么我们如何设计类、 对象， 则必须从这些行为以及系统中各个对象交互的视角上出发， 而不是考虑我们的表如何设计的。 注意， 这不是说我赞成以实体类去设计表， 关系模型关心和表现的是事情的另一个侧面， 所以设计表恰恰不能从对象设计倒回去。 它们之间应该是正交的， 不要存在一个依赖另外一个这样的耦合。 如何让他们兼容， 需要且应该做额外的工作。

当 上面的例子简化到一定地步， 比如 if(男) ... else ...时， 我们也不需要什么策略的对象或者类， 有一些用于体现策略脚本处理即可。 到了这个地步， 我们也许一个实体类都不需要有。 我们就简单的把系统看作根据具体情况作出判断和处理的策略系统就可以了， 这时候我们需要的仅仅是信息的载体， 这就是为什么我经常会说， 当产生了贫血对象后， 我们要考虑的不是把它变复杂， 而是看看能不能把它从系统中抹去的原因。 很多时候， 贫血类比起一个通用的信息载体， 除了字段和属性强类型的好处， 仅仅发挥一个自身标识的作用； 但是当我们调用“人能做的事情静态帮助类.上厕所(信息载体)”的时候， 实际上我们已经隐式的传递了这个标识； 我们也可以设置一些具体的手法， 保证安全。

总结：

最后， 我们再来看看这些区别， 强化一下印象：

1. “人能做的事情.上厕所(信息载体)”、“人.上厕所（）”和“人.上厕所（策略）”之间如何取舍， 在于复杂度， 复杂度上升到一定程度， 我们要采取后者； 这是为了避免前者“上厕所”这一Rotine其内部复杂度上升的太高， 或者被频繁修改。 另外一个更明确的判断点在于， 人是否带有可变化的状态； 上厕所这件事是否有很多的方式。

2. 假设我们采取了含有“人”这一样一个概念的具体表达的设计， 人这个接口如何保持稳定是我们要注意的。 比如“上厕所”这一行为隐含的变化， 或者又增加“吃饭”等行为， 都属于接口的不稳定， 如果这种不稳定在短期内就会出现， 我们应该把行为和规则外包给其它概念， 而不是让它们依附在人之上。 如果我们一出生就是狼孩， 本来我们也不会具有这些概念所指的行为； 并不是说“主语.谓语”， 这样的设计方式就是合理的。

3. 我们是否需要“男人”、“女人” 或者 “讲师”、 “教授” 这样的继承体系， 可以这样判断： 必须共性大、同时差异也大。 组合比继承好， 这是从95年《设计模式》以后被大家广泛接受的原则。 很显然， 共性和差异同时非常大的情况不是特别多见。 也许我们平时见惯了我们的aspx页面继承于Page， Page又继承于TemplateControl和Control。 且不说合理与否， 这并不能说明需要继承的情况很多。 因为这样一个继承， 使用了10000遍， 它其实还是一个继承。

4. 表设计和对象设计是两码事， 要按照各自的特点来做； 同时追求两边的合理性， 要付出的代价就是多做中间工作， 这些上面说的比较详细， 就不多说了。唯一可以说的是， 在成本上考虑， 我们要做好折中的选择。 更多的则是， 无论哪个设计， 无论什么设计方法， 我们别想太多， 更多的要找出我们关心的全部内容， 而不要把在现实生活中的知识带入过多； 因为对我们要解决的问题所在视角， 这些知识可能就成了不必要的偏见， 或者至少像用大学物理解释初中物理题。

这些问题其实在学习面向对象以后， 做类似的信息管理时， 非常普遍。 我想你先问问自己， 你自己想采用什么样的设计呢？ 其次， 看看自己能不能找到这种设计的扩展或灵活性的好处。很多时候， 我感觉咱们想面向对象的冲动， 是因为不面向对象， 好像就不是一个设计， 简陋了些。 首先要克服这个心理。 如果找不到一个设计的好处， 而非要面向对象的话，即使存在一些好处， 也不是我们可以掌握的； 如果反而添了不少麻烦， 这些麻烦也不容易被找到。

总而言之， 我觉得， 不求巧， 但求拙， 不给自己的思路下套子， 不引入过多的杂念， 是设计的一些好的准则。

谈下我的看法：
首先OO中的“继承”这个概念“Object”的集成，而非现实生活中的继承
我比较反对老师讲OO的时候用什么学生老师继承Person这种例子，容易误导人
虽然说OO是“模拟现实世界”，但是OO的继承基础应是“属性”和“行为”的继承
如果系统设计中教授类和讲师类具有很多类似的属性（比如Name Age）来自于Person，具有类似的行为（比如Tech,或者Eat）,我们就考虑让他继承Person或者Teaher，如果系统里讲师和教授本身就毫不相关，那继承就是多余的
有个著名的例子就是正方形该不该继承长方形
从现实角度是肯定的，但是从OO角度某些情况下正方形并不具备长方形的SetWidth和SetHeight两个行为以及Width和Height两个属性，因此不能使用继承

然后就是建表的问题
《企业应用架构模式》里面总结的一些建表方式只是总结而已，并没有太多的提到优劣
如果有一套完美的ORM或是什么tool，我完全不需要关心你到底如何建立数据表，我只管我的OO设计（当然现在还没有这样的tool，以后会不会有这么完美我不敢说，但我相信一定会有往这方面发展的趋势），那就是另一种情况了
这些时间看了好些系统，确实没以前那么迷信oo了，一方面很多地方oo几乎完美的解决了问题，很赞美，一方面很多oo还搞不定的地方手上有很多工具或者传统的模式解决了问题，也很漂亮
就好象上面说的aspx page control什么的继承，不管他“理论上”合不合理，用了这么多年确实好用，没出什么岔子，他就是最好的
所以最后又是那句话 不论oo不oo，适合的是最好的
2008-04-14 01:53 | Yannic Yang

你说的对， 我起标题的时候就觉得别扭， 自己还找不着原因。

称体重的时候， 参数应该是， 一个有重量的玩意， 是不是人咱不关心～

说到这方面， 多说两句：

有 一种设计是很差的， 所谓的面向接口经常犯这个毛病。 为了让一些代码稳定下来， 搞一个“重量”接口， 搞一个“身份证”接口， 然后弄一个所谓的“人”的类，直接实现这些接口, 要么弄个Wrapper什么的; 或者来一个重量实现， 来一个身份证实现， 到下一个系统同时用这两个概念的时候， 再弄个组合什么的。

有些时候这样可以的甚至是必要的， 但这种做法变成一种指导以后， 实质上是在鼓励非常厚重的胶合层和做无用功，而这些东西不是没有代价的。 把这个当作原则， 是面向对象思想一个非常不成功的补丁，这不过是一种很具体的手法罢了。 如果说它换取了什么， 也要看具体场景， 最差劲的情况下， 它连初学者的东拼西凑都不如。

我不是想讨论表设计， 我数据库功底一般， 除了怎么让它设计的符合需要， 唯一感兴趣的地方就是数据仓库中的维度建模， 还是分析和设计层面的东西 :) 。 其实我也不喜欢说面向对象了， 说的口水都快干了，味同嚼蜡； 不过有人问， 越写越多， 结果不得不单发了； 反正如果谁选择了学习面向对象， 我这些不上台面的东西也许或多或少有点用。

说句实 话， 什么数据与行为打包啊之类， 真是看上去很美，其实质不过是些糖豆（这也意味着还是有方便设计和实践的用武之地的）， 而糖豆吃多了要长肉和蛀牙的； 要是2年前别人跟我这么说， 我肯定不信。 不过要说明的是， 如果有兄弟正准备兴致勃勃的摆弄这个， 也不必在乎我这盆冷水， 关键是面向对象适不适合你的领域。

我在这个过程中， 也学到了很多东西， 所以也算没白摸索。 而且正是对其缺陷的认识， 逼我不得不把目光转向FP和TMP， 并且试图把所有的东西结合起来； 这期间我似乎若有所感， 认识比以前完善了很多； 同时， 这一过程也让我找到了我喜好和擅长的方向。

另外， 我更不是支持那些还没有深入接触过面向对象的兄弟鞭挞面向对象的行为。 事实上， 面向对象作为20年来最重要的革新之一， 不仔细了解它， 可以说就不可能掌握现代程序设计的思路， 更不论体会问题所在了。如果你要放下它， 必须先要拿起它。

刨 除对于面向对象的执着， 很多思想， 像DDD这些， 很多根本性的东西还是好的， 对的， 只是也许他们选错了实践的工具， 使得他们的思想在一些地方施展的时候仿佛有点碍手碍脚。 不过， 既然我还要使一段时间面向对象的语言， 现在也许是我最适合使用它的时候； 我还是觉得， 你越发现一个东西烂， 说明你对它掌握的也越好了。

嗯嗯， 话有点多了， 闭嘴闭嘴， 毕竟这些问题我也没能解决， 只是在探究中， 自己憋思路去了...
2008-04-14 10:43 | 怪怪

@guaiguai
你的东西很多我都认同。
正如你所说得，刨除对于面向对象的执着， 很多思想， 像DDD这些， 本质上的东西还是好的。

所谓的面向接口经常犯这个毛病，应该是一个粒度问题，这些很难把握。

oo本身有局限，比如静态特质
比如一群人排好队，开始报数，这时有人跑过来插到对中，到他的时候，他也会报数。这应该算是aop的东西。

另外对现实抽象的问题。我想有时应该是看问题的角度错误。
比如类似这类：现实中父亲、母亲、儿子
儿子继承父亲、母亲。儿子具有父亲、母亲的特征，这也符合现实。（之所以符合，是因为我们没有去考虑他们之间的可变性），但是却带来了一些问题，比如：儿子不具有女性的特征。
我觉得有一种思想很实用，共性和可变性分析。在共性的基础上进行可变性分析。当可变性导致共性出现缺陷时，应该重新进行共性分析。
2008-04-14 11:23 | bmrxntfj

@bmrxntfj
那段话我说的比较偏激， 已经重新编辑过了。

粒度的问题只是表象不是核心的问题， 对于接口来说， 粒度小了， 很多时候其繁文缛节就又增加了； 大了， 那帮子专家大师都说的很清楚了。 在这里， 面向接口最大的问题是， 它实质上是想掩饰问题， 所以做起来就必须小心翼翼，注意这个注意那个。

该 使用这一手段的时候， 就必须使。 关键是不能把它当成一个指导原则， 而这正是现在所鼓励的。 AOP呢， 则是另外一个补丁； 以前我总觉得这么一个手法， 被上升到一个很高的高度， 似乎不合理； 想到面向接口是一个原则我都相信了好一阵子， 那么AOP被热炒也是应该的。 类似的还有IoC等等。

你说的最后这个问题也是个问题；动态语言要好一些， 但是动态语言没有静态检查， 这个实在是我不能容忍的了.... 其实问题还有很多， 只是一时不能全都列出来， 毕竟对于这个“认识其不足”的话题， 对很多人包括我来说才刚刚开始。

我个人认为， 贡献咱们要加分， 不过面向对象想成为软件构建从具体的底层实践到方方面面的上层规划的基石， 这个尝试应该算是失败了（虽然现在正是最热闹的时候）。 仔细看了看， 有些言论， 如果引起别人注意， 我就又能盖房子了.....， 匿了匿了

2008-04-14 11:29 | 怪怪

对象本来不存在，只是楼主一想，它就存在了。别叫它对象好了，免得让楼主吃不下中午饭。就叫它“那个东西”吧。


那个东西跟其他东西有啥区别呢？嗯，也不先不问问为啥要区别啊？是啊，为啥要区别呢？因为楼主想区别它们了，这总行吧。行，没啥不行，那就得先得找到那些东西的不同点。

是不是说那些东西有共同点？废话，没有共同点又如何去找不同点呢？结果，凡人就一个一个地找不同点，找到一个A，就把那些东西分成两类，再找到第二个B， 又分出一类...就这样，找啊找，想啊想的，最后找到了Z，就这样按共同与不同分类，就弄出个名叫“继承”的分类结构A-B-...Z。俺瞎猜的，俺虽然 是凡人，但凡人不只俺一个。


楼主呢，另辟蹊径，先找到了不同点Z，然后又找到了Y，最后才找到A，结果楼主发现自己搞出的类结构是Z-Y...A，与凡人不一样啊。俺瞎猜的。


楼主痛苦啊，为啥自己看到的与凡人不同啊。但正因为楼主不是凡人，他立即意识到A-B..Z的结构也好，Z-Y..A的结构也好，这并非那个东西的本质。而本质的东西在于M,U,K,Z,B,C,A,....，与继承的顺序并没有关系！

俺瞎猜的，真不好意思

。

于是楼主提出以大胆的观念：任何东西的背后一定是由若干本质的概念构成，而这些概念之间相互独立，而那些东西不过是这些概念的组合而已。


于是，楼主从这一高度立即发现了“接口”的理论基础，再看“面向方面”所说的“方面”不正是这一个个的A,B,C..吗？

俺瞎猜的


既然是这样，我们设计数据表时，为啥不直接设计那些A,B,C...本质的东西呢？然后用一个ID来将这些本质记录串起来不久行了？任何东西在这里都有一个ID，至于其是否在A中有记录，就看这个东西是否具有A本质。这个思路多清晰啊！


传说中的对象数据库就有那些东西。俺都是瞎摸的，摸错地方你哼一声。


2008-04-14 12:48 | 李战

@李战
倒， 你的表情好多啊...， 另外让你猜中了， 我确实没啥胃口， 没吃午饭； 饿着肚子自然也没多大劲儿“哼”了～

说 实在的， 你猜的没有一样是我所想的。 最上头表的那一段， 也不过重复下Fowler之流的介绍， 只是因为有人可能关心才拿出来晒晒； 这些并不是我脑子里关注的东西， 可能你心思放在这些比较多， 就认为我也再说这些...； 我说的很清楚了， 我更关心FP、TMP以及各种实践代表的不同思想融合的问题，你怎么就没看见呢？

我当然是凡人， 但是我也是个闲人， 闲人瞎想的就比较多嘛 :) 另外我觉得你最好直接一点， 太高深了我就看不懂了， 万一以为你在夸我呢， 平白无故骄傲一下， 自作多情多不好意思啊.... 不过看表演还是挺开心地～

关 于面向对象、AOP和接口， 其实我想的和所表达的跟你说的完全是两码事... 能理解就理解了(千万不要误会， 我可不是说什么比《对象真经》高深的境界，仅仅指我的个人想法)， 不能理解， 就只当我在痴人说梦吧， 只希望这“面向对象潮流”之中的些微冷水没溅到你身上就好。

谁都希望自己的知识能保值， 但这可不是找个哲学依据， 跟“无象无形”拉上关系就保险了的。 也许你确实是“横看成岭侧成峰”了， 那就当我什么也没说好了 = ) 不过还是推荐你看看Linus对面向对象语言的抨击， 虽然那个老愤青比我偏激多了。

最后， 即使存在鸡同鸭讲的情况， 我也不拒绝交流； 如果意识形态的问题咱们没法互通， 至少可以就具体环节讨论一下。 我提出的和想解决的都是实际问题， 可不是什么一二三四； 如果你有具体的解决办法， 不吝赐教。

前提是大家别像刺猬一样， 凑近了就互相扎一下， 多疼啊～
2008-04-14 13:35 | 怪怪

@xiao_p(匿名)
你指的Post是指这个贴还是包括以往的呢？ 感觉具体的问题我都有提出一些措施的吧..， 如果是涉及到抽象问题的，你说的很对，我只是我也在摸索阶段， 对不足的认识比较多， 解决的方法还在研究中。 我心中有一些思路， 可是感觉还不太成熟， 也不容易表达。 现阶段我主要是通过TMP或者更FP的风格在具体地方规避问题， 还没有统一的解决办法。

比如， 对于数据层， 尽量少做PopulateData的任务， 而是传给数据层方法不同的Function和其它信息。 这样数据层就不必依赖于BL， 在具有更多的通用性的同时， 避免框架式做法带来的僵化。

对 于不同性质的任务中特定的组成部分， 我把他们拆散放到不同的包中； 那些相对统一的过程和形式， 把它们放到另一一些包中， 用比如FP风格的写法来忽略所有特定的知识； 最终的应用部分引用一个粘合用的包， 而粘合包是面向应用临时制定的。 这个粘合包就是根据需要， 选取第一个集合中的组成部分作为素材， 第二个集合中的规则作为形式， 粘合出应用所需要的部件。

但是这个过程中存在很多非常具体的问题， 我也在解决之中。 举一个问题的例子，因为我们工作时，并不是所有的东西都是自己写的(比如.NET框架就不是咱们写的，但一定要用的)， 其中一些依赖于特定的接口， 那么在粘合时如何考虑这些问题。

但 至少， 比如引入FP之后， 我们对接口的依赖和假设就降低了， 而粘合的工作更像是声明性的，结构清晰； 工作量也要小的多， 同时可以利用编译器为我们执行静态检查； 另一点好处就是， 由于我们把粘合的工作单分出去， 并且变成了容易管理的形式， 就可以避免面向对象厚重粘合层带来的负担， 和Linus所谓的围绕漂亮对象建立模型而导致的弊端， 使得这一部分工作变成低成本的， 可抛弃、可替换的。

这些东西现在在我的脑子里还不足够清晰， 所以没法很好的表达出来。 我之所以强调问题， 也是希望大家能够更加明确的注意到很多当前做法的弊端， 从而集思广益， 找出更好的办法来 :)
2008-04-16 23:06 | 怪怪