帮助类设计答案

【问题标题】：Help with Class Design帮助类设计
【发布时间】：2011-01-16 12:44:41
【问题描述】：

我有一个类必须从一个系统的数据库中获取产品信息并将其保存到另一个系统的产品数据库中。

我将从第一个系统产品 A 和另一个产品 B 中调用产品。产品 B 的数据取决于从用户选择的设置。

因此，产品 B 可能有一个 GetDescriptions 方法，该方法查看用户设置，该设置说使用产品 A 中的 Description1 变量，或者他们可以选择描述 2，或者他们可以使用产品 B 中已有的描述。

这很好，但是有很多设置和获取描述的方法。这就是问题所在，我有很多方法似乎都与产品 B 相关。GetDescription、GetName、GetSku 等方法都是根据用户设置设置的，并且都依赖于产品 A。

虽然它们似乎都与产品 B 相关，但该类变得非常大，我想将一些方法从该类移到另一个类中。我正在考虑使用工厂模式。如下所示（代码只是一个快速的想法）

public class ProductBuilder
{
    public ProductB BuildProduct()
    {
          SkuBuilder.BuildSku(ProductB,ProductA);
          ProductDescriptionBuilder.BuildDescription(ProductB,ProductA);
    }
}

我的问题是：什么是好的设计？我上面提出的方法可以接受吗？您认为这种设计有什么潜在的问题吗？

【问题讨论】：

标签： oop architecture class-design

【解决方案1】：

这是 factory 模式的变体，是一种非常有用的设计形式。您所写的内容暗示了一种简洁的三类设计：ProductA 包含仅与 A 相关的方法和属性，ProductB 包含与 B 相关的方法和属性，以及 ProductBuilder，它基于 A 为您构建了 B。

唯一的缺陷是一般的 OOP 设计问题。确保 ProductConverter 不依赖于 A 或 B 的内部知识——换句话说，确保 A 和 B 的公共接口足够丰富，足以让 ProductConverter 完成其工作。只有 A 应该连接到 A 的产品数据库，只有 B 应该连接到 B 的产品数据库。避免单例和全局状态。这些是您在几乎任何应用程序中都会做的事情，但在这种系统中它们会成为特殊的陷阱。

【讨论】：

【解决方案2】：

我会建议在您的 ProductBuilder 中使用抽象，而不是直接使用 ProductA 和 ProductB ...这样您以后可以轻松地更改实现。使用接口或抽象类...

此外，测试和模拟也会更容易。

【讨论】：