Comments on: Interfaces or Abstract Classes?

By: Jon

Jon — Wed, 03 Apr 2013 21:02:06 +0000

Java 1.8 , as part of the Lambda package, is going to allow what is called “Defender methods” capability, which allows you to have a default implmentation of a method completely defined in a interface definition, thereby enabling the inheritance of multiple interfaces without the requirement of having to define what those methods do unless you want to re-define them (different than a override).

By: Stephen S. Musoke

Stephen S. Musoke — Mon, 25 Feb 2013 14:04:36 +0000

Interfaces are a contract for behavior – any class that implements an interface must provide an implementation for the methods in the interface.

Abstract classes – form a basic building block with common behavior for a hierarchy of classes and can force child classes to enforce certain behavior

Interfaces are great for grouping related behavior and can be used across a complete codebase while Abstract classes are only good for behavior in a specific hierarchy of objects.

A good mix would be to define interfaces and have base Abstract classes for specific hierarchies

By: Evert

Evert — Fri, 22 Feb 2013 22:42:44 +0000

It could make sense, but you’ll find OOP and design pattern-purist mostly typing on interfaces at all time, because they are more flexible, and other reasons.

I’m not a purist though, I am a pragmatist and I try to use the best tool for the job..

I find in the project I work on (a relatively large and complex open source library, been at it for 6 years now) that slowly the places where I made a decision earlier to use (abstract-)classes as the base type, I’m shifting towards interfaces.

So generally I disagree, in most cases where I need to spend the most time on quality, durability and backwards compatibility (public, open source code basically), type is in 90% of the cases provided by some interface, and implementation by classes.

I feel very different about private code though, and maintain very different design goals for code where both the API and the consumer is controlled, for example within the same company. In those cases I try to work as ‘flat’ as possible, use inheritance sparingly and interfaces almost never. For private code I my primary goal is to write code that extremely easy to refactor, throw away or rewrite.

By: Paul

Paul — Fri, 22 Feb 2013 10:23:13 +0000

@Evert, I get your point. Yes, interfaces can define types, but from the client’s point of view. I like to see it like this: objects have a type that is purely defined by their class and their superclasses. If they fulfill some contract used by other objects, they can express this by implementing an interface. However, this does not change the object’s type, but states that the object _also_ acts as an implementation of the contract declared by that interface. Does that make sense to you?

Cheers,
Paul

By: Wayne

Wayne — Thu, 21 Feb 2013 18:57:18 +0000

This is a pretty good writeup. I did a comparison of Interfaces an Abstract Classes about a year ago. http://waynemay.com/interfaces-vs-abstract-classes-in-php/

By: Evert

Evert — Thu, 21 Feb 2013 15:47:05 +0000

I disagree that interfaces don’t provide ‘type’. I use that concept everywhere, and generally only force type based on interface. If I combine that with traits I can effectively achieve what multiple inheritance also provides. But I agree that it’s not _exactly_ the same thing on a language-level.

As with all of these abstract concepts it’s subjective though. To me, with the design problems I am facing, I can achieve a form of multiple inheritence, which is kinda where I’m coming from.

By: Anthony

Anthony — Thu, 21 Feb 2013 14:59:00 +0000

Evert,

Traits are not multiple inheritance. And neither are interfaces.

Inheritance requires the ability to overload methods. Traits do not provide that ability. Additionally, inheritance is also about typing, something that traits by very definition do not provide. Inheritance provides sub-type polymorphism. Traits have no mechanisms for that. Traits are nothing more (literally) than compiler-aided copy/paste. Inheritance is much more than just copy/paste.

Interfaces only provide a contract, they do not define a “type”. Therefore, interfaces do not provide sub-type polymorphism. They are very useful for providing polymorphic behavior, but they are a very different concept than inheritance.

It’s a very subtle difference mind you. In practice you can use traits and interfaces to simulate multiple inheritance. But it’s not multiple inheritance. And I think it’s very important to draw that distinction so that we communicate clearly. Traits have a very specific contract with the developer. They are not intended to provide polymorphism or typing. They are intended for static (compile-time) horizontal code re-use only.

My $0.02 at least…

By: Milan Popović

Milan Popović — Thu, 21 Feb 2013 14:42:55 +0000

Why don’t you want to define concrete methods in abstract classes?

By: Paul

Paul — Thu, 21 Feb 2013 13:57:08 +0000

I think that you can’t really compare interfaces with abstract classes since they have completely different meanings. An abstract class describes an abstract super-type – an interface only a set of methods that client objects might want to use. People should start using inheritance for sub-typing instead of for making functionality of other classes available in an object. This is what traits and composition are for…

By: Evert

Evert — Thu, 21 Feb 2013 13:08:51 +0000

I’d argue that traits + interfaces is a form of multiple inheritance.