随便说两句：表设计兼一些设计分析的讨论
总而言之， 我觉得， 不求巧， 但求拙， 不给自己的思路下套子， 不引入过多的杂念， 是设计的一些好的准则。
评论：
#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，适合的是最好的
#12楼 回复 引用 查看 bmrxntfj
@guaiguai
文章讨论设计，但问题的出现，我觉得应该算到分析里面。
DDD应该能够解释。
我想老怪的主要意思是具体问题具体设计。比如一个这样的系统，要称体重，现实中应该是让一个真实的人站到称上面，
那参数应该是人。
而另一个系统，要查一个人的成绩，现实中我们只需要报上身份证即可，那参数只需一个标识。
我不太喜欢讨论表设计。
@bmrxntfj 怪怪
你说的对， 我起标题的时候就觉得别扭， 自己还找不着原因。
称体重的时候， 参数应该是， 一个有重量的玩意， 是不是人咱不关心～
说到这方面， 多说两句：
有一种设计是很差的， 所谓的面向接口经常犯这个毛病。 为了让一些代码稳定下来， 搞一个“重量”接口， 搞一个“身份证”接口， 然后弄一个所谓的“人”的类，直接实现这些接口, 要么弄个Wrapper什么的; 或者来一个重量实现， 来一个身份证实现， 到下一个系统同时用这两个概念的时候， 再弄个组合什么的。
有些时候这样可以的甚至是必要的， 但这种做法变成一种指导以后， 实质上是在鼓励非常厚重的胶合层和做无用功，而这些东西不是没有代价的。 把这个当作原则， 是面向对象思想一个非常不成功的补丁，这不过是一种很具体的手法罢了。 如果说它换取了什么， 也要看具体场景， 最差劲的情况下， 它连初学者的东拼西凑都不如。
我不是想讨论表设计， 我数据库功底一般， 除了怎么让它设计的符合需要，