对委托的引用是否构成对对象的引用(以防止垃圾回收)？

Question

我很难想出一个很好的方法来解释这个问题,所以让我试着通过例子来解释:

假设我有一些界面.为简单起见,我会说界面是IRunnable,它提供了一种方法Run.(这不是真实的;它只是一个例子.)

现在,假设我有一些预先存在的课程,让我们称之为Cheetah,我无法改变.它之前存在IRunnable; 我不能让它实现我的接口.但我想使用它就像它实现 - IRunnable可能因为它有一个Run方法,或类似的东西.换句话说,我希望能够拥有期望IRunnable和将使用的代码Cheetah.

好的,所以我总能写出CheetahWrapper一些交易.但幽默我,让我写一些更灵活的东西 - 怎么样RunnableAdapter？

我设想类定义是这样的:

public class RunnableAdapter : IRunnable {
    public delegate void RunMethod();

    private RunMethod Runner { get; set; }

    public RunnableAdapter(RunMethod runner) {
        this.Runner = runner;
    }

    public void Run() {
        Runner.Invoke();
    }
}

直截了当,对吧？所以有了这个,我应该可以这样打个电话:

Cheetah c = new Cheetah();
RunnableAdapter ra = new RunnableAdapter(c.Run);

现在,瞧,我有一个实现的对象,IRunner并且在其心中是一个Cheetah.

我的问题是:如果我的这个Cheetah在某些时候超出了范围,并且达到通常会被垃圾收集的程度......它会吗？或者此RunnableAdapter对象的Runner属性是否构成对原始属性的引用Cheetah,以便它不会被收集？我当然希望该引用保持有效,所以基本上我想知道上面的类定义是否足够,或者是否有必要维护对底层对象的引用(比如通过一些私有UnderlyingObject属性),只是为了防止垃圾收集.

Answer 1

是的,该引用仍然有效,实际上可以使用Delegate.Target属性检索 - 在代码中,如ra.Runner.Target.