这是一个非常基本的问题，但我是 Java 设计的新手，请原谅。 :)
我想知道在哪些场景中我们需要将类行为与类本身分开。
例如
如果我有一个 Employee 类，我将在其中包含一些数据，例如姓名、年龄等。此外，该类将具有一些行为，例如 doWork() 等。现在在什么情况下，我们可以拥有数据和里面的行为一次仅类 (Employee)，在这种情况下，我们需要为员工数据 (EmployeeDTO) 和行为 (EmployeeService) 提供 2 个不同的类
非常主观的问题，但我正在寻找一些关于我从文本文件中获取数据的小型应用程序设计的输入。我应该将数据和行为放在不同的类中还是相同的类中？你有什么理由来证明这个决定是正确的？
PS：任何有关此信息的链接也将非常有用:)
谢谢你
【问题讨论】：
记录在案
它是经典的富域对象 vs 贫乏域对象。
一般来说，如果您有一个 UI 对象或库对象（例如类 Date 或类 TextButton），并且可能是其他类型的对象，那么您可以将所有对象包装在一个类中而不是依赖项中在不同的类中只是为了商品具有同一类中的所有属性和方法。
但是，对于经典的业务对象 (BO)，情况就不同了。即使你想要一个丰富的领域对象，排除一些我现在不想提及的其他问题，事实上，业务服务 (BS) 层充当“燃烧脂肪的饮食计划”，它让每个人都变得富有BO变成贫血的BO。
Rich BO -------> BS ----------> 贫血 BO。
【讨论】：
尽可能做最简单的事情。以后您总是可以使您的代码更加通用，而且很有可能您甚至不必这样做。
每次需要做出决定时都应用YAGNI原则。 Extreme Programming wiki 也是不错的读物。
现在把所有东西都放在一个类中。当你看到你的 Employee 变得太胖时，你可以做一些重构——例如，move method 到另一个类。在像 Java 这样的静态类型语言中，这非常容易，因为编译器有很大帮助，而且 IDE 支持也很棒。
例如，从文件中读取看起来像是提取到单独的加载器类的明显候选者。另一方面，如果您有一个非常常见的格式作为输入，例如 XML 或 JSON，您可以创建静态方法 List<Employee> Employee.loadFromFile(string fileName) 并在几行代码中实现读取逻辑。现在已经足够好了：简单、简短且工作正常。
【讨论】：
当您想使用尽可能轻量级的方式移动数据时，您可以使用DTO（如首字母缩写词所示），例如通过网络传输到服务。
【讨论】：
良好的面向对象设计主张每个类都遵守Single Responsibility Principle。我无法比维基百科条目更雄辩地总结：
Martin 将责任定义为改变的理由，并得出结论 一个类或模块应该有一个，而且只有一个，理由 改变。例如，考虑一个编译并打印 报告。可以出于两个原因更改这样的模块。首先， 报告的内容可以改变。二、报告的格式可以 改变。这两件事因非常不同的原因而改变；一 实质性的，一种化妆品。单一责任原则 说这两个方面的问题真的是两个分开的 职责，因此应该在单独的类中或 模块。将两个变化的东西结合起来是一个糟糕的设计 不同的时间有不同的原因。
如果您考虑一下，您可以将所有 Java 代码压缩到一个类文件中，但事实并非如此。为什么？因为您希望能够更改、维护、调整和测试它。这个原则说，不要将你的代码任意划分为不同的模块，你应该采取一种策略，即事物应该按照它们的逻辑职责来分解。这通常意味着更多的小模块，我们知道这些模块更容易更改、维护、调整和测试。
我个人建议您将代码分解为较小的离散类，如果这被证明是不合理的，稍后再将它们组合起来——这对您来说很明显。将来组合松散耦合的代码比分解紧耦合的代码要容易得多。
【讨论】：
通过将业务逻辑排除在 pojo 之外，从而使其成为纯粹的传输对象，如果有一天您发现自己需要从 Spring 框架切换到 EJB JavaBeans，那么您将受益于松散耦合。
通过将数据和业务逻辑放在一起，它就成为了一个领域对象。 JSF2 中最简单的托管 bean 使用形式使用域模型，其中“动作”与表单数据融合在一起。
如果您选择第一个模型，您可以清楚地分离为数据对象设计继承和多态性的关注点，而不必担心定义的行为是否有意义，反之亦然。
【讨论】：