刚开始学习 Java 的时候, 由于没有项目经验, 对项目中是如何运用面向对象的理论, 雾里看花。
当时老师的结论: 虽然 Java 语言是对面向对象理论的实现, 实际项目编码的过程中并没有用到 面向对象 的理论;
当时没办法理解, 这个问题一直萦绕在脑中, 挥之不去。
今天复习基础笔记时, 对此有一些新的想法。
首先, 面向对象理论中的对象组成:
对象中包含:
(1)数据(属性);
(2)职责(行为);
然后, 查看 Java String 的源码, 的确是严格实现 面向对象的理论的:
将字符串的 “属性” 和 “方法” 都放置于 String 类中, 所有方法都围绕其属性进行实现和展开;
然而, 实际开发过程中, 与 Java 的实现是不一样的:
(1) 实体类单独拿出来, 进行维护;
(2) 实体类对应的业务逻辑, 单独拿到 service 中进行实现, 而不是放在 entity 实体类中进行。
与 Java 源码中的实现方式好像不一样, 是不是就没有按照 “面向对象” 的理论实现?
此时此刻, 我的理解: 运用了。
实际编码中, 只不过将 数据 和 行为 分开进行维护, 而不是放在一个类中。
数据和行为之间的联系, 通过 类名 进行关联。 User类 ---> UserService;
此关联需要人为的判断。
如此架构也有现实的需要:
(1) 一个类的属性和行为可能会非常多且复杂;
比如: 一辆车的相关属性, 多达上百个, 业务实现方法更是繁多, 而且随着项目的扩展, 只可能会越来越多。
如果将 属性 和 行为 放置在一个类中, 会非常臃肿, 难以维护, 结构也不清晰。
将数据和行为 拆开就没有这种问题了;
(2) 不是所有的行为, 都是只属于某一个对象的, 它可能关乎到多个对象, 比如:
司机 和 车辆 之间有关联关系:
那么, “根据车辆查询司机信息” 和 “根据司机查询车辆信息” 这两个方法, 应该如何严格的归于哪一个类呢?
而 Java 源码, 它是基础架构, 不会涉及太多的 属性(数据), 更多的是行为, 将二者放在一个类中是更好的选择;
总结:
实际编码的架构中, 我们也运用了 面向对象 的理论, 只不过根据实际情况进行了更合理的调整,并没有违反其定义。