如何避免从基构造函数调用虚拟方法

Question

我在图书馆有一个抽象类。 我试图尽可能轻松地正确实现此类的派生。 问题是我需要通过三步过程来初始化对象：获取文件，执行一些中间步骤，然后使用该文件。 第一步和最后一步是派生类特有的。 这是一个精简的示例。

abstract class Base
{
    // grabs a resource file specified by the implementing class
    protected abstract void InitilaizationStep1();

    // performs some simple-but-subtle boilerplate stuff
    private void InitilaizationStep2() { return; }

    // works with the resource file
    protected abstract void InitilaizationStep3();

    protected Base()
    {
        InitilaizationStep1();
        InitilaizationStep2();
        InitilaizationStep3();
    }
}

当然，问题在于构造函数中的虚拟方法调用。 我担心，如果库的使用者不能指望派生类完全初始化，那么他们在使用该类时会发现自己受到限制。

我可以将逻辑从构造函数中提取到受保护的 Initialize() 方法中，但随后实现者可能会调用 Step1() 和 Step3() > 直接而不是调用 Initialize()。 问题的关键在于，如果跳过Step2()，不会出现明显的错误； 只是在某些情况下表现很糟糕。

我觉得无论哪种方式，图书馆的未来用户都必须解决一个严重且不明显的“陷阱”。 我是否应该使用其他设计来实现这种初始化？

如有需要，我可以提供更多详细信息； 我只是想提供表达问题的最简单的例子。

Answer 1

我会考虑创建一个抽象工厂，它负责使用用于初始化的模板方法。

举个例子：

public abstract class Widget
{
    protected abstract void InitializeStep1();
    protected abstract void InitializeStep2();
    protected abstract void InitializeStep3();

    protected internal void Initialize()
    {
        InitializeStep1();
        InitializeStep2();
        InitializeStep3();
    }

    protected Widget() { }
}

public static class WidgetFactory
{
    public static CreateWidget<T>() where T : Widget, new()
    {
        T newWidget = new T();
        newWidget.Initialize();
        return newWidget;
    }
}

// consumer code...
var someWidget = WidgetFactory.CreateWidget<DerivedWidget>();

这个工厂代码可以得到显着的改进 - 特别是如果你愿意使用 IoC 容器来处理这个责任......

如果你无法控制派生类，你可能无法阻止它们提供一个可以调用的公共构造函数 - 但至少你可以建立一个消费者可以遵守的使用模式。

虽然并不总是能够阻止您的类的用户搬起石头砸自己的脚，但是，您可以提供基础设施来帮助消费者在熟悉设计后正确使用您的代码。

Answer 2

对于任何类的构造函数来说，这都太多了，更不用说基类了。 我建议您将其分解为单独的 Initialize 方法。

Answer 3

在很多情况下，初始化工作涉及分配一些属性。 可以使这些属性本身抽象，并让派生类重写它们并返回一些值，而不是将该值传递给基构造函数进行设置。 当然，这个想法是否适用取决于你具体班级的性质。 不管怎样，构造函数中有这么多代码是很臭的。

Answer 4

乍一看，我建议将这种逻辑转移到依赖于此初始化的方法中。 就像是

public class Base
{
   private void Initialize()
   {
      // do whatever necessary to initialize
   }

   public void UseMe()
   {
      if (!_initialized) Initialize();
      // do work
   }
}

Answer 5

由于步骤 1“获取文件”，因此最好进行 Initialize(IBaseFile) 并跳过步骤 1。这样消费者就可以随心所欲地获取文件 - 因为它无论如何都是抽象的。 您仍然可以提供“StepOneGetFile()”作为返回文件的抽象，这样他们就可以选择以这种方式实现它。

DerivedClass foo = DerivedClass();
foo.Initialize(StepOneGetFile('filepath'));
foo.DoWork();

Answer 6

编辑：出于某种原因，我为 C++ 回答了这个问题。 抱歉。对于 C#，我建议不要使用 Create() 方法 - 使用构造函数并确保对象从一开始就保持有效状态。 C# 允许从构造函数进行虚拟调用，如果您仔细记录其预期函数以及前置条件和后置条件，则可以使用它们。 我第一次推断 C++ 是因为它不允许来自构造函数的虚拟调用。

将各个初始化函数设为私有。 可以是私有和虚拟。 然后提供一个公共的非虚拟 Initialize() 函数，以正确的顺序调用它们。

如果您想确保在创建对象时一切都发生，请使构造函数受保护，并在调用 Initialize( 的类中使用静态 Create() 函数) 在返回新创建的对象之前。

Answer 7

您可以使用以下技巧来确保以正确的顺序执行初始化。 据推测，您在基类中实现了一些其他依赖于初始化的方法 (DoActualWork)。

abstract class Base
{
    private bool _initialized;

    protected abstract void InitilaizationStep1();
    private void InitilaizationStep2() { return; }
    protected abstract void InitilaizationStep3();

    protected Initialize()
    {
        // it is safe to call virtual methods here
        InitilaizationStep1();
        InitilaizationStep2();
        InitilaizationStep3();

        // mark the object as initialized correctly
        _initialized = true;
    }

    public void DoActualWork()
    {
        if (!_initialized) Initialize();
        Console.WriteLine("We are certainly initialized now");
    }
}

Answer 8

我不会这样做。 我通常发现在构造函数中做任何“真正的”工作最终都是一个坏主意。

至少，有一个单独的方法来从文件加载数据。 您可以进一步提出一个论点，让一个单独的对象负责从文件构建您的对象之一，将“从磁盘加载”的关注点与对象的内存中操作分开。