When would you use abstract classes over interfaces

[sasha]

I am talking about in practice, when writing production code? I still
think the only good point about abstract classes is ability to add
some implementation.


thanks

 

[Daniele Futtorovic]

I am talking about in practice, when writing production code? I still
think the only good point about abstract classes is ability to add
some implementation.

When would you use abstract classes over interfaces

Hardly ever. If anything, use both.

 

[Tom Anderson]

I am talking about in practice, when writing production code? I still
think the only good point about abstract classes is ability to add some
implementation.

The main reason, as others have said, is to provide a partial
implementation. Even a majority implementation: rather than being a
mostly-abstract class with a few concrete methods, you sometimes have
classes with loads of concrete methods, and one or two key abstract ones.
A good example would be java.util.AbstractMap, which has just one abstract
method, entrySet(), and has implementations for all the other Map methods
which are built on top of that. That's also an example of the pattern
others have mentioned where you have a contract-defining interface, like
Map, backed up by an abstract base class, AbstractMap. You program to the
interface, and the base class is just there as a convenience for
implementations

However, i also like to use abstract classes in another situation: where i
want to communicate that a set of classes are part of a tightly-coupled
family. For example, if i was writing an XML processing library (one less
complicated than the W3C DOM, that is), rather than making Node an
interface and then having Element, Attribute etc be implementing classes,
i think i'd make Node an abstract class, even if it didn't have any
concrete methods which could be inherited by the children. This is a
matter of aesthetics and personal taste, though - i'm sure other people
would object to this.

tom

 

[Mark Space]

Hardly ever. If anything, use both.

I'll agree with this. Check out the way Lists are done in the
Collections API. First, there's a List interface. Second, there's an
AbstractList, which is intended to allow a programmer to create a list
object by inheritance by overriding only a few methods.

new AbstractList<Integer>() {
public Integer get(int i) {};
public Integer set(int i, Integer val ) {};
public int size() {};
}

You only need to override three methods to make a new List, thanks to
AbstractList. The list interface has many more methods, but
AbstractList handles them for you. That's a big convenience in an API
designed for extension by inheritance.

So the pattern here is to use abstract classes in addition to
interfaces. The interface is kind of the primary specifier of a class's
contract, and the abstract class is a helper to make the programmer's
job easier.

 

[Daniel Pitts]

Hardly ever. If anything, use both.

Abstract classes should be used to allow "borrowing" implementation. In
most situations any public method on an abstract class should be
implementing a method from an interface. All other methods should be
private or protected.

Even if I don't start a design that way, I usually end up refactoring to
have both

First iteration:
public class MyFoo...

Second Iteration
public class AbstractMyFoo...
public class MyFooA extends AbstractMyFoo...
public class MyFooB extends AbstractMyFoo...

Third Iteration:
public interface Foo...
public class AbstractSimpleFoo implements Foo...
public class MyFooA extends AbstractSimpleFoo...
public class MyFooB extends AbstractSimpleFoo...
public class MyFooC extends SomeBar implements Foo...

 

[Andy Dingley]

An abstract class
* may have implementation.

So what's an abstract class for? If you want an interface, use an
interface; if you want to attach implementation, consider an abstract
class.

Both of these are viable approaches, but they're not exclusive (as is
too often thought). There's nothing that says "If you want an
interface with a bit of implementation too, then use an abstract class
_instead_of_ an interface".

If you are in this case, consider using _both_ instead. Define the
interface with an interface (that's what they're good for) and then
write an abstract class that implements this interface and attaches
the implementation that you need.

 

[Tom Anderson]

This approach is good, because it takes into account that an abstract
class is the root of a singly-rooted hierarchy.

It's also potentially overengineering, though. If you don't need the
flexibility that this pattern gives you, just use an abstract class. If
you later find that you do need it, refactor. Doing this right from the
outset makes my YAGNI sense tingle.

tom

 

[thusa12]

In a design, having interfaces at the top would be really good as you are only dealing using contracts rather than focusing on implementation details. When you consider on implementation specific details, you'll end up in changing the methods.

After defining the contracts with interfaces, you may decide whether to write abstract classes or concrete classes depending on the situations. If some parts of the implementations be shared with different classes that implement an interface, but need more specific classes to implement the complete requirements; there you go for an abstract class + some concrete classes extending that abstract.