IQueryable<T>继承疑问及接口扩展方法优先级解析

Great question! This is a common pattern in .NET (and other languages) that often confuses developers, so let's break down your two questions clearly.

1. Scenarios Where Explicitly Inheriting Both Child and Parent Interfaces Makes Sense #

Even when IChildInterface already inherits from IParentInterface, explicitly declaring both in the interface definition serves several practical purposes:

• Backward Compatibility & Historical Context
  Take IQueryable<T> as an example: IEnumerable<T> was introduced in .NET 2.0, while the non-generic IEnumerable existed since .NET 1.0. By explicitly listing IEnumerable alongside IEnumerable<T> in IQueryable<T>'s definition, older non-generic code that checks for direct implementation of IEnumerable (via reflection or type checks) works seamlessly. Without this explicit declaration, some legacy tools or code might fail to recognize that IQueryable<T> supports non-generic enumeration, since they only look at directly implemented interfaces instead of traversing the inheritance chain.

• Improved Readability & Clarity
  Explicitly listing both interfaces makes the contract of the interface immediately clear to developers. When you look at IQueryable<T>'s definition, you don't have to dig into IEnumerable<T>'s inheritance to know it supports both generic and non-generic enumeration. This reduces cognitive load and makes the interface's capabilities obvious at a glance.

• Insulation Against Future Refactoring
  If the inheritance relationship between IChildInterface and IParentInterface ever changes (unlikely in .NET's core interfaces, but possible in your own codebase), explicitly declaring both ensures that code dependent on the parent interface doesn't break. For example, if IChildInterface stopped inheriting from IParentInterface later, any code relying on IQueryable<T> implementing IEnumerable would still work if it was explicitly declared.

• Meeting Framework/Tool Requirements
  Some frameworks, serialization tools, or dependency injection containers rely on direct interface implementation checks (instead of inheritance chains) to determine behavior. Explicitly declaring the parent interface ensures your type meets these requirements without extra configuration.

2. Priority of Extension Methods with the Same Name #

When you have extension methods targeting IChildInterface and IParentInterface with identical names and signatures, the compiler follows a clear priority rule:

The most specific type match wins.

Here's how it plays out in practice:

Example Code #

// Interfaces
public interface IParentInterface { }
public interface IChildInterface : IParentInterface { }

// Extension methods
public static class ParentExtensions
{
    public static void Execute(this IParentInterface obj)
    {
        Console.WriteLine("Parent interface extension");
    }
}

public static class ChildExtensions
{
    public static void Execute(this IChildInterface obj)
    {
        Console.WriteLine("Child interface extension");
    }
}

// Usage
IChildInterface childInstance = new MyImplementation();
childInstance.Execute(); // Outputs "Child interface extension"

IParentInterface parentInstance = new MyImplementation();
parentInstance.Execute(); // Outputs "Parent interface extension"

• When the compile-time type of the variable is IChildInterface, the compiler picks the extension method targeting IChildInterface because it's a more specific match than the one for IParentInterface.
• If the compile-time type is IParentInterface (even if the runtime type is IChildInterface), the compiler uses the extension method for IParentInterface, since it can't know the runtime type at compile time.

If both extension methods are defined in the same static class, the compiler will throw an ambiguity error—you'll need to rename one or explicitly cast the object to the desired interface to resolve it.

内容的提问来源于stack exchange，提问作者rahulaga-msft