有一种观点认为，类应该是“数据结构”（即，专注于存储数据而没有功能）或“功能导向”（即，专注于执行某些操作同时存储最少状态）。如果您遵循这个观点（这很有道理，但不总是容易做到），那么这没有什么必然的问题。

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

我见过某些来源（例如《清晰代码》一书）论述说应该避免使用具有多个参数的方法，而应该传递一个具有getter和setter的单个对象。这也更接近于命名参数的“smalltalk模型”，其中顺序并不重要。

因此，我认为当合理使用时，您的设计是有意义的。

请注意这里有两个分开的问题。

1. 一个“类似于结构体”的类是否有意义？

2. 从一个方法返回多个值创建一个类是明智的吗？

结构体类

一个对象类应该 -- 大部分情况下 -- 代表一个真实世界的对象类。一个被动的、类似于结构的 java bean（只有 getter 和 setter）可能代表一个真实世界的东西。

然而，大多数现实世界的事物都有规则，限制，行为和基本动词参与。 类似结构的类很少与现实世界的事物相匹配，通常是某些技术性事物。 这使其不是理想的面向对象设计。

一个方法的多重返回

虽然Python具有此功能，但Java没有。多个返回值并不是一个面向对象的问题，就本身而言。这是一个需要通过解决语言限制来解决的问题。

多个返回值可能意味着对象的状态已经改变。也许一个方法改变了状态，并且一些组的getters返回了从这个状态变化中产生的值。

老实说，这在我听来还不错。评论员提出了什么替代方案？

遵循面向对象编程的“最佳实践”并没有问题，但你必须务实并实际完成工作。

使用像这样的值对象（OO中结构体的说法）在某些情况下是完全合法的方法。

通常情况下，您希望将操作类所需的知识隔离到类本身中。如果您有这样的一个类，它要么在多个地方使用，因此可以在这些地方中的其中一个中获得一些功能，要么在一个地方使用，应该是一个内部类。如果它被以完全不同的方式多种方式使用，使得没有共享功能，那么将其作为一个单一的类是误导的，表明存在共享功能，而实际上不存在。

然而，这些通用规则是否适用通常有具体的原因，所以这取决于你的课程应该代表什么。

我认为他可能将“不太OOP”混淆为不良实践。我认为他期望您提供几种方法，每种方法都返回所需的1个值（因为您将不得不在新类中使用它们，所以并不太糟糕）。

请注意，在这种情况下，您可能不应使用getter / setter，而是将数据公开。不，这不是“非常面向对象”的，但这是正确的方法。

也许Josh Bloch在这里提供了一些见解：这里。