Interfaces vs Abstract Classes

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
17,151
#1
After reading this again and again I think I have come to the conclusion that the guy who invented Interfaces must have sat down one day and thought to himself: "I know, I'll take this base class and the concept of Inheritance which seems to work just fine, and I'm just going to see how unnecessarily complicated I can make it just to piss everyone off.

I'm working through this book called Head First with C# on chapter 7. The more I read the more and more I am left just confused as to why Interfaces are even needed in the first place. Sigh.

http://stackoverflow.com/questions/6802573/c-sharp-interfaces-whats-the-point
 
Last edited:

Thor

Honorary Master
Joined
Jun 5, 2014
Messages
34,858
#4
Heck even I understand interfaces quite well.

I read a book a while back best damn piece of advise I have ever gotten it actually made me think differently now and a lot of this OOP stuff makes more sense now.

First and foremost, an object is a collection of capabilities. An object is defined by what it can do, not by how it does it — and the data is part of “how it does it.” In practical terms, this means that an object is defined by the messages it can receive and send; the methods that handle these messages comprise the object’s sole interface to the outer world.
 

Hamster

Resident Rodent
Joined
Aug 22, 2006
Messages
29,340
#5
If an interface is seen as complicated by you there are bigger problems. It's really a very simple concept.
 

Hamster

Resident Rodent
Joined
Aug 22, 2006
Messages
29,340
#6
The more I read the more and more I am left just confused as to why Interfaces are even needed in the first place. Sigh.
"Hey developer guy employed by me, we're going to integrate with a third party system. They'll only be reading for integration testing in three weeks though because they're substandard losers, hahahaha! Anyway, we need our part done, unit tested and ready by the time they are done do we can show them how awesome we are!"

What do you do, boy? What do you do?
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
6,571
#7
After reading this again and again I think I have come to the conclusion that the guy who invented Interfaces must have sat down one day and thought to himself: "I know, I'll take this base class and the concept of Inheritance which seems to work just fine, and I'm just going to see how unnecessarily complicated I can make it just to piss everyone off.

I'm working through this book called Head First with C# on chapter 7. The more I read the more and more I am left just confused as to why Interfaces are even needed in the first place. Sigh.

http://stackoverflow.com/questions/6802573/c-sharp-interfaces-whats-the-point
Thing is, a class can only extend a single abstract class but can implement multiple interfaces.
 

Hamster

Resident Rodent
Joined
Aug 22, 2006
Messages
29,340
#9
Thing is, a class can only extend a single abstract class but can implement multiple interfaces.
That's a C# limitation if I'm not mistaken. Personally I think inheritance should die and we should all just use composition.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
6,571
#10
Read up up dependency injection and interfaces will make more sense
I think that might confuse him more tbh. He's learning the basics and I think you need to understand interfaces to understand dependency injection.
 

adrianx

Expert Member
Joined
Jun 30, 2008
Messages
3,328
#14
This is a PHP example that helped me understand interfaces more.
Code:
<?php

interface Logger
{
    public function execute($message);
}


class DatabaseLogger implements Logger
{
    public function execute($message)
    {
        print "Logging to database: $message";
    }
}


class FileLogger implements Logger
{
    public function execute($message)
    {
        print "Logging to file: $message";
    }
}


class UserController
{
    protected $logger;

    public function __construct(Logger $logger)
    {
        $this->logger = $logger;
    }

    public function show()
    {
        $user = 'SomeUser';

        $this->logger->execute($user);
    }
}

$controller = new UserController(new DatabaseLogger);
$controller->show();
// output
// Logging to database: SomeUser

$controller = new UserController(new FileLogger);
$controller->show();
// output
// Logging to file: SomeUser
Notice how UserController doesn't care what kind of Logger it receives.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
6,571
#16
This is a PHP example that helped me understand interfaces more.
Code:
<?php

interface Logger
{
    public function execute($message);
}


class DatabaseLogger implements Logger
{
    public function execute($message)
    {
        print "Logging to database: $message";
    }
}


class FileLogger implements Logger
{
    public function execute($message)
    {
        print "Logging to file: $message";
    }
}


class UserController
{
    protected $logger;

    public function __construct(Logger $logger)
    {
        $this->logger = $logger;
    }

    public function show()
    {
        $user = 'SomeUser';

        $this->logger->execute($user);
    }
}

$controller = new UserController(new DatabaseLogger);
$controller->show();
// output
// Logging to database: SomeUser

$controller = new UserController(new FileLogger);
$controller->show();
// output
// Logging to file: SomeUser
Notice how UserController doesn't care what kind of Logger it receives.
This example doesn't really show the reason why one would use an interface rather than an abstract class (as per thread title) - the same thing could be achieved extending an abstract class
 

etienne_marais

Executive Member
Joined
Mar 16, 2008
Messages
6,426
#18
Heck even I understand interfaces quite well.

I read a book a while back best damn piece of advise I have ever gotten it actually made me think differently now and a lot of this OOP stuff makes more sense now.
First and foremost, an object is a collection of capabilities. An object is defined by what it can do, not by how it does it — and the data is part of “how it does it.” In practical terms, this means that an object is defined by the messages it can receive and send; the methods that handle these messages comprise the object’s sole interface to the outer world.
Although the quote you give probably refers to interfaces in general OOP terminology (thus a concept, also applicable to C++ which does not have actual interface constructs) as opposed to actual C#/Java interface structures, the principle applies: one must think of C#/Java interfaces (structures) as the interface (concept) defining the messages an implementing class will expose.

My take on this is that it (the difference between using abstract classes and interfaces in C#/Java) is indeed a bit vague from a technical stance (except for the technical differences of limited inheritance for example), but from a design and conceptual stance it reinforces the idea that you are defining the messages that a class will be / must be implementing.
 
Last edited:

etienne_marais

Executive Member
Joined
Mar 16, 2008
Messages
6,426
#19
Although the quote you give probably refers to interfaces in general OOP terminology (thus a concept, also applicable to C++ which does not have actual interface constructs) as opposed to actual C#/Java interface structures, the principle applies: one must think of C#/Java interfaces (structures) as the interface (concept) defining the messages an implementing class will expose.

My take on this is that it (the difference between using abstract classes and interfaces in C#/Java) is indeed a bit vague from a technical stance (except for the technical differences of limited inheritance for example), but from a design and conceptual stance it reinforces the idea that you are defining the messages that a class will be / must be implementing.
And of course, in C# an abstract class can define partial (or complete or none) implementation, if the bulk of implementation or perhaps core critical functionality will be common to inheriting classes then abstract classes are preferable.
 

adrianx

Expert Member
Joined
Jun 30, 2008
Messages
3,328
#20
This example doesn't really show the reason why one would use an interface rather than an abstract class (as per thread title) - the same thing could be achieved extending an abstract class
That's true and it can even be done without abstract classes. I could remove type hinting (in PHP) from the UserController constructor and it would still work.

DatabaseLogger and FileLogger would probably need to extend other classes in real life, but an interface (in this case) would ensure that those classes or their parents implement a method called execute.
 
Top