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

Question

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

我很难为我的班级设计一个脱钩设计。尽管模拟器的完整版本有更多的类，但我遇到问题的类是：

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

所以我的问题是：考虑到我面临的业务逻辑耦合，这是否真的很好解耦？我可以应用任何其他策略（哪些？）来帮助我设计更强大和灵活的模拟器？

Answer 1

ProductData地图中的每个条目都应该是ProductDataEntry类的成员（除非它们包含的数据变化很大）。

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

整体而言，你的设计听起来还不错 - 虽然没有看到实际的物体和整体架构，但没有办法说出更多的东西，而且这不是那个地方（而且我没有时间）。

说实话，在你的编程生涯的这个阶段（甚至更晚），如果他们不工作，你不应该害怕尝试并扔掉它们。而不是花3天时间尝试决定做什么，花3天时间尝试不同方法的3个原型，然后最后看看你学到了什么，你喜欢什么，不喜欢原型。

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