Why Interfaces are better than Abstract classes

I have recently begun to understand where a lot of the books/articles/blogs I have read recommend Java programmers to use Interfaces and composition and this has come about because recently I have been using a interfaces a lot more. I noticed this has been a definitive change because before I used to always think of using Abstract classes.

I think as you progress as a developer you move away from using inheritance and then start to favour composition. I think the key area of this change is you start to understand the benefit of interfaces and abstract classes and through practice you get better and using them.

I initially could never understand the point of interfaces, the idea of them seemed like extra work. You have to create an interface which has no code in, except some empty methods. I used to think why would I want to do that when I can create an Abstract class with some methods which have code and then all the classes can extend that and get some code for free. This would mean I have to write less code. Interfaces use to seem like a terrible idea, every class that implements it has to write all the code again for each class that implements an interface.

I have discussed before Interfaces Vs Abstract Classes I have also blogged about why you should use interfaces and abstract classes, I didn't really write that much but I linked to a good article http://hoskinator.blogspot.com/2006/05/interfaces-and-abstract-classes-dont.html

I have moved away from using abstract classes as much because I am using interfaces more and the way I am using Interfaces more. Recently I have been using Interfaces to hide change behind. If there is a piece of code which has an algorithm or recently I was writing some code which checked a directory for a file. I was able to use an Interface and check for a certain file. The interface I created had two methods, one method to check the directory and one to perform an action if it found something. By using an interface I was able to write the code to resolve the problem I was trying to fix but also hide the change behind the interface. If later I need to search for a different file or search for files I can make another class that implements the interface and change the method to check the directory and the action and the rest of the code will work just fine. Here is the blog entry if you would like to read about it in more detail

http://hoskinator.blogspot.com/2006/06/function-pointers-in-java.html

I think the change from using Interfaces from Abstract is the change in thought. I have been thinking about trying to write simple code and nothing extra but also where change might come in the future. If I think the code might change, I bash a interface in allowed a developer in the future to add a different implementation behind the interface but without effecting other parts of the code.

I suppose what I am trying to say is that Interfaces allow you to use polymorphism and benefits that associated with it.

What other benefits are there, well I think interfaces encourage Single_responsibility_principle
in your code because you can make interfaces for smaller tasks. When you use abstract classes they often start off this way but then as you extend them with different flavours the classes seem to start growing and sometimes you need to alter the super class and slowly the code seems get harder to maintain and extend. I think abstract classes and the concrete classes which inherit from them do become more difficult to maintain is the different extending classes start to change the focus of the class and they become less cohesive.

One other weakness I find with inheritance and abstract classes is that any methods you want to overridden or to be able to use you have to make public. Although there is no reason why you don't use the extended class with composition but for some reason I don't. With inheritance and the blog about function pointers I pass in the interface. I like this use of interfaces as instance variable, this is where interfaces are really powerful and useful you can use them as a set of behaviors inside a class. The real advantage is classes using the class which contains the interface rather implements it, don't even know there is a interface being used.

Another weakness of Abstract classes is that you can extend any other classes.

Increased dependency. Abstract classes by their very nature create a fundamental dependency with the subclass and the superclass.

Interfaces seem more comfortable when making an interface with just one or two methods. It seems easier to create a small interface and the interfaces I write seem to be a lot more cohesive and focused on one particular task/behavior. The Benefit of small concrete classes is they are not coupled with other code and have few dependencies. This means it's easier to use the concrete class implementing the interface in other parts of the code.

There are situations when Abstract classes are useful and the right choice, they do have advantages that each class can inherit some general methods used by all extended classes. It's just in my experience recently Abstract classes seem a lot harder to maintain and extend, especially with the more classes that extend the Abstract superclass.

I don't know what other people think about this but it seems to me that after starting off using Abstract classes you get a bit more savvy and then start to use Interfaces a bit more and composition. Interfaces seem to make it easier to write code that cohesive and focused on one thing, this has the result of making the code easier to extend, maintain and unit test before another class implements the interface or uses it like an instance variable