c# - 抽象方法和开闭原则

Question

假设我有以下人为设计的代码:

abstract class Root
{
  public abstract void PrintHierarchy();
}

class Level1 : Root
{
  override public void PrintHierarchy()
  {
    Console.WriteLine("Level1 is a child of Root");
  }
}

class Level2 : Level1
{
  override public void PrintHierarchy()
  {
    Console.WriteLine("Level2 is a child of Level1");
    base.PrintHierarchy();
  }
}

如果我只查看 Level2 类，我可以立即看到 Level2.PrintHierarchy 跟在 the open/closed principle 之后因为它自己做了一些事情并且它调用了它正在覆盖的基本方法。

但是，如果我只看 Level1 类，它似乎违反了 OCP，因为它没有调用 base.PrintHierarchy -- 事实上，在C#，编译器禁止它并出现错误“无法调用抽象基成员”。

使 Level1 看起来遵循 OCP 的唯一方法是将 Root.PrintHierarchy 更改为一个空的虚拟方法，但是我不能再依赖编译器来强制派生类来实现 PrintHierarchy。

我在此处维护代码时遇到的真正问题是看到许多未调用 base.Whatever() 的 override 方法。如果 base.Whatever 是抽象的，那么很好，但如果不是，那么 Whatever 方法可能是被拉入接口(interface)的候选方法，而不是具体的可覆盖方法-- 或者类或方法需要以其他方式重构，但无论哪种方式，都清楚地表明设计不佳。

除了记住 Root.PrintHierarchy 是抽象的或在 Level1.PrintHierarchy 中添加注释之外，我还有其他选择可以快速识别一个类是否像 Level1 是否违反了 OCP？

---

评论中有很多很好的讨论，也有一些很好的答案。我不知道到底要问什么。我认为令我沮丧的是，as @Jon Hanna points out ，有时虚拟方法只是表示“你必须实现我”，而其他时候它意味着“你必须扩展我——如果你不能调用基本版本，你就破坏了我的设计!”但是 C# 没有提供任何方式来表明您指的是哪一个，除了抽象或接口(interface)显然是“必须实现”的情况。 (除非代码契约中有一些东西，我认为这有点超出这里的范围)。

但是如果一种语言确实有一个必须实现与必须扩展的装饰器，如果它不能被禁用，它可能会给单元测试带来巨大的问题。有没有这样的语言？这听起来很像 design-by-contract ，所以如果是在埃菲尔铁塔，我也不会感到惊讶。

最终结果大概是as @Jordão says ，而且它完全是上下文相关的；但在我仍然接受任何答案之前，我将让讨论开放一段时间。

Answer 1

Root 定义如下:Root 对象有一个 PrintHierarchy 方法。它只定义了 PrintHierarchy 方法。

Level1 有一个 PrintHierarchy 方法。它不会停止使用 PrintHierarchy 方法，因此它绝不会违反开放/封闭原则。

现在，更重要的是:将“PrintHierarchy”重命名为“Foo”。 Level2 是否遵循或违反开闭原则？

答案是我们毫 headless 绪，因为我们不知道“Foo”的语义是什么。因此我们不知道 base.Foo 是否应该在方法体的其余部分之后、在其余部分之前、在它的中间或根本不被调用。

1.ToString() 应该返回“System.ObjectSystem.ValueType1”或“1System.ValueTypeSystem.Object”以在打开/关闭状态下保持这种伪装，还是应该将调用分配给 base.ToString() 在返回“1”之前转换为未使用的变量？

显然这些都不是。它应该尽可能返回一个有意义的字符串。它的基类型尽可能返回有意义的字符串，并且扩展它不会从对其基的调用中受益。

开闭原则意味着当我调用 Foo() 时，我期望发生一些 Fooing，并且当我在 Level1 上调用它时我期望一些 Level1 适当的 Fooing 和当我在 Level2 上调用它时一些 Level2 适当的 Fooing。 Level2 Fooing 是否应该涉及一些 Level1 Fooing 也发生取决于 Fooing 是什么。

base 是帮助我们扩展类的工具，不是必需的。