我有一个类必须从一个系统的数据库中获取产品信息并将其保存到另一个系统的产品数据库中。
我将从第一个系统产品A和另一个产品B调用产品。产品B的数据取决于从用户选择的设置。
因此,产品B可能有一个GetDescriptions方法,该方法查看用户设置,该设置说明使用产品A中的Description1变量,或者他们可以选择说明2,或者他们可以使用产品B中已有的描述。
这很好,但有很多设置和方法可以获得描述。这就是问题,我有很多方法似乎都与产品B有关。像GetDescription,GetName,GetSku这样的方法都是根据用户设置设置的,都依赖于产品A.
虽然它们似乎都与产品B有关,但是这个类的增长非常大,我希望将一些方法移出另一个类。我在考虑使用Factory模式。像下面的东西(代码只是一个简单的想法)
public class ProductBuilder
{
public ProductB BuildProduct()
{
SkuBuilder.BuildSku(ProductB,ProductA);
ProductDescriptionBuilder.BuildDescription(ProductB,ProductA);
}
}
我的问题是:这有什么好的设计?我上面提出的方法是否可以接受?你觉得这个设计有什么潜在的问题吗?
答案 0 :(得分:3)
这是 factory 模式的变体,它是一种非常有用的设计形式。您所写的内容表明了一个简洁的三级设计:ProductA
包含仅与A相关的方法和属性,ProductB
包含与B相关的方法和属性,ProductBuilder
构建了一个B基于A。
唯一的缺陷是一般的OOP设计问题。确保ProductConverter不依赖于A或B的内部知识 - 换句话说,确保A和B的公共接口足够丰富,以便ProductConverter完成其工作。只有A应该连接到A的产品数据库,只有B应该连接到B的产品数据库。避免单身和全球状态。这几乎是你在几乎所有应用程序中都会做的事情,但它们将成为这种系统中的特殊陷阱。
答案 1 :(得分:1)
我建议在ProductBuilder中使用抽象,而不是直接使用ProductA和ProductB ...这样,您可以在以后轻松地更改实现。使用接口或抽象类......
此外,测试和模拟也会更容易。