面向对象的荒诞之处

首先,面向对象不仅仅只是个mode
然后,一个对象30个属性,是否考虑对象的粒度问题,是否是粒度太粗了.是否应该考虑细粒度建模
其次,面向对象是一种思想,面向接口,面向组件,仔细看他们的设计,仔细看他们的实践,多态,封装,继承.面向xx的什么的都是一个名字而已.其设计本质还是那几个原则

楼主说的一个对象30个属性，却大部分不是经常用的说法 ~

是有一定道理的，而且现在也有更好的解决办法 ：P

答案只有一个：列存储Nosql：比如hbase比如cassandra

这个现象的本质就是关系型数据库固定的表结构限死了，其实一个表30个字段，大多都空着，也不是一件好事。。。

楼主讲的意思大家都懂,产生的性能浪费也很容易理解,但是专注于这些问题,往往到最后得不偿失.
面相对象也不仅仅像你说的那样,概念有点套大了.

OO是可选的，你可以不用OO，直接用过程的方式！

单说：属性超过30个的M是如何产生的。
通常大部分应用的M都是设计成“平面”的（即一层），即：假就设计 30个属性。如表有30个字段，对应的M
当M的复用系数较低的时候，这样不会有太大问题。
复用系数高了之后，就会出现冗余代码，如：Lz所说的“只用其中几个属性”。

原因前面有网友说了：M的划分粒度太粗。
实际上现实世界的M是多层的，如：常见的User表。
可以划分为：
account : 账户，保存登陆用户名，密码，密保问题，等和登陆相关的属性。
permission ：权限，保存用户的读，写，查等权限。
figure  ：画像，标签，保存用户的偏好标签，如兴趣，常去的模块。
等等等等。
这样能解决“一次只用几个属性”的问题，但却引入大量实体，增加了开发工作量。
总之：需要在开发成本和扩展性上做平衡。

大家积极热情的解答让我受益匪浅，在此一并感谢！

表示认同

居然那么多人说30个成员的model不正常。。。
还那么多人认同。。。

其实面向对象的设计里哪有数量限制，这根本不是作为一个考量的因素。

事实是这个实体就有那么多属性，那么这个class当然就有这么多的成员变量。 难道强行拆分掉才算好的面向对象设计？

数量的多与少根本就不是一个考量合理不合理的因素。 也不是一个可以用来评论面向对象这个设计本身优劣的依据。

结论是个伪命题，结论本身是正确的，但没考虑一个度。我要是原文换成100个属性，你还会这么说么。

至于30个多还是不多，的确不能盲目下定论，但我还是倾向于嫌多。如果有实际案例可以参考，我想还是有办法拆分成不同的部分，通过组合的形式构成一个完整的业务对象。

当然硬要搞30个，那也没办法，我们系统中我还见过前人写的50个哩~

30个还是100个都没关系。 还是那句话，不拿个数说事。

面向对象就是个权衡，得到的是代码可复用，易用维护，降低复杂度，易于编写出健壮的代码。易于扩展等等这些方面。
在性能方面本来就要失去一些。

权衡得失，觉得性能损失可以接受，那就用面向对象。不可接受就不要用。 这也是为什么很多地方必须要用C些面向过程的实现。

30和100有什么区别，不过是常见不常见而已。  8个属性的实体属性很常见吧？ 也经常见到这样的场景吧： 用OO的方法获得一个对象，它有8个属性，但我们这次得到了这个对象，仅仅为了使用其中的一个 xxxId字段。 这个效率有多个？别说其他属性是字符串等。 就算都是int型。  8个属性中也只不过用1个。  内存，cpu等的利用率也超不过 1/8。 看起来这足够浪费了吧。 

任何一个面向对象的著作中都没说过类的属性不能超过N个，这个N是几。  讨论一个方法论的时候，不可能假设所有的情况。 谁也不知道会不会某一个场景下，一个实体的属性就有那么多。

你说也许可以拆分，我是对的。 你指出他哪些地方不符合OO的原则， 哪些属性应该拆分不属于这个实体，他给混到一起了。 这些说出来，很有说服力。