面向对象的荒诞之处

嗯，楼上，赞同你的方法论，也觉得面向对象本身并不会要求不能多余几个属性。不过我发现这变成了一个不可证明也不可证伪的奇怪问题了，呵呵。你觉得世界上可能存在真的大于几十个属性的对象，而我恰恰觉得从事物构造上来考虑，很少有几十个独立属性的对象。不过这种也不是1+1等于2的问题，真举出了大于几十个的属性，也可以“故意”通过各种逻辑划分来分割成手脚头组成一个人咯，呵呵。
总体来说，同意你的基础观点，只是我们出现这种情况的时候，主要还是自己设计的问题

贫血模型的无奈，你不能责怪架构师，大家都这么干的。
如果你在实体类里写入了过多的业务逻辑，说不定还会遭到整个开发组的批评和抵制。

看到有人要把一个user表分成几十个表，叫人着急得不行啊！

还有人说性能不重要。这些人简直是猪头。

*过多的类和表，必然性能很差。维护很难维护。

互联网第一要素：快。你打开这个网站慢过5秒，人家是不会再来第2次的。内部网那另说。

其次，维护速度要快，一个jira ticket,必须2小时内修改完毕。否则客户满意度就急剧下降。

再次，你们好好研究一下你们版本控制系统，一个运行了5年的项目，到底那些类和包是经常修改的。那些复杂的类结构是从一开始到现在都从来没有变过的。


我敢说，从架构开始后，数据库基本是不会变的。


的确，阿里巴巴把数据库从mysql变成了oracle然后又变了回来。

但是人家有钱啊，你的项目要有钱，那么也可以这么折腾。

阿里把数据库从mysql变成oracle，又改变回来，每一次改变都被认为是正确的。 这个跨度跨越了许多年，实事情况一直在发生变化，这些变化促成了这些决策。
你居然把它们归结为“有钱”和“折腾”，看意思是谁有钱谁可以随便这么折腾，犀利！

不是淘宝的，不过最初mysql支不住时，从时间上不可能一步到位的做成现在这样的结构。买个牛B服务器就能解决的问题，淘宝当时有钱自然是最好的选择。直到后来小型 机也撑不住，再堆钱也没用的时候，不得不再mysql化

http://www.meetqun.com/member.php?mod=register&fromuser=windshg

Java在性能方面确实不如c ,优点就是开发快，再加上硬件的快速发展，没有问题，除非超大规模的用户访问量，必须得考虑了