娃娃和假人

我已经写了很多关于为什么我不考虑JavaBeans真实对象的文章。 例如，我认为我们在这里和这里都同意，模型对象仅仅是语法糖，我们可能根本不使用它们，它们是无用的抽象，不提供任何功能。

不过，让我们再尝试一次，这次是通过一些隐喻和一些想象力。 是的，我相信，要成为优秀的OOP程序员，我们需要想象力和可视化对象如何协同工作的能力，这要比UML图表多一点。

汤姆和杰瑞（Tom＆Jerry）–威廉·汉娜（William Hanna）和约瑟夫·巴贝拉（Joseph Barbera）设计的杰瑞设计

我们可以看看模型对象，另一种方式是：他们要么娃娃 （ User ， Student ， Partner等）或设计草图 （ Car ， Phone ， Book等）。 问题是，我们如何与他们合作，他们如何帮助我们解决任何问题？ 答案很简单：我们不能对他们采取任何措施，他们除了提供一定的可读性外没有任何其他帮助！ 他们只是坐在那里，等待一些辅助方法或WhateverService类对它们执行操作，我们的工作是设计该方法和该服务以及希望能够对它们进行处理的过程代码。 我们是致力于容纳模型的人。

但是为什么他们不能为我们工作？ 为什么我们不能设计他们，使他们移动 ，从而不必满足他们的负担中解放出来我们不得不为他们写那些手续？ 秉持这种思维方式，我们不会四处寻找解决500 LoC方法的方法，也不会试图弄清楚如何测试该Service类。 相反，我们的工作将更像是一名工程师：我们将不得不设计，实现，测试和修复对象，而不是过程，而不是意大利面条代码。

我是这样看的：软件开发人员和工程师要承担相同的任务，他们每个人都必须制造一辆Car 。 工程师将构建真正的Car ，该Car将实际移动，加速等。另一方面，软件开发人员将仅查看需求，构建Car模型，然后继续围绕该模型构建各种工具，应该使它移动并提高速度……我个人想象一个房间，里面装满了无生命模型的横梁和细绳。 同样，可能会有一个操纵杆必须由某人操作才能使“汽车”完成某事–所有这些梁，弦和操纵杆都是应用程序代码中的辅助方法和服务类。

这种比较听起来很疯狂，但这就是事实：主流的OOP只是为人们提供了必要的工具，可在数据上加上标签，同时让他们保持程序化的思维方式。 相反，真实的面向对象是思维方式的完全转换：您从体力劳动者的职位转到工程师的职位，后者的职位是实际解决问题的对象，使事情自动化。

那么我们如何才能开始编写这样的代码呢？ 好吧，第一步是要了解任何适当的对象都必须具有接口。 我也写过关于此的文章，但让我重申一些原因：

• 该接口是什么对象，可以做。 如果没有接口，那么就没有规则，没有身份，没有能力，它只是一堆程序；
• 通过一个接口，我们可以装饰对象。
• 我们可以有多种实现。 不难发现，我们不应该费力地（即拥有一些程序）将X转换为Y，而是应该基于X添加新的Y实现；
• 我们可以模拟一个接口，或者使用Fake实现。 等等

此外，我们应该比其他事情更多地考虑行为 。 如果我们有一个Student并且给他们一个分数，那么该分数应该在任何需要的地方立即可见。 我们应该能够相信该对象将按预期完成其工作，而无需设计一个我们将要修改的木偶，然后传递给每个人查看并执行其工作：

//This is it, grade is given and it already made its effect everywhere
  this.student.grade(10);

  //as opposed to this:
  this.student.setGrade(10);
  this.service.updateRegistry(student);

这是一个复杂的过程，不幸的是，仅仅因为那里的所有框架都基于“模型”的概念，以这种方式（当然不是很大）完全实现应用程序并不容易。 我们可能必须重新实现所有内容。 但是，我相信，如果我们至少以面向对象的方式实现应用程序的核心，并且仅让边界成为过程，那仍然是一个很大的进步。

翻译自: https://www.javacodegeeks.com/2018/04/dolls-and-maquettes.html