设计决策——带委托的继承

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。说到未来：您可能决定为某个字段提供功能性 getter/setter 以赋予它一些副作用。你不能完全控制访问，因为它是通过基类接口可见的。

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

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

附：托尼霍普金森说得很对