When would you use abstract classes over interfaces

Discussion in 'Java' started by sasha, Jul 29, 2008.

  1. sasha

    sasha Guest

    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
    sasha, Jul 29, 2008
    #1
    1. Advertising

  2. On 29/07/2008 03:30, sasha allegedly wrote:
    > 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.

    --
    DF.
    Daniele Futtorovic, Jul 29, 2008
    #2
    1. Advertising

  3. sasha

    Tom Anderson Guest

    On Mon, 28 Jul 2008, sasha wrote:

    > 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

    --
    The glass is twice as big as it needs to be.
    Tom Anderson, Jul 29, 2008
    #3
  4. sasha

    Mark Space Guest

    Daniele Futtorovic wrote:

    > On 29/07/2008 03:30, sasha allegedly wrote:
    >> When would you use abstract classes over interfaces


    >
    > 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.
    Mark Space, Jul 29, 2008
    #4
  5. sasha

    Daniel Pitts Guest

    Daniele Futtorovic wrote:
    > On 29/07/2008 03:30, sasha allegedly wrote:
    >> 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.
    >

    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...



    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Jul 30, 2008
    #5
  6. sasha

    Andy Dingley Guest

    On 29 Jul, 02:56, Lew <com.lewscanon@lew> wrote:
    > 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.
    Andy Dingley, Jul 30, 2008
    #6
  7. sasha

    Tom Anderson Guest

    On Wed, 30 Jul 2008, Lew wrote:

    > Andy Dingley wrote:
    >> On 29 Jul, 02:56, Lew <com.lewscanon@lew> wrote:
    >>> 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.

    >
    > 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

    --
    10 PARTY : GOTO 10
    Tom Anderson, Jul 30, 2008
    #7
  8. sasha

    thusa12

    Joined:
    Aug 5, 2008
    Messages:
    3
    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.
    thusa12, Aug 5, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rhino
    Replies:
    32
    Views:
    1,240
    Thomas Hawtin
    Feb 11, 2006
  2. Replies:
    11
    Views:
    682
    Chris Uppal
    May 26, 2006
  3. Replies:
    2
    Views:
    295
    Mike Schilling
    Oct 11, 2006
  4. Replies:
    0
    Views:
    1,092
  5. puzzlecracker
    Replies:
    0
    Views:
    227
    puzzlecracker
    Jul 29, 2008
Loading...

Share This Page