1

我目前正在对我们的一些框架类进行一些重构（+ 添加新功能）。情况是我们有一个（类似上帝的）类，它执行我们想要拆分的一堆逻辑。该类表示类似于财政代码的验证规则。所以它会验证人名、生日等。

我要做的是将其拆分为单个规则，基本上是一个规则，它根据财政代码验证人的名字，另一个验证生日等等。对于最后的程序员来说，它看起来几乎相同。他不会调用 FiscalCode 规则的巨大构造函数，而是执行类似的操作FiscalCode.GetRules(...)并在此处传递参数。然后GetRules(...)将在内部构造单个规则并将它们作为数组传回。这对我们来说是完全正确和正确的。

你的背景就这么多。现在我的问题如下。FiscalCode 类（这是我们当前强大的神级）有很多实用方法，我将要创建的更多单一“规则类”将需要这些方法。我所知道的是，我仍然需要 FiscalCode 类来做这GetRules(...)件事（这是为了程序员以某种方式保持不变，而不是他们必须做一个全新的事情）。

我有两个选择：

  1. 创建我的新规则类并访问 FiscalCode 类的公共静态实用程序方法
  2. 创建我的新规则类作为 FiscalCode 类 st 的内部嵌套类我已经访问了实用程序方法（因此不需要公开我的实用程序方法）

我已经有一个最喜欢的，但我想先听听你们中的一些人的意见。

谢谢

4

6 回答 6

2

当您的方法变成“实用方法”时，您需要将它们设为静态和公开，但您可能需要将 FiscalCode 重命名为 FiscalCodeUtil。所以很明显它包含什么样的方法。

于 2009-08-11T08:13:46.927 回答
1

我还建议对规范模式进行审查，它为如何解决此类问题提供了一些指导。 这篇文章还提供了一些 C# 示例。

建议的规范模式将引导您走向您的选项#1。

于 2009-08-11T23:24:57.897 回答
0

这些实用程序方法对 FiscalCode 类或规则类有什么依赖关系？他们有没有保存状态？

如果没有任何依赖项，我建议将这些实用程序方法移至单独的类，并让 FiscalCode 类或规则类酌情调用这些方法。

对于您提供的选项，1) 和 2) 之间的唯一区别是规则类是否对不使用它们的类可见。我不认为这真的是一个重要的目标。我以前在做 c++ 的时候一直担心这个……那是浪费时间。

于 2009-08-11T08:15:56.830 回答
0

IMO 您应该选择第一个选项，因为这样，您可以将新创建​​的类公开给外部世界，并且可以编写可在其他地方重用的代码。如果您选择第二个选项，您将创建非常专业的类。您的外部代码甚至可能不知道它的存在，但这可能有利于封装。尽管如此，在某些时候，您可能会决定在您的大班范围之外使用专门的规则，对于这种情况，您最好使用第一个选项。你的选择是什么？

于 2009-08-11T08:20:01.110 回答
0

如果该类不会在FiscalCode类外使用，则使其嵌套。重要的是把这个新类的责任拉出来FiscalCode；那么它在哪里就变成了一个单纯的选择问题。当新类获得更多依赖项时，您可以将其设为外部类。

于 2009-08-11T08:20:04.043 回答
0

我会这样处理（我不擅长 OOP，所以对它持保留态度）：

规则类（嵌套在 FiscalCode 中）实现了一个 IRule 接口，公开了规则方法（如 Validate()，无论返回类型如何都会让您的船浮动）。FiscalCode 有一个 AddRule() 方法，该方法管理内部规则集合并返回对 self 的引用以允许方法链接：

FiscalCode fc = new FiscalCode();
fc.AddRule(new RuleClass1(<params specific to RuleClass1>)
  .AddRule(new RuleClass2(<params specific to RuleClass2>)
  ...

此外，FiscalCode 有一个 Validate() 方法，它遍历每个规则的 Validate() 并管理错误。

IMO 这使用起来非常方便，并且仍然允许嵌套规则类访问 FiscalCode 的实用程序方法。

于 2009-08-11T08:27:32.280 回答