OOP 最佳实践：Employee.GetCars() 与 Cars.GetByEmployee()答案

【问题标题】：OOP best practice: Employee.GetCars() vs Cars.GetByEmployee()OOP 最佳实践：Employee.GetCars() 与 Cars.GetByEmployee()
【发布时间】：2011-03-29 02:00:39
【问题描述】：

鉴于 Company、Employee 和 Car 类，检索与 Company 或 Employee 关联的 Cars 的方法的首选做法是什么？

Employee.GetCars(params...)
Company.GetCars(params...)

或者：

Cars.GetByEmployee(params...)
Cars.GetByCompany(params...)

第一种方法是我常用的方法，对我来说似乎总是最直观的。但是在看到使用第二种方法的大型代码库之后，我不得不承认它在我身上不断增长。我真正喜欢第二种方法的两点是：

它将所有Car相关的代码组合到一个文件中，使代码更加模块化，更易于维护。
将返回值为Car（在本例中更像List<Car>）的任何方法归入Car 类有一个直观的逻辑。

是否有涵盖此内容的最佳实践？

【问题讨论】：

选择一组关于这些事情的约定和规则，并使它们在呈现相同决定的每个类似场景中保持一致。决定的结果相对不重要。
另外，取决于您要跟踪的内容，如果员工经常有 4 辆车，我会使用 Employee.GetCars() 因为它从一开始就缩小了范围，但是如果您有数百万员工和很少的汽车，我会做 Cars.GetByEmployee 因为汽车将是较小的集合。我想我是说我更喜欢： Subset.GetSuperset() 所以更窄的选择是类。
@Jimmy：除非您喜欢雇用有感知的车辆，否则我不一定将 Cars 称为员工的子集，但我同意您提出的一般观点。

标签： c# design-patterns oop

【解决方案1】：

都没有。

有一个名为ICarOwner 的接口由Employee 和Company（或其派生类）实现，然后创建具有Car 属性的类CarOwnership（类型为Car 或ICar）和Owner（ICarOwner 类型）。

当您需要查找汽车所有权时，您无需关心车主是员工还是公司。你只需要CarOwnerships.GetByOwner(ICarOwner)。

我希望这会有所帮助。

【讨论】：

【解决方案2】：

通过德米特法则逻辑处理来运行这个问题。很有帮助，对！呵呵

问题的呈现方式总是在 Employee 和 Car 类之间存在耦合。如果您可以将car.GetByEmployee(...) 更改为car.GetByDriversLicenseNumber(...)（或类似的东西），那么您将解耦这两个类。

最好的方法是减少耦合在一起的对象的数量。所以，这一切都取决于链中的下一级对象将如何使用 Car。

我认为这个问题没有一个正确的答案，都是关于当前的情况。

【讨论】：

仅供参考：我知道你没有违反得墨忒耳法则。我建议我们程序员应该在违规发生之前考虑一下。

【解决方案3】：

没有最好的方法。这取决于您的应用程序需要做什么。使用相同数据的两个应用程序可以具有完全不同的对象模型，具体取决于它们的用例。

【讨论】：

【解决方案4】：

这两种方法对我来说似乎都有些不对劲。为什么 Employee 类应该知道 Car 类？为什么 Car 类应该知道 Employee？两个类都不需要另一个类来运行，因此没有必要耦合它们。我会在某个地方存储一个字典，将员工映射到汽车集合，另一个将公司映射到汽车集合。

【讨论】：

为什么 Employee 类应该知道 Employee 的年龄或薪水？只需制作一张地图（每个属性一张）！一段时间后，有人决定将与Employee类相关的所有地图收集到一个类中......
这里的问题是耦合。一般来说，您应该尽可能避免将一个类耦合到另一个类。
我什至没有想到这一点，很好，也许该方法属于 dal 类，而不是返回具有汽车列表的员工，而是返回一个维度类 EmployeeByCar，其行为类似于Tuple 或 Tuple 之类的性质

【解决方案5】：

一个员工有一辆汽车（或一些汽车，就此而言），所以每个员工自然都知道他使用哪些汽车。但汽车知道或关心谁“拥有”它吗？我会说不。它可能知道是谁在驾驶它，但这是一个不同的问题。

要么汽车确实知道是哪个员工拥有它（这感觉不对，这是一种奇怪的有关系），要么它必须搜索所有员工才能找到自己，这更糟（不合逻辑，狗慢，除了松散之外的一切耦合）。

【讨论】：

【解决方案6】：

我认为没有单一的解决方案。这取决于你如何争论。如果汽车有责任知道它们归谁所有，我会使用第二种方法。但如果员工有责任知道他有哪些汽车，那么我会使用第一种方法。

但我个人更喜欢第一种方法，因为它似乎更容易实现。

【讨论】：

【解决方案7】：

这都是关于关系的。一名员工可以拥有多于一辆车吗？ (1:N) 永远不要从 N 面引用 1 面，这是我老师说的。其他事情也一样。如果你有一个 1:1，你可以同时做。 Employee.getCar 和 Car.getOwner ;-)

【讨论】：

想要使用 Employee.getCars() 和 Car.getDrivers() 并没有错。而且你没有回答关于 Car.getCarsByOwner() 的问题。

【解决方案8】：

我会在实体类中使用第一种方法。这些方法不应该有参数，因为它们只返回所有关联。第二种涉及一些简单业务逻辑的方法应该放在一个帮助类或 CarDAO 中，如果你有的话。

【讨论】：

很棒的建议！我真的很喜欢这种方法，因为它提供了两全其美。