java - 在非常耦合的业务逻辑中解耦 Java 中的类

Question

我正在编写一个模拟器，作为开始学习 Java 和面向对象分析与设计 (OOA&D) 的第一个雄心勃勃的项目。模拟器将比较不同的方法来管理供应链中的库存(如果业务部分需要更多详细信息，请告诉我)。

我很难为我的类(class)进行解耦设计。虽然完整版模拟器有更多类，但我遇到问题的类是:

• ProductData:这基本上是一个类，旨在保存产品的所有可用历史信息。每个产品都有一组标准属性，每个属性在产品(记录的)历史记录中的每个日期都有不同的值。根据 Head First OOA&D 第 448 页所示的设计决策，我决定使用一个 Map 来存储每个日期的产品的每个相关属性，然后使用另一个集合来存储每个 Map 和这些属性有效的日期(以便我可以按日期轻松访问每个属性)。如果以后的新算法需要跟踪新的属性，我可以将它添加到属性 Map 中，然后在新的算法中使用它。
• RawResults:这个类是另一组属性，比ProductData更广泛，因为除了基本的产品数据外，它还需要存储每个模拟日期的模拟的所有计算值。由于每个算法可能需要特定“结果”属性的不同子集，除了所有算法共享的“基本”属性子集之外，每次我们向 ProductData 添加新属性时，相同的“基本”属性需要添加到 Rawresults。由于向 ProductData 添加新属性几乎总是作为向模拟器添加新算法的结果，因此我可能需要向此类添加更多“结果”属性。
• 算法:这个类是模拟器的“大脑”。它采用 ProductData 对象并读取算法的相关属性，为每个模拟日期处理它们，然后将结果存储在(最初)空白的 RawResults 对象中。在模拟结束时，我得到一个 RawResults 对象，其中包含特定模拟的所有结果，然后我可以处理它以与其他模拟进行比较并得出结论。这将是一个抽象类，每个特定的算法都是算法的一个子类，每个算法都以非常具体的方式实现所有必需的操作。我认为在这方面设计要好一些(我希望)，因为向 ProductData 和 RawResults 添加新属性不应该意味着需要更改我现有的 Algorithm 子类，因为它们可能不需要使用那些新的无论如何属性。

所以我的问题是:考虑到我面临的业务逻辑耦合，这真的是一种很好的解耦吗？我可以应用任何其他策略(哪些？)来帮助我设计一个更健壮和灵活的模拟器吗？

Answer 1

ProductData 映射中的每个条目都应该是 ProductDataEntry 类的成员(除非它们包含的数据差异很大)。

听起来 RawResults 可能会扩展 ProductDataEntry，因为它将具有相同的字段。

总体而言，您的设计听起来还不错 - 但是，如果不查看实际对象和整体架构，就无法多说，这里不适合(而且我没有时间)。

老实说，在你编程生涯的这个阶段(甚至以后)，你不应该害怕尝试一些东西，如果它们不起作用就把它们扔掉。与其花 3 天时间尝试决定要做什么，不如花 1 天时间在 3 个原型(prototype)中的每一个上尝试不同的方法，然后在最后看看你从原型(prototype)中学到了什么以及你喜欢什么和不喜欢什么。

请注意，虽然尽可能多地解耦是一个很好的目标，但有时问题的本质是紧密耦合的。当这种情况发生时，不要扭曲整个架构来对抗它 - 只要确保它们确实确实需要尽可能紧密地耦合。