面向对象的荒诞之处

在常见的Java Web中，一般会有Modal, Controller, View, DAO, Service几个分层，而Modal在其中发挥怎样的贡献呢？莫非两点：1.对对象属性进行增、删、改时，作为新属性的包装，进行整体传递；2.对对象属性进行查询时对查出的数据进行包装以进行传递。
然而实践中，我们在删、改、查时，通常只会涉及部分属性，并不经常动用全部属性。那么再用Modal来包装有什么意义呢？如果一个Modal有30个属性，而我通常操作只会涉及一两个字段，那么当我new一个对象时，内存中会分配所有字段的空间，而我只会使用其中一两个，在资源和效率上都产生极大浪费。那么这样面向对象又有什么意义呢？
各位看官以为如何？

其实还可以细分，如果是用来做ORM MAPPING的，就要放所有属性，如果只需要部份属性的，可以整个DTO，里面就只加所需的属性。

“好用”和“便宜”本来就不能兼顾，如果你的系统注重效率，那就别用model咯，但你不能说这东西没意义，如果有个model有30个成员，那可能这个model本身设计就没有很好的面向对象

不好意思口误了，我是指“一个Modal有30个属性”，不是对象。

理解您的意思了，我觉得反而DTO应用会非常广泛，Modal则只会偶尔用到，是这样不？

和ORM MAPPING打交道，就必须要用MODEL了，其他场景可以考虑DTO。

如果所有的实例属性都是延迟(lazy alloc)分配内存，那就既有了Modal封装的好处，也避免了内存资源的浪费。

那一开始在设计些什么东西，30个字段经常只操作一两个，你们的架构师可以拉出去枪毙了。

这有什么不可理解的？比如一个User会有非常多属性，但常用的可能只有name,email,password。你是不是要说可以把其它属性拆分成别的类啊？问题是，我抽象类是针对现实中的实体来抽象，还是要面向业务需要来抽象？

那按照你的意思，现实中没的实体你怎么办？根本就没有一定要怎样设计的说法。领域模型的设计思路因人而异或者业务不同而不同，有人愿意大而全的领域模型，有人愿意多而精巧的领域模型。

现在的领域设计都被一些莫名其妙的思路搞的乱七八糟，上来就是一个实体对应一张表。

面向对象不是实体怎么设计，不是实体的属性应该怎么划分，不是去研究究竟是is-a还是has-a。

面向对象的核心是屏蔽，是隐藏实现。所以才有封装，继承，多态这些特性的出现。

但是再怎么设计业不应该一个实体大部分操作只操作一两个字段，你就好比你这个User对象大部分操作只要看name,email,password？

ok，那你所有有关人员的信息的人事报表看来是没了，人员的履历信息应该也没做了，根据人员生日，性别，注册日期等等的事务提醒看来也是没做了，人员入职离职等状态是基本不用的。

所以，基本不可能出现30个字段经常只操作一两个的实体，如果出现，那架构师就应该拉出去枪毙。