c# - 试图继承三个基类而不能

Question

我有几个关于我的 User 类设计的问题，但是他们足够不同，我认为他们应该是独立的问题。

所以，首先是与基类的继承有关。我目前继承两个类，ProfileBase 和 ISessionMgrEntry，如下所示:

public class User : ProfileBase, ISessionMgrEntry

但是，我还想继承第三个类，MembershipUser，像这样:

public class User : ProfileBase, MembershipUser, ISessionMgrEntry

但是，编译器不允许我这样做。为什么？而且，我怎么得到围绕这个？

谢谢。

PS - ASP.NET 3.5/C#

编辑

嗨。我认为以下解决方案可能适用于我想要实现的目标。这看起来非常简单直接。我这样做是为了创建一个完整/组合的 User 对象。有没有人看到这可能导致问题的任何原因？一个是在我做这个的时候出现的，这是重叠的属性。例如，MembershipUser 和 ProfileBase 共享“UserName”。我应该只选择一个还是另一个，或者这会是一个设计缺陷吗？建议？再次感谢。

public class User
{
    #region Constructors
    
    private readonly MembershipUser _MembershipUser;
    private readonly ProfileBase _ProfileBase;
    
    #endregion

    public User()
    {
        _MembershipUser = new MembershipUser();
        _ProfileBase = new ProfileBase();
    }

    public string Comment
    {
        get { return _MembershipUser.Comment as string; }
        set { _MembershipUser.Comment = value; }
    }

    public bool IsAnonymous
    {
        get { return _ProfileBase.IsAnonymous as bool; }
    } 

    ....
}

Answer 1

在第一个示例中，您实际上并不是从两个类继承，而是从一个类和一个接口(interface)继承。

C# 不允许从类进行多重继承，但允许您实现多个接口(interface)。请参阅 this MSDN blog post (链接已失效，因此文本粘贴在下方)以获取有关原因的更多信息。

您必须创建一个IMembershipUser 接口(interface)并在您的User 类中实现它。

接口(interface)的命名通常基于具体的类名，前缀为I。所以 MembershipUser 类将有一个接口(interface) IMembershipUser。没有什么可以阻止您使用其他名称，但每个使用接口(interface)的人都习惯了这种命名约定。

There are a number of reasons we don’t implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance).

However, I should point out that it’s possible for compilers to create MI for their types inside the CLR. There are a few rough edges if you go down this path: the result is unverifiable, there is no interop with other languages via the CLS, and in V1 and V1.1 you may run into deadlocks with the OS loader lock. (We’re fixing that last problem, but the first two problems remain). The technique is to generate some VTables in RVA-based static fields. In order to deposit the addresses of managed methods (which probably haven’t been JITted yet), you use the VTFixup construct. This construct is a table of triplets. The triplets consist of a token to a managed method, an address in your image that should be fixed up (in this case, a slot of the VTable you are creating in the RVA-based static), and some flags. The possible flags are described in corhdr.h and they allow you to specify 32- vs. 64-bit pointer sizes, control over virtual behavior, and whether some reverse-PInvoke behavior should be applied in the form of a thunk that eventually dispatches to the managed method. If we are performing an unmanaged->managed transition, you also have some control over which AppDomain should be selected for us to dispatch the call. However, one of these options (COR_VTABLE_FROM_UNMANAGED_RETAIN_APPDOMAIN) doesn’t exist in V1. We added it in V1.1.

There are several reasons we haven’t provided a baked-in, verifiable, CLS-compliant version of multiple implementation inheritance:

1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don’t want this concept (presumably VB.NET, for example). Of course, that’s the business we are in as a common language runtime, but we haven’t got around to doing it for MI yet.

2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?

3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

It’s not at all clear that this feature would pay for itself. It’s something we are often asked about. It’s something we haven’t done due diligence on. But my gut tells me that, after we’ve done a deep examination, we’ll still decide to leave the feature unimplemented.