Interface inheritance limits

Question

Known that C# support interface inheretence, i want to create an interface "B" that inherits from a base interface "A" but also hides some interface "A" members, just like a Class uses explicit interface implementation to hide an interface member, unless the class instance is casted to the implemented interface:

MyExample:

First i create an interface IDbObject with some members and methods

public interface IDbObject
{
    IDbObject ParentObject
    {
        get;
    }
    .
    .
    .
}

and then I create a second interface IDbConstraint that inherits the first interface but since inheritance is specialization I know more about the ParentObject member which i want to call ParentTable in the child interface.

public interface IDbConstraint : IDbObject
{
    // Hide IDbObject.ParentObject

    IDbTable ParentTable
    {
        get;
    }
    .
    .
    .
}

I'm not really sure what you're asking. Why don't you just implement the derived interface IDbConstraint instead of IDbObject? Or depending what problem you're actually trying to solve, generics might be the answer. — Keith Rousseau, Feb 28 '18 at 12:32
Possible duplicate of [Shadowing Inherited Generic Interface Members in .NET: good, bad or ugly?](https://stackoverflow.com/questions/7035781/shadowing-inherited-generic-interface-members-in-net-good-bad-or-ugly) — hardkoded, Feb 28 '18 at 12:47
"Inherited" is always the wrong mental model when talking about interfaces. You don't inherit squat from an interface, all you get it is a demand to write more code. IDbConstraint has two members, nothing is getting "shadowed". It gives you a headache when implementing it since their names are ambiguous, explicit implementation required to deal with it. If you have the choice, you do, then just give them different names. — Hans Passant, Feb 28 '18 at 12:57
Declaring an interface IDbConstraint from scratch with half of the properties and the methods already declared in another interface IDbObject is just a waste of time and storage. Inheretence can solve this type of issues so why not use it ? — Samir, Mar 02 '18 at 16:57

score 0 · Answer 1 · answered Feb 28 '18 at 12:57

0

I do not know the details and therefore I could say something wrong. But i Think it could be a solution to use an abstract class instead of an interface.

public interface IDbObject
{
    IDbObject ParentObject
    {
        get;
    }
}
public abstract class IDbConstraint : IDbObject
{
    public IDbObject ParentTable 
    {
        get;
    }

    //Hidden becouse not public
    IDbObject IDbObject.ParentObject => throw new NotImplementedException();
}

answered Feb 28 '18 at 12:57

danilonet

1,757
16
33

Using an abstract class instead of an interface is a major architectural change, in my opinion, it is considered a workaround more than a solution. – Samir Mar 02 '18 at 16:53

score 0 · Answer 2 · answered May 23 '20 at 18:21

The best solution i know to this is to wait till the implementation time, then use explicit interface implementation to hide the ParentObject member, unless the instance is casted to IDObject:

public class DbConstraint : IDbDbConstraint
{
    IDbObject IDbObject.ParentObject
    {
        get;
    }

    IDbTable ParentTable
    {
        get;
    }
    .
    .
    .
}

Interface inheritance limits

2 Answers2