Abstract Classes vs Interfaces

[Steven Schveighoffer]

On Thu, 08 Jul 2010 07:59:08 -0400, Ary Borenszweig <ary at esperanto.org.ar>  
wrote:

> On 07/07/2010 06:24 PM, Justin Johansson wrote:
>> Currently I'm struggling with unifying some C++ and Java code with
>> the idea that I might eventually port it to D2.
>>
>> C++ people will know that their language supports abstract classes
>> and multiple inheritance but not interfaces per se (although they
>> can be hacked as abstract classes with implicit/trivial constructors).
>>
>> Java people will know that their language also supports abstract
>> classes and interfaces though not multiple inheritance.
>>
>> In respect of the support of abstract classes, multiple inheritance
>> and interfaces, both D1 and D2 are closer to Java than C++.
>>
>> May I please ask of this group their opinions as to the difference
>> between abstract classes and interfaces from an axiomatic viewpoint.
>>
>> Is there a difference axiomatically, semantically or otherwise?
>>
>> Thanks in advance for all comments,
>>
>> Justin Johansson
>
> Basically an interface is a contract: if a class implement that  
> interface then it provides all the methods described in the interface.
>
> An abstract class just serves building common functionality for a set of  
> classes that will inherit from it. If an abstract class provides no  
> functionality at all then it might well be think of as an interface (it  
> should be replaced by an interface.)
>
>  From the other reply it seems that interfaces in D can have  
> final/static methods. That kind of goes against what I just said about  
> interfaces...

Not really, the class still does implement the required functions.  It's  
just that when some functions *always* are the same, then a final method  
makes it easier to maintain that one method.

In java/C# you have this awkward construct:

interface I
{
    int foo(int x);
    int bar();

    // Note, implementing classes should *always* implement this as  
foo(bar());
    int foo();
}

Whereas in D, you have:

interface I
{
    int foo(int x);
    int bar();

    final int foo() { return foo(bar()); }
}

Much more elegant if you ask me...

And to clarify, the difference between an abstract class and an interface  
is not so much the function implementation, it's that an abstract class  
can have data members and an interface cannot.  The difficulty in  
implementing multiple inheritance is directly related to data members.   
The problem is, class inheritance is based on the axiom that a pointer to  
the base class is the same as a pointer to the derived class.  This allows  
all kinds of cool things to work with very little performance problems.   
However, if you have two base classes, then you have two *different* base  
class pointers, since the pointer to the base class must look like a  
pointer to an instance of the base class when calling the base class'  
methods.  This means casts to base classes involve changing pointers, and  
you can't simply call base functions without adding some sort of offset.   
It also makes casting to derived classes much more complex and error  
prone.  It also introduces the diamond problem (where you inherit from two  
base classes that themselves have the same base class, giving you two  
copies of the lower base class) and the horrible solution, virtual  
inheritance.

Also, multiple inheritance can be done, quite easily in D, with the new  
alias this construct.  It exposes some of the ugliness of multiple  
inheritance, but I think that's to the programmer's benefit.

-Steve