Vis*_*hal 9 java oop class dto
这是一个非常基本的问题,但我不熟悉Java设计,请原谅.:)
我想知道在哪些场景中我们需要将类行为与类本身分开.
例如
如果我有一个类Employee,我会在其中有一些数据 - 如名称,年龄等.此类也会有一些行为,如doWork()等.现在在什么情况下我们可以拥有数据和内部行为一次类(Employee) )仅在这种情况下我们需要为Employee数据(EmployeeDTO)和行为(EmployeeService)提供2个不同的类
非常主观的问题,但我正在寻找一个小型应用程序设计的一些输入,我从文本文件中获取数据.我应该将数据和行为放在不同的类中还是相同的？你有理由为这个决定辩护吗？
PS:任何有关此信息的链接也将非常有用:)
谢谢
良好的面向对象设计倡导每个班级遵守单一责任原则.我不能比维基百科条目更有说服力地总结:
马丁将责任定义为改变的理由,并得出结论认为一个阶级或模块应该只有一个改变的理由.例如,考虑一个编译和打印报告的模块.可以更改这样的模块有两个原因.首先,报告的内容可以改变.其次,报告的格式可以改变.这两件事情因不同的原因而改变; 一个实质性的,一个化妆品.单一责任原则说,问题的这两个方面实际上是两个不同的职责,因此应该在单独的类或模块中.在不同的时间将两个因不同原因而变化的事物结合起来是一个糟糕的设计.
如果你考虑一下,你可以将所有Java代码都塞进一个类文件中,但事实并非如此.为什么？因为您希望能够更改,维护,调整和测试它.这个原则说,不应该将你的代码任意划分为不同的模块,你应该采取应该通过逻辑责任分解事物的机智.这通常意味着更多的小型模块,我们知道这些模块更易于更改,维护,调整和测试.
我个人会建议您将代码分解为较小的离散类,如果这被证明是不合理的,则将它们组合起来 - 这对您来说很明显.将来松散耦合的代码组合起来比分解紧密耦合的代码要容易得多.
做最简单的事情吧.你总是可以在以后使你的代码更加通用,你很可能甚至不必这样做.
每次需要做出决定时都应用YAGNI原则.极限编程维基也是一个很好的阅读.
现在把所有东西都放在一个班级里.当您看到您的员工变得太胖时,您可以进行一些重构 - 例如,将方法移动到另一个类.在像Java这样的静态类型语言中,它非常容易,因为编译器有很多帮助,IDE支持很棒.
例如,从文件读取看起来像是一个明显的候选者,可以提取到一个单独的加载器类.另一方面,如果您有一个非常常见的格式作为输入,例如XML或JSON,您可以创建静态方法List<Employee> Employee.loadFromFile(string fileName)并在几行代码中实现读取逻辑.它现在已经足够好了:简单,简洁,工作正常.
愿真正的终极编程能力与你同在!