OOP最佳实践：Employee.GetCars（）vs Cars.GetByEmployee（）
鉴于Company ， Employee和Car类，检索与公司或员工相关联的汽车的方法的首选做法是什么？
Employee.GetCars(params...) Company.GetCars(params...)
要么：
Cars.GetByEmployee(params...) Cars.GetByCompany(params...)
第一种方法是我一直使用的方法，对我来说似乎总是最直观的。 但在看到使用第二种方法的大型代码库之后，我必须承认它正在增长。 我真正喜欢第二种方法的两件事是：
- 它将所有与
Car相关的代码组合在一起成为一个文件，使代码更加模块化，更易于维护。 - 有一个直观的逻辑，让任何方法都将
Car的返回值（或者更像是List）分组到Car类中。
有没有最佳实践涵盖这个？
我会在实体类中使用第一种方法。 这些方法应该没有参数，因为它们只返回所有关联。 涉及一些简单业务逻辑的第二种方法应该放在帮助程序类中，或者如果你有一个，可以放在CarDAO中。
我认为没有一个解决方案。 这取决于你如何争论。 如果由汽车负责人知道他们是谁，我会使用第二种方法。 但如果员工有责任知道他拥有哪辆车，那么我会采用第一种方法。
但是我个人更喜欢第一种方法，因为它似乎更容易实现。
员工有一辆汽车（或者一些汽车，因此）每个员工都自然知道他使用了哪些汽车。 但汽车是否知道或关心谁“拥有”它？ 我会说不。 它可能知道谁在驾驶它，但这是一个不同的问题。
要么汽车确实知道哪个员工拥有它（哪个感觉不对，这是一个奇怪的关系），要么它必须搜索所有有需要的人找到自己，这更糟糕（不合逻辑，狗慢，一切都松散耦合）。
这两种方法对我来说都有点不对劲。 为什么Employee类应该知道Car类？ 为什么汽车课应该了解员工？ 这两个类都不需要另一个来运行，因此不需要耦合它们。 我会在某个地方存储一个字典，将员工映射到一组汽车，另一个将公司映射到一系列汽车。
没有最好的办法。 这取决于您的应用程序需要做什么。 使用相同数据的两个应用程序可以具有完全不同的对象模型，具体取决于它们的用例。
通过Demeter逻辑处理法运行此问题。 非常有帮助，对！ 呵呵
问题以一种始终在Employee和Car类之间进行耦合的方式呈现。 如果您可以将car.GetByEmployee(...)更改为car.GetByDriversLicenseNumber(...) （或类似的东西），那么您将解耦这两个类。
最好的方法是减少耦合到的对象的数量。 所以，这一切都取决于链中的下一级对象如何成为Car。
我不认为对这个问题有一个正确的答案，这一切都是关于当前的情况。
都不是。
有一个名为ICarOwner的接口，由Employee and Company （或它们的派生）实现，然后创建CarOwnership类，其属性为Car （类型为Car或ICar ）和Owner （类型为ICarOwner ）。
当您需要查找汽车所有权时，您无需关心所有者是员工还是公司。 你只需要做CarOwnerships.GetByOwner(ICarOwner) 。
我希望这有帮助。
这完全取决于关系。 一个员工可以拥有一辆车吗？ （1：N）永远不要从N侧引用1侧，这就是我老师所说的。 其他事情也一样。 如果您的比例为1：1，则可以同时执行这两项操作。 Employee.getCar和Car.getOwner 😉