为什么在Java中使用类作为结构是一种糟糕的做法？

我们最近进行了一次代码审查。使用了我的一个类，因此我可以从方法返回/向方法传递多种类型的数据。该类仅有的方法是getter/setter。团队的一名成员（我尊重他的意见）说，开这样的课是不好的做法（而且不是很糟糕）。为什么会这样？

通常，您需要将操作类所需的知识隔离到类本身中。如果您有一个这样的类，它可以在多个地方使用，因此可以在这两个地方都具有一些功能，或者它在一个地方，应该是一个内部类。如果它以多种方式使用，但使用方式完全不同，以至于没有共享功能，那么将其作为一个类是有误导性的，这表明没有共享功能的共享功能

---

然而，这些一般规则可能适用，也可能不适用，通常有特定的原因，因此这取决于您的类应该表示什么。

有一种观点认为类应该是“数据结构”（即，侧重于存储没有功能的数据）或“面向功能的”（即，在存储最小状态的同时专注于执行某些操作）。如果您遵循该论点（这很有意义，但并不总是容易做到），那么这并不一定是错误的

事实上，有人会认为bean和实体bean本质上是具有getter和setter的数据容器

我见过一些资料来源（例如《干净的代码》一书）认为应该避免使用多个参数的方法，而是将它们作为一个带有getter和setter的对象传递。这也更接近于命名参数的“smalltalk模型”，其中顺序并不重要

---

因此，我认为如果使用得当，您的设计是有意义的。

我认为他可能会将“不太OOP”混淆为不好的做法。我认为他希望您提供几个方法，每个方法都返回所需的1个值（因为您必须在新类中使用它们，这也不算太糟糕）

---

请注意，在这种情况下，您可能不应该使用getter/setter，只需公开数据即可。不，这是“不太面向对象”的做法，但却是正确的做法。

也许Josh Bloch对此提供了一些见解。

请注意，这里有两个不同的问题

“类似结构”的类是否合理

创建从方法返回多个值的类是否合理

类似结构的类

一个对象类在很大程度上应该代表一个真实世界的对象类。一个被动的、类似结构的JavaBean（所有getter和setter）可能代表一个真实世界的东西

然而，大多数现实世界中的事物都有规则、约束、行为和基本动词。类似结构的类很少能很好地匹配现实世界中的事物，它通常是一些技术性的东西。这使得它不如理想的OO设计

方法的多次返回

虽然Python有这一点，但Java没有。多个返回值本身不是一个OO问题。这是一个克服语言限制的问题

---

多个返回值可能意味着一个对象已更改状态。可能有一个方法更改了状态，一些getter组会返回此状态更改产生的值。

老实说，我觉得这很好。审阅者建议了什么替代方案

遵循面向对象的“最佳实践”，一切都很好，但你必须务实，切实完成工作

---

在某些情况下，使用像这样的值对象（OO代表“struct”）是一种完全合法的方法。

虽然我不一定不同意“状态”与“功能”的区别类划分，我确实觉得有必要指出，这是将OO从OO中剥离出来。我认为这种划分背后的总体思想是避免使用非核心功能重载对象，而是考虑那些“函子”我只会在字段/属性不是引用类型时使用结构。通过这种方式将数据作为参数传递，被调用的方法将获得数据的副本而不是引用（如传递类的实例）并且无法更改原始数据。因此，在多个调用中重用同一个结构实例不会相互影响。结构的好例子可能是：Vector（表示向量的一组浮点）Python实际上不允许多个返回值，它将返回值封装为一个类型，即tuple，并允许在一个语句中将tuple/list分配给多个变量。@he_the_great:虽然是真的，但这是一个微妙的区别，在这种情况下几乎没有任何价值。这里的问题是将OO设计和Java限制混为一谈。Python是OO，但在某些方面采用了不同的方法。