Question

我有以下对象模型：

class CheckoutAd{
  int AdId;
  int ImpressionCap;
  int ClickCap;
  int ConversionCap;
  // ...
}

class SiteAd{
  int AdId;
  int ImpressionCap;
  int ClickCap;
  //...
}

如您所见，存在重复的代码。所以我决定将重复的代码放在基类中，并从基类扩展上面的类，如下所示：

class BaseAd{
   int AdId;
   int ImpressionCap;
   int ClickCap;
}

但后来我想到了将会有一个MobileAd类的未来，这个基类可能不是一个好的候选者，然后我将不得不改变它。

我应该委托这些属性吗？

你会怎么做？

我应该使用策略模式吗？我将如何委托这种行为？

Answer 1

我看到没有重复的代码，我看到几个类具有相同名称和类型的成员。

Is CheckoutAd a SiteAd? (yes inherit)
Does CheckOutAd have a SiteAd? (yes aggreate)
No to both, leave them the heck alone..

Answer 2

由于我无法推测未来的类，从我在这里看到的，这是一个接口或抽象类的完美位置。

Absract类可以填充需要覆盖的方法和属性。

由于您只有空属性，因此界面看起来更合适。

看看：C# interfaces - What's the point?

Answer 3

这在很大程度上取决于您的应用，目标和时间范围。

您需要实施您认为降低复杂性的任何解决方案。如果您的对象要共享行为和数据，并且从基类继承它们将使您的应用程序更易理解，更易读，更不容易产生混淆，那么请务必找出所有用例。广告，构建基类，并继承。

您不想做的是选择一种基于您尚未想到的“可能”场景的设计。你将最终得到一些对当前状态没有意义的东西，并且不必要地包含一些甚至可能不会发生的事情的结构。

确定您现在可以想到的所有可能类型的广告。确定他们是否共享行为，数据，无，或两者。如果它们共享行为，则从定义行为的基类继承。如果它们共享行为和数据，则从定义行为和数据的基类继承。如果他们共享数据，则在类的实例中包含该数据。

请记住，您的目标是降低复杂性。现在就使用最简单的解决方案，并在遇到问题时对其进行迭代。不要设计你猜测可能发生的问题。

Answer 4

除非方法重复，否则我不会考虑任何继承。你有共同的领域，那又怎样？我无法通过...精确地推断出你的意思，但我们可以说这是毫无意义的。因此，基类本身根本不使用通用字段。

在我的团队中，我们在将重复字段移动到基类时遇到了一些冲突。保留基类中的公共字段可能会违反SRP。说到未来：您可能决定为某个领域提供功能性吸气剂/设定剂，以赋予其一些副作用。您无法完全控制访问，因为它通过基类接口可见。

两个类中具有相同名称的字段应具有与之关联的不同行为。如果行为相同，则创建基类并在那里提取重复的方法。

所以，我的一般建议：除非你概括链接行为，否则不要概括数据成员

P.S。托尼·霍普金森把它直接对了

设计决策 - 与委托的继承

4 个答案: