Reasons not to use abstract class instead of interface?

Question

I'm considering using an abstract class with all abstract members instead of an interface in order to avoid explicit interface implementation boiler-plate code. So instead of

type IMyInterface =
    abstract Name : string
    abstract Text : string

type MyClass() =
    member __.Name = "name"
    member __.Text = "text"
    interface IMyInterface with
        member this.Name = this.Name
        member this.Text = this.Text

I'd have

[<AbstractClass>]
type MyAbstractClass() =
    abstract Name : string
    abstract Text : string

type MyClass() = 
    inherit MyAbstractClass()
    override __.Name = "name"
    override __.Text = "text"

Any words of caution or implications I should be aware of here?

Answer 1

Only thing that you should be aware and make a conscious decision is a class can inherit from only one class but implement many interfaces.

---

Apart from that, some recommendations on using Abstract classes or Interfaces:

• If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
• If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
• If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
• If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

http://msdn.microsoft.com/en-us/library/scsyfw1d%28vs.71%29.aspx

Personally, I feel these recommendations are spot on. Especially Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface. is a very important point.

Answer 2

Stephen,

Only one, the most basic, and obvious... An interface allows for alternate implementations; if the "published well know type" is an abstract class you cannot later provide any alternatives... So the downside is you're limiting your future options; the upside is that (depending in how many inheritors there are) you could save a lot of boiler plate code.

If you're really really sure there ARE no other valid implementations then go the abstract class. If not then stick to the interface.

And I suppose you COULD do both... and I guess that'd give you most-of-the-best of both worlds.

Cheers. Keith.

PS: manojlds is right, of course ... and soooo much more sucinct ;-)

Answer 3

In abstract class, you can implement some common behavior of all the sub classes.

In your interface design, you may want to have a method call other method to accomplish some compound task. For instance, predictAll(Instance array) may use predictSingle(Instance) and provides a default implementation for all sub classes. If you use interface, you need to implement predictAll in all subclasses.

But this point is not a big deal as the multiple inheritance one. I prefer interface more than abstract class.

Interface also keeps your design sallow.

One more point: Interface encourages more functional code than abstract class. Typeclass in Haskell is a more powerful Interface.