Interfaces vs Abstract Classes

Yeah, thats right lets bash them because we don't understand their use. Always a good approach.
 
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.
Click to expand...
 
If an interface is seen as complicated by you there are bigger problems. It's really a very simple concept.
 
Solarion said:
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.
Click to expand...

"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?
 
Solarion said:
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
Click to expand...

Thing is, a class can only extend a single abstract class but can implement multiple interfaces.
 
Read up up dependency injection and interfaces will make more sense
 
C4Cat said:
Thing is, a class can only extend a single abstract class but can implement multiple interfaces.
Click to expand...
That's a C# limitation if I'm not mistaken. Personally I think inheritance should die and we should all just use composition.
 
skimread said:
Read up up dependency injection and interfaces will make more sense
Click to expand...

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.
 
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.
 
adrianx said:
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.
Click to expand...

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
 
Java supports faux multiple inheritance via default methods
 
Thor187 said:
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.
Click to expand...

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.
Click to expand...

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 said:
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.
Click to expand...

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.
 
C4Cat said:
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
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X