如何将此虚拟方法调用移出构造函数？

Question

我有几个类形成了一个过于复杂的对象图。下面是一个较小的场景。假设 INotifyPropertyChanged 已到位。

class A
{
    public InternalType InterestingProperty { get; set; }
}

class B
{
    public A Component { get; set; }
}

我的帮助器类监视这些事件，并在对象属性更改时更新其属性。这样做是为了让对尽可能多的对象的大约十几个属性感兴趣的其他类可以轻松访问。这一切都包含在一个具有多个变体的框架中，因此继承发挥了作用。

我已经完成了第一个场景，并最终得到了一个像这样的具体类：

class ScenarioOnePropertySpy
{
    protected ScenarioOne PropertySpy(Foo thingToMonitor)
    {
        _thingToMonitor = thingToMonitor;
        RegisterForEvents()
    }

    public B InterestingB { get; }

    protected RegisterForEvents()
    {
        // * Register for _thingToMonitor propertyChanged if first time.
        // * If B is different, unregister the old and register the new.
        // * If B hasn't been set yet register for PropertyChanged on it.
        // * If B.Component isn't the same as last time unregister the
        //      old and register the new.
    }

    protected Update()
    {
        // Some monitored object changed; refresh property values and
        // update events in case some monitored object was replaced.
        B = _thingToMonitor.B;
        RegisterForEvents()
    }

    private Handle_PropertyChanged(...) { Update(); } 
}

这是令人讨厌的事件注册，但将这种丑陋从想要了解属性的类中移出才是目的。现在我已经转到场景 2，它监视不同的对象/属性，并使用我的具体类作为抽象类的指南：

abstract class PropertySpy
{
    protected PropertySpy(FooBase thingToMonitor)
    {
        _thingToMonitor = thingToMonitor;
        RegisterForEvents()
    }

    protected abstract void RegisterForEvents()

    // ...
}

哎呀。我在构造函数中有一个虚拟方法调用。理论上，它对于我的所有场景都是安全的，但 R# 警告一直困扰着我。我确信，如果有一天我继续前进，将会导致一个需要一段时间才能解决的问题。该方法肯定需要使用派生类型的属性。

我可以删除该方法并强制派生类型自行进行事件管理。这会违背基类的目的。有人会忘记遵守合同，这就会变成支持事件；我花了足够的时间编写文档。我想到的另一个方法是公开 RegisterForEvents() 并要求用户在构造后调用它。 “创建然后初始化”模式在 .NET 中很糟糕，人们总是忘记。目前，我正在考虑另一个类的概念，该类执行通过构造函数注入的事件注册。然后派生类可以提供该类来实现与虚方法相同的效果，而不会产生危险。但进行注册的操作实际上需要与 PropertySpy 相同的属性接口；这看起来很乏味，但我想“丑陋但有效”比我所拥有的更好。

我缺少什么吗？如果论点令人信服的话，我什至会接受“这是一个警告，而不是规则”作为答案。

Answer 1

您的场景似乎足够复杂，需要考虑采用完全不同的类实例化方法。用工厂来建造地产间谍怎么样？

public class PropertySpyFactory<T> where T : PropertySpy, new()
{
    public static T Create()
    {
        T result = new T();
        // … whatever initialization needs to be done goes here …
        result.RegisterForEvents();
        return result;
    }
}

ScenarioOnePropertySpy spy = PropertySpyFactory<ScenarioOnePropertySpy>.Create();

它在代码中是可挽救的，实例初始化可以轻松扩展，一旦你转向 IoC，它会感觉很自然，不需要太多重构。

更新：另一种选择是，a）你的间谍层次结构足够平坦，b）你不需要使用共同的祖先，或者你可以用接口替代它：

public abstract class PropertySpy<T> where T : PropertySpy, new()
{
    public static T Create()
    {
        T result = new T();
        // … whatever initialization needs to be done goes here …
        result.RegisterForEvents();
        return result;
    }

    …
}

public class ScenarioOnePropertySpy : PropertySpy<ScenarioOnePropertySpy>
{
    …
}

ScenarioOnePropertySpy spy = ScenarioOnePropertySpy.Create();

换句话说，工厂方法位于共同祖先内。这种方法的缺点是它不是正交的（工厂没有与正在构造的类分离），因此可扩展性和灵活性较差。然而，在某些情况下可能是一个有效的选择。

最后但并非最不重要的一点是，您可以在每个类中再次创建一个工厂方法。优点是您可以保护构造函数，从而强制用户使用工厂方法而不是直接实例化。

Answer 2

我认为关键问题是，当调用虚拟方法时，您的子类构造函数和初始值设定项尚未执行。因此，在您重写的方法中，您的子类可能没有初始化您期望初始化的所有内容。