Question

我正在使用 C#。我有一个产品类，其中包含 SKU、名称、描述等字段，以及 setSku、setDescription、setImages 等方法（产品附带图像）。我最初将这些方法放在 Product 类中，但由于客户设定 SKU、描述和图像的选项过多，类变得非常庞大。类内有大量的代码。因此，我将大型的 Product 类分解成 ProductSku 类、ProductDescription 类等。但问题在于，这些类中需要访问一些相同的字段。我开始在这些单独的类上调用方法，并反复传递相同的对象，但这似乎不太对。因此，现在我决定创建一个全局的（使用 Singleton 设计模式）CurrentProduct 类，它具有我为其他 Product 类创建的所有字段。我的问题是，这听起来是否正确，你会怎么做？

我正在工作的程序，基本上只是从数据库1的一个表中取出产品，并将产品保存到数据库2的一个表中。然而，用户有很多设置可用于他们希望从数据库1进入数据库2时字段的外观。

澄清一下: 上述提到的set和get方法不是常规的getter和setter方法。我使用属性，但将它们称为“set”是因为在更新某些字段之前需要编写大量代码进行格式化。我理解造成的混淆，并为未能澄清而道歉。

Answer 1

当前产品的单例听起来很糟糕。你只是用不同的名称调用全局变量。

我不知道什么是Sku，但是对于其余部分（描述和图片），如果它们是产品的属性（我认为是这样），则应属于产品类。

如果您经常一起传递你们的“课堂作品”，那么这是它们应该在一起的强烈迹象。

如果您希望，可以使用“partial”关键字将代码（而不是类）分成几个文件。像这样：

// This file is Product.CodeAboutThingA.cs

public partial class Product
{
    // Some stuff related to A here...
}

而在另一个文件中：

// This file is Product.CodeAboutThingB.cs

public partial class Product
{
    // Some stuff related to B here...
}

Answer 2

To give my .5 cents, a class that can only be managed by splitting it into partials has quite some code smell. Separating the whole thing into several classes sounds good, especially when you already identified stuff like SKU etc. to be its own class.

你应该问自己的事情是...

Is it OK if I can only access an SKU through a valid Product instance? Even if it is just an identifier, such an identifier may be quite complex in itself.
In what way must the SKU use stuff from the Product class? If the product is the only one instantiating an SKU, it may be OK to pass the product into the SKU. The two classes are now coupled fairly tight, but still better than a single Product mess with no semantics.
Can you identify what are the common parts that need to be shared throughout? Maybe you are missing an entity or a value object that is that "common part"?
Maybe you would be happier with a Product Builder, instead of letting the Client rummage around the innards of a Product instance?

在我看来，当你有一个包含1000行以上代码的类时，仍然缺少很多对你的“产品”真正是什么以及在应用范围内如何行为的了解...

Answer 3

也许您应该考虑将它合并回一个类中，但为了使其可读，请使用partial修饰符？

另一个答案是创建一个抽象类产品并从中继承专业化类。

友情链接