这是一个非常基本的问题，但我不熟悉Java设计，请原谅。 ：）
我想知道在哪些场景中我们需要将类行为与类本身分开。
例如
如果我有一个类Employee，我会在其中有一些数据 - 如名称，年龄等。此类也会有一些行为，如doWork（）等。现在在什么情况下我们可以拥有数据和内部行为一次只有class（Employee），在哪种情况下我们需要为Employee数据（EmployeeDTO）和行为（EmployeeService）提供2个不同的类
非常主观的问题，但我正在寻找一个小型应用程序设计的一些输入，我从文本文件中获取数据。我应该将数据和行为放在不同的类中还是相同的？你有理由为这个决定辩护吗？
PS：任何有关此信息的链接也非常有用：）
谢谢你
答案 0 :(得分：9)
良好的面向对象设计倡导每个班级服从Single Responsibility Principle。我不能比维基百科条目更有说服力地总结：
Martin将责任定义为改变的理由，并得出结论 一个类或模块应该只有一个，而且只有一个 更改。例如，考虑一个编译和打印的模块 报告。可以更改这样的模块有两个原因。首先， 报告的内容可以改变。其次，报告的格式可以 更改。这两件事情因不同的原因而改变;一 实质性的，一个化妆品。单一责任原则 说问题的这两个方面实际上是两个独立的 责任，因此应该在单独的班级或 模块。将两件改变的事情结合起来将是一个糟糕的设计 不同时期的不同原因。
如果你考虑一下，你可以将所有Java代码都塞进一个类文件中，但事实并非如此。为什么？因为您希望能够更改，维护，调整和测试它。这个原则说，不应该将你的代码任意划分为不同的模块，你应该采取应该通过逻辑责任分解事物的机智。这通常意味着我们知道更容易改变，维护，适应和测试的更小的模块。
我个人会建议您将代码分解为较小的离散类，并在以后将其合并，如果这被证明是不合理的 - 这对您来说很明显。将来松散耦合的代码组合起来比分解紧密耦合的代码要容易得多。
答案 1 :(得分：6)
做最简单的事情。你可以随时使你的代码更加通用化，你很可能甚至不必这样做。
每次您需要做出决定时，应用YAGNI原则。 Extreme Programming wiki也很好读。
现在把所有东西放到一个班级。当您看到您的员工变得太胖时，您可以进行一些重构 - 例如，move method到另一个班级。在像Java这样的静态类型语言中，它非常简单，因为编译器有很多帮助，IDE支持很棒。
例如，从文件读取，看起来像是一个明显的候选者，可以提取到一个单独的加载器类。另一方面，如果您有一个非常常见的格式作为输入，例如XML或JSON，您可以创建静态方法List<Employee> Employee.loadFromFile(string fileName)并在几行代码中实现读取逻辑。它现在已经足够好了：简单，简洁，工作正常。
答案 2 :(得分：2)
通过将业务逻辑保持在pojo之外，从而使其成为纯粹的传输对象，如果有一天您发现自己处于需要从Spring框架切换到EJB JavaBeans的情况，那么您将获得松散耦合的好处。
通过将数据和业务逻辑放在一起，它就成了一个域对象。在JSF2中提升的最简单的托管bean使用形式使用域模型，其中“动作”与表单数据融合在一起。
如果您选择第一个模型，您可以干净地分离设计数据对象的继承性和多态性的问题，同时如果定义的行为有意义则不会被打扰，反之亦然。
答案 3 :(得分：2)
当您想使用最轻的方式（例如通过电线连接到服务）移动数据时，您使用DTO（如首字母缩略词所示）。
答案 4 :(得分：0)
记录
它是经典的富域对象与贫血域对象。
通常，如果您有一个UI对象或一个库对象（例如类Date或类TextButton），并且可能是其他类型的对象，那么您可以将所有对象包装在一个而不是依赖在不同的类中，只有商品才能拥有同一类中的所有属性和方法。
但是，对于经典的业务对象（BO）来说是不同的。即使你想要一个丰富的域名对象，排除我此前不想提及的其他一些问题，也就是商业服务（BS）层充当了一个燃烧的饮食计划＆＃34 34;它将每个富有的BO变成了贫血的BO。
Rich BO -------＆gt; BS ----------＆gt;贫穷的BO。