abstract base class or interface

[dragonwell]

I'm at the point where I've nearly completed a project whose core functionality revolves around an interface. It is becoming more and more apparent that in most cases it will only make sense to implement some of the methods in the interface, and just leave stubs for the remaining methods. This makes me almost wish that I had used an abstract base class instead, with default behaviors (that do nothing) for the methods, so that concrete classes do not have to implement them.

So I would like to know if anyone has experience with this issue as to whether it will pay off in the long run to keep the interface, or will converting to an abstract base class now save me headaches in the future.

Thanks

 

[jby1]

An interface is good, as it provides a clear statement of what is behaviour is expected from any class that implements it, free from any details of implementation. However, I have also found that often there is a lot of shared functionality between the concrete classes. What I do in these kinds of cases is to implement the interface in a base class, and then extend this base class in the concrete classes. This keeps the notion of the contract in the interface, while allowing code sharing easily. Using this set-up, it is easy to implement default behaviours for methods, and also to mark methods as virtual functions when there is no default implementation.

I would appreciate any comments on this way of doing things.

 

[stevexff]

In languages without multiple inheritance, interfaces often provide a way to simulate this.

But jby1's solution is neat. Java supplies some adapter classes that do just this - implement do-nothing methods that ensure that the interface contract is honoured by any class that inherits from them. So you only have to override any methods that you actually need.

 

[dragonwell]

Cool idea - adapter class...

I suppose I could do both - inherit from the base class (which implments the actual interface), but the client code only knows about the interface. That way I can do either in future implementations. cool.

Thanks

 

[globos]

An interface is good, as it provides a clear statement of what behaviour is expected (...)

implement do-nothing methods that ensure that the interface contract is honoured by any class that inherits from them

Stricto sensu, a Java interface does not state any behaviour, it justs expose a list of deferred routines and constants, that's all. Maybe jby1 meant another idea behind behaviour. What did you mean by 'behaviour'?
Again in pure Java, an interface does not state any contracts in terms of DBC like stevexff suggested. You can't formally define the pre and post conditions of the routines of an interface.
So there is no constraints to satisfy for implementation classes, apart the prototype of the routines.

That's why I tend to think that most of the time Java interfaces leads to over abstracting and implementation labour. What Java interfaces do really bring?
In Java, jou have to deal with it if your OO model makes use of multiple inheritance.

Last, sorry if I'm haggling, "adapter" classes, as used in the Java gobbledygook, is not a well-fitted name. Adapting is modifying something to make it compatible with another thing.
But it is some kind of the official designation. "DefaultImpl" or "NopImpl" would maybe be better, but longer.

--
Globos

 

[jby1]

Quite right Globos, an interface doesn't say anything about the behaviour, it is merely a statement of which methods must be implemented and what their signatures must be.

I apologise for my incorrect use of vocabulary!

I was going to go on about why I think interfaces are useful, but have just scrolled up and saw that dragonwell said what I was going to say, and in far fewer words as well!

(I am doing this in C#, but have used Java in the past)

 

[stevexff]

Interfaces also give you a way to abstract classes from different inheritance hierarchies, to allow you to treat them as if they all belonged to the same superclass (within the constraints of the interface, of course).

I don't think you can make a firm rule about when or how to use them, as any programming standards that are perfect in one situation may be clunky and over-engineered for another. It's probably easier to think of situations when they should not be used! I guess you have to treat abstract classes, interfaces, and even adapters[sup]1[/sup] as a set of tools in your designer's toolbox, and use them when the need arises.

[sup]1[/sup]insert preferred name here...