-8
public abstract class PureAbstract
{
    public abstract bool GetData();
}
public class ChildClass : PureAbstract
{
    public override bool GetData()
    {
        Console.WriteLine("Pure Abstract Class called");
        Console.ReadKey();
        return true;
    }
}
public class DIClass
{
    private PureAbstract pureAbstract;
    public DIClass(PureAbstract abstractClass)
    {
        this.pureAbstract = abstractClass;
        this.pureAbstract.GetData();
    }
}
class Program
{
    static void Main(string[] args)
    {
        ChildClass child = new ChildClass();
        DIClass pureAbstract = new DIClass(child);
    }
}

We all know that Interface allows us Multiple Inheritance in C#, but I want to know that if we ignore this reason and assume we always need single inheritance in our application then what is difference between Pure Abstract Class and Interface.

  • 2
    Interface does *not* allow for multiple inheritance. A class can implement multiple interfaces, but that is not the same thing as inheritance. Although default interface methods (C# 8) kind of blur that line. – mason Aug 06 '19 at 18:13
  • Thanks for reply, but I am not satisfied with theoretical answer, take an example we have Dependency Injection, if not concern about Multiple inheritance or any other future concern, just think about Single Inheritance, can we use the pure abstract class in place of interface in DI. – Saurabh Rathi Aug 06 '19 at 18:19
  • @mason that line was always blurry. What actually _is_ the diff between implements and inherits? From the outside? – H H Aug 06 '19 at 18:22
  • No, you should never use abstract classes for DI if you want to follow the correct SOLID principles. Dependency injection principle #1 states the following: ```High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).``` Use interfaces, not abstract classes. – Aiyuni Aug 06 '19 at 18:23
  • @SaurabhRathi You'll likely have better luck finding a concrete answer by providing a [minimal, complete and verifiable example](https://stackoverflow.com/help/minimal-reproducible-example) – devNull Aug 06 '19 at 18:23
  • @Aiyuni Looks like you don't make difference between abstract class and *pure* abstract class. Besides multiple inheritance, there is no difference between pure abstract class and interface. – Ivan Stoev Aug 06 '19 at 18:27
  • @IvanStoev correct me if I'm wrong, but I believe that interfaces allow for more loosely coupled code than pure abstract classes due to the fact that you can't extend more than 1 pure abstract class. And DI is based around loosely coupled code. – Aiyuni Aug 06 '19 at 18:33
  • @devNull - I added the sample of code, which I think you understand what I want to tell you? – Saurabh Rathi Aug 06 '19 at 18:55
  • 2
    I would offer that abstract classes in .NET *cannot* be pure because they will always ultimately inherit from `Object` and therefore have a non-zero size in addition to the vtable. Interfaces do not inherit from `Object` (they're *convertible* to `Object` when you have an instance because all *instances* are of some type that inherits from `Object`). This question may make sense in C++ but not in .NET languages. – madreflection Aug 06 '19 at 20:23

1 Answers1

1

In short, there is no reason why you would want a pure abstract class. Don't ever use pure abstract classes, there is no point in using them. If you want to use a 'pure abstract class', go with interface so you can still use multiple interfaces.

An interface is like a contract. If a class implements an interface it has to implement all the services listed in the interface.

An abstract class is like a skeleton. It defines a certain way its extended classes will work while letting the abstract methods to be unique.

Aiyuni
  • 780
  • 5
  • 15
  • 1
    If there is no reason to use the pure abstract class then why C# allows us to use the pure abstract class and doesn't force use to create the interface in place of pure abstract class. – Saurabh Rathi Aug 06 '19 at 18:25
  • 1
    After some thought, there are some uses, such as declaring and initializing constants in a pure abstract class (in an interface you can't declare constants). Or using a pure abstract class so that you can extend another abstract class later on (interfaces cant extend classes). But in general, if you have to do it those ways (i.e your 'interface' requires you to declare constants; you need your pure abstract class (with no implementations at all) to extend ANOTHER abstract class), then it's most likely a design issue. – Aiyuni Aug 06 '19 at 18:41
  • If you declare a pure abstract class and use that as an "interface" you still have the option to implement a previously unimplemented method, changing it from abstract to virtual. (Default interface implementations will change that, but lack instance fields.) I don't know if I can call that a benefit of abstract classes, though, since you can implement an interface with anything, including an abstract class. I don't know if I'd say *never* use a pure abstract class because someone will come up with a use case. But most of the time it seems weird and pointless. – Scott Hannen Aug 07 '19 at 01:25