0

我有以下对象模型：

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 类，这个基类可能不是一个好的候选者，那么我将不得不改变它。

我应该委托这些属性吗？

你会怎么做？

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

4

4 回答 4

3

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

Is CheckoutAd a SiteAd? (yes inherit)
Does CheckOutAd have a SiteAd? (yes aggreate)
No to both, leave them the heck alone..
于 2012-08-09T21:29:42.143 回答
0

由于我无法推测未来的类，从我在这里看到的情况来看，这对于接口或抽象类来说都是一个完美的地方。

一个抽象类可以有方法和属性填充需要被覆盖。

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

看看：C# 接口 - 有什么意义？

于 2012-08-09T21:14:23.180 回答
0

这在很大程度上取决于您的应用程序、您的目标和您的时间框架。

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

你不想做的是根据一些你还没有想到的“可能”场景来选择一个设计。你最终会得到一些对当前状态没有意义的东西，并且不必要地包含一个甚至可能不会发生的东西的结构。

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

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

于 2012-08-09T21:25:16.330 回答
0

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

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

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

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

PS托尼霍普金森说得对

于 2012-08-09T21:41:29.107 回答