Understanding Interfaces V Classes

Question

Hi I know this is a well trodden question but after reading the following post What is the difference between an interface and a class, and why I should use an interface when I can implement the methods directly in the class? I am struggling to understand why an interface really needs to be used. Sorry for the basic question here but while I get the theory as a contract between the interface and the class I cannot seem to see how useful this is. I know it can help you create objects easily but I feel like I am missing something.

I have read so many posts on here and all over the internet to how to use an Interface but half of the time I am like well if you create a class and inherit it would it not do the same thing? what am I missing here?

Answer 1

Why interfaces?

Do you drive a car? If not, I assume you know what driving a car generally entails (steering wheel, accelerator, brake). The rest of the answer assumes you drive a car and have a car that is a different brand than mine.

Have you ever driven my car? No. But if given access, would you be able to drive my car without needing to learn how to drive my car? Yes.
The same applies to me. I've never driven your car, but I would be able to drive it without needing to learn how to drive it.

Why is that? Because all cars share the same interface. Steering wheel, accelerator on the right, brake in the middle. No two cars are exactly the same, but they are built in a way that the interaction between a driver and any car is exactly the same.

Compare this to an F16 fighter jet. Being able to drive a car does not make you able to pilot a jet because its interface is different. It doesn't have a steering wheel, it doesn't have accelerator/brake pedals.

The main benefit is clear: drivers don't need to learn how to drive every car individually.

Now, to complete the analogy, the general concept of a car is an interface, whereas specific cars are classes. The main benefit is clear: you don't need to write custom code for every similar class.

---

A practical example

public class BMW 
{
    public SteeringWheel SteeringWheel { get; set; }
    public Pedal Accelerator { get; set; }
    public Pedal Brake { get; set; }
}

public class BMWDriver
{
    public void ParticipateInRace(BMW myBMW) 
    {
        myBMW.Accelerator.Press();

        myBMW.SteeringWheel.TurnLeft();
        myBMW.SteeringWheel.TurnRight();

        myBMW.Accelerator.Release();
        myBMW.Brake.Press();

        myBMW.Brake.Release();
    }
}

This driver only knows how to drive a BMW.

public class Audi 
{
    public SteeringWheel SteeringWheel { get; set; }
    public Pedal Accelerator { get; set; }
    public Pedal Brake { get; set; }
}

public class AudiDriver
{
    public void ParticipateInRace(Audi myAudi) 
    {
        myAudi.Accelerator.Press();

        myAudi.SteeringWheel.TurnLeft();
        myAudi.SteeringWheel.TurnRight();

        myAudi.Accelerator.Release();
        myAudi.Brake.Press();

        myAudi.Brake.Release();
    }
}

This driver only knows how to drive an Audi.

But in reality, a driver would be able to drive any car (that has a steering wheel and two pedals).

So how do we tell the compiler that any car can be used? We give them a commonality they both share: the interface.

public interface ICar
{
    SteeringWheel SteeringWheel { get; }
    Pedal Accelerator { get; }
    Pedal Brake { get; }
}

public class BMW : ICar { /* same as before */ }

public class Audi : ICar { /* same as before */ }

public class Driver
{
    public void ParticipateInRace(ICar anyCar)
    {
        anyCar.Accelerator.Press();

        anyCar.SteeringWheel.TurnLeft();
        anyCar.SteeringWheel.TurnRight();

        anyCar.Accelerator.Release();
        anyCar.Brake.Press();

        anyCar.Brake.Release();
    }
}

We now have a more generalized Driver who is able to drive any car that has a steering wheel and two pedals.

---

Why not inheritance?

half of the time I am like well if you create a class and inherit it would it not do the same thing? what am I missing here?

In some cases, inheritance would work. However, inheritance is generally an inferior solution, especially when you get into more complex codebases or more advanced architectures.

Don't worry, all developers once loved inheritance and then needed to learn to not use inheritance as a cure-all. It's part of the normal lifecyle of a developer :)

One of the biggest reasons why is that you can't derive from more than one class, but you can implement multiple interfaces.

Let's say we have three types of sports that can be done

public class Runner 
{  
    public void Run() { /* running logic */ } 
}

public class Swimmer
{  
    public void Swim() { /* swimming logic */ } 
}

public class Cyclist
{  
    public void Cycle() { /* cycling logic */ } 
}

Now we need to create a specialized sport which entails running, e.g. basketball.

public class BasketBallPlayer : Runner 
{ 
    public void ThrowBall() { /* throwing logic */ }

    // Running is already inherited from Runner
}

Great, no problems yet. But now, we need to create a triathlete class, which entails all three sports (running, swimming, cycling)

public class Triathlete: Runner, Swimmer, Cyclist { ... }

