Java 项目开发中是否真的运用了面向对象理论？

刚开始学习 Java 的时候， 由于没有项目经验， 对项目中是如何运用面向对象的理论， 雾里看花。

当时老师的结论： 虽然 Java 语言是对面向对象理论的实现， 实际项目编码的过程中并没有用到 面向对象 的理论；

当时没办法理解， 这个问题一直萦绕在脑中， 挥之不去。

 

今天复习基础笔记时， 对此有一些新的想法。

 

首先， 面向对象理论中的对象组成：

对象中包含：

（1）数据（属性）；

（2）职责（行为）；

 

然后， 查看 Java String 的源码， 的确是严格实现 面向对象的理论的：

将字符串的 “属性” 和 “方法” 都放置于 String 类中， 所有方法都围绕其属性进行实现和展开；

 

然而， 实际开发过程中， 与 Java 的实现是不一样的：

（1） 实体类单独拿出来， 进行维护；

（2） 实体类对应的业务逻辑， 单独拿到 service 中进行实现， 而不是放在 entity 实体类中进行。

与 Java 源码中的实现方式好像不一样， 是不是就没有按照 “面向对象” 的理论实现？

此时此刻， 我的理解： 运用了。

 

实际编码中， 只不过将 数据 和 行为 分开进行维护， 而不是放在一个类中。

数据和行为之间的联系， 通过 类名 进行关联。 User类 ---> UserService;

此关联需要人为的判断。

 

如此架构也有现实的需要：

（1） 一个类的属性和行为可能会非常多且复杂；

   比如： 一辆车的相关属性， 多达上百个， 业务实现方法更是繁多， 而且随着项目的扩展， 只可能会越来越多。

   如果将 属性 和 行为 放置在一个类中， 会非常臃肿， 难以维护， 结构也不清晰。

   将数据和行为 拆开就没有这种问题了；

（2） 不是所有的行为， 都是只属于某一个对象的， 它可能关乎到多个对象， 比如：

   司机 和 车辆 之间有关联关系：

   那么， “根据车辆查询司机信息” 和 “根据司机查询车辆信息” 这两个方法， 应该如何严格的归于哪一个类呢？

 

而 Java 源码， 它是基础架构， 不会涉及太多的 属性（数据）， 更多的是行为， 将二者放在一个类中是更好的选择；

 

总结：

实际编码的架构中， 我们也运用了 面向对象 的理论， 只不过根据实际情况进行了更合理的调整，并没有违反其定义。