C# Interface class + inheritance VS pure Abstract class

Question

Is this OOP approach doomed to fail or is there some merit in this?

Before I understood abstract classes I was getting more or less the same benefits of code reuse by using an interface class + a regular class that implements certain methods of the interface. For example

public interface IMyService
{
    String Helloword1();
    String Helloword2();
    String Helloword3();
}

public class MyService
{
    public String Helloword1(){return "1";}
    public String Helloword2(){return "2";}
    //Helloworld3 is not here so I would be forced to provide implementation in any subclass
    //very similar to calling abstract on a method
}



public class SubClass1: MyService, IMyService
{

    public String Helloword3(){return "3";}

}


public class SubClass2: MyService, IMyService
{

    public new String Helloword2(){return "override method";}
    public String Helloword3(){return "3";}

}

Can anyone see of any advantage of doing this or is this really providing the same advantages as an abstract class?

Be aware that SubClass2.Helloword2() hides MyService.Helloword2(), it does not override it. — D Stanley
– D Stanley, Commented Aug 15, 2014 at 18:56

Reed Copsey · Accepted Answer · 2014-08-15 18:54:04Z

2

Can anyone see of any advantage of doing this or is this really providing the same advantages as an abstract class?

There is a big disadvantage to doing this. You allow people to subclass MyService without implementing Helloword3, since that's not part of the contract.

An abstract class would enforce that the type implements that member. Here, you trust that the user will implement the "required" interface.

answered Aug 15, 2014 at 18:54

Reed Copsey

567k80 gold badges1.2k silver badges1.4k bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Servy Over a year ago

Of course, in the OPs case there's no real reason to prohibit the creation of the MyService type. The reason that abstract classes can't be actually constructed isn't just an arbitrary restriction that isn't really adding value, but rather the restriction exists precisely because abstract classes are dependent on not-yet-implemented behavior, which is their real power. Here the OP's class just inherently isn't abstract, in the conceptual sense, because there's no real reason why you shouldn't be able to construct an instance of it.

Servy · Accepted Answer · 2014-08-15 18:58:00Z

In your example someone can actually construct an instance of MyService and use it without the use of the abstract method.

Honestly, there isn't even really any need to inherit form MyService in your two sub classes. If MyService can be created concretely, that type can be composed, rather than inherited from.

The real value in an abstract class is where the concrete methods actually use the abstract methods. Being able to write things like this:

public abstract class Foo
{
    public abstract Guid CreateUniqueIdentifier();
    public void SaveToDatabase()
    {
        Guid guid = CreateUniqueIdentifier();
        //do stuff with guid
    }
}

You cannot do something like this using your pattern; the concrete methods can never be dependent on the not-yet-implemented methods.

Collectives™ on Stack Overflow

C# Interface class + inheritance VS pure Abstract class

2 Answers 2

1 Comment

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

Comments

Your Answer

Sign up or log in

Post as a guest

Related