And this is where the compiler breaks down. It refuses to allow you to inherit from multiple base classes at the same time. The reasons are much deeper than this answer can delve into, Google it if you want to know more.

However, had we used interfaces:

public interface IRunner
{
    void Run();
}

public interface ISwimmer
{
    void Swim();
}

public interface ICyclist
{
    void Cycle();
}

Then the compiler would've allowed this:

public class Triathlete: IRunner, ISwimmer, ICyclist 
{ 
    public void Run() { /* running logic */ } 

    public void Swim() { /* swimming logic */ } 

    public void Cycle() { /* cycling logic */ } 
}

And this is why interfaces generally beat inheritance (among other reasons).

There are more reasons why interfaces are generally better, but this is the biggest one. Google it if you want more explanation, I can't delve into it all for a StackOverflow answer.

Answer 2

one scenario where you (the creator of the overall algorithm) simply doesn't know the implementation in advance.

To convert them into real life scenarios: FxCop + StyleCop both use the visitor pattern to scan code. So, the creators of the tool (FxCop) in this example, has some basic code that couples to some UI/CLI and expects some certain properties in the scan result such as severity/problem etc.

And while FxCop ships with default rules, you, as end customer, can also extend these rules to your own liking. The only way for FxCop to do that is to rely on polymorpishm Interfaces/Abstract Classes.

So the FxCop tool expects a rule instance which detects something and reports back success or failure.

But your organization might have a custom rule which only you need. Let's say it's something like: All our namespaces must begin with myorg.mytool

That's an example of where you must use abstraction (can't just implement the code in a class up front) since Microsoft doedn't know anything in particular about the custom code rules tha you enforce in your organisation.

Another example is the way that Domain- and Infrastructure code are separated in Domain Driven Design.

So, let's say you have a book collection app. One where you can get a book, all books books by an auther etc.

You will then have a Domain Type call something like BookRepository where all your books are persisted. There's two sides of this: 1. Domain where all handling logic of books are placed and 2. persistence code (IO/Database or whatever).

The reason to split these two is because then the domain logic (business logic) doesn't get entangled with persistance code. The Domain code doesn't want to know how a book is persisted. It only cares about what you can do with a book (Get by Author, Buy, Sell etc.).

The interface in this case comes in as you place an interface in your Domain code called something like IBookRepository and you go on creating all the code you need with unit tests. At this point, you don't care much about how books are stored - you just care that they are stored. Then another team or later, you can dive into the details about how the book sa restored. In a database, in cache or something else. The persistence code can also evolve without touching the domain code which is an integral part of Continuous Release principles: As small updates as possible. In other words, it allows you to ship infrastructure updates wo touching the business code. It could be that you app is working excellent but you wan't to update the database drivers.

Abstract classes are something in between interfaces and classes but should be used similar as to interfaces / they're close in usage to interfaces than classes.

** finally, there's another reason to use interfaces which is that an interface can be considered an aspect and you can apply multiple interfaces (aspects) to a single class (multiple inheritance) with little friction whereas placing it in classes forces you to do single inheritance which can result in large and overly complex inheritance hierachies.

Hope it helps you a bit

Answer 3

Well in essence and with as few words as i can think of for each case:

• Abstract should be used when you have different entities sharing common behavior.
• Interface should be used when you want different entities to be able to work with the same code

For example you would use abstract when:

You want to create an app that handles animals. You create an abstract class Animal which contains some fields NoLegs,HasTail,NoEyes. You create a Dog , a Cat and a Panda class, all inheriting from Animal. Now you end up having 3 classes, but with the shared code defined in 1 other class, because all of them share those descriptive traits.

Now for the interface: Inside a service in your project you create a method called 'StartRunning'. The definition of the method is :

public void StartRunning(List<ICanRun> thingsThatRun)
{
    thingsThatRun.forEach(t => t.StartRunning());
}

Now you go back to your animal abstract class and you declare that it should implement ICanRun interface, and the compiler will force you to go and define the method on Dog,Cat and Panda classes. The great part now is that:

1. You have defined properties that are common in different objects only once. ( number of eyes is a trait common when describing animals)
2. The way each animal runs is different.Your dogs run method could 'just run straight ahead', while your cat run method could 'look for the closest wall and climb'. The Panda would probably throw cause pandas don't run.

The real magic on the interface: Because your StartRunning method does not consider classes, but rather that the objects passed comform to the ICanRun interface, you can have an other class, say Bike, that also implements ICanRun and defines the method StartRunning. Then you can create a list containing a dog, a cat and a bike and throw those 3 unrelated classes to the same list and pass that list to StartRunning, and they will all "Start running".

List<ICanRun> runableThings = new List<ICanRun>(){new Dog(), new Cat(), new Bike()};
StartRunning(runableThings);

I hope this example helps