Ashish Jain Blog

What is a Java Interface

From java.sun.com

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a “contract” that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group’s code is written. Generally speaking, interfaces are such contracts.

In this blog,  I am trying to present very common design pattern in projects, which I kind of don’t agree with.

This pattern is to define Interface for all data beans and value beans.  In most of the projects, I have worked in past (and current one too), I have observed, Architects have defined interface for any kind of bean flowing between layers of software.

For example  ‘Person’ and associated ‘Address’ bean.  So, there will be a Person interface and an Address interface. And there will be ‘PersonImpl’ and ‘AddressImpl’ object implementing respective interfaces.  Now Person interface has common getters and setters for properties like name, age, height and Address interface has getters & setters for addressLine1, addressLine2, city, zipcode, country etc.  So we can imagine implementing classes have defined class variables for corresponding each getter and setter. Now big question comes to mind, Why we have defined interface for this object? Why not to keep single class Person having getter/setter and it’s class variables.

Common Reasons (and why I think, they are wrong)

1. It can have multiple, different implementations. As I have heard from architects, they just want to expose interface to integrating layers/client. And if later on, we change implementation, it won’t visible or require any code change on their side. Well, why we will have different implementations, in first place? These beans have getter and setter of certain property. How come you can have different implementation?
2. We want integrating client to write their own implementation. Again, why? It’s simple data bean carrying data around. I think, this is another example of ‘abuse’ of interfaces by architects who are following more of text books version, instead of thinking out of box. Interfaces are contracts of expected behavior of operations, not data beans. Data beans doesn’t have behavior, they are mere payload objects. If they are more than payload, then I would put your design in question.
3. To support legacy objects. Argument is, their legacy code of databeans have behavior. Now to bridge to new version of software, they need to use interfaces for databeans. Hence they provide bridged data beans implementing new data beans. And later on, when they move away from legacy, we will just use new implementation of interface. This is clear sign of ‘design’ smell. If you want to bridge to legacy code, then use bridge services objects. Bridged services will take care of handling legacy operations on legacy bean. Your new beans shouldn’t have any kind of behavior, encapsulating or hiding legacy smell. That was main reason to start new project, right?
4. So that, we can have multiple inheritance. If your data bean’s getters/setters are not suppose to have different kind of implementation, hence why different objects will implement same implementation. Those different objects rather extend common super implementing class.
5. (write in comments, I will add here)

Problems I have faced and I hate it

• Whenever I need to add/remove any property, first you will have to fix interface. Hence doubling my effort in refactoring.
• If same interface is implemented somewhere else, then changing interface (in prev step), I will have to change all other classes too. Question comes, why other implementing class, just simple extends original class.  They all are data beans,  no behavior.

Only behavior, data beans/value beans (must) contain, implementing equals() and hashCode() methods.  Well, we get those as part of Object class. Another possible ‘operations’ can from other interfaces like ‘Comparable’ or ‘Serializable’. If you get gist of it, none of  interfaces defined operations as accessors for properties.

In end, I am trying to advocate, to keep java programming simple and productive. Yes, we can boost of designing complex mutli-layered system, but at the cost of productivity and maintainability. Lets keep any kind of operability or logic in business classes.  Any logic or code in data beans, is destined for future refactoring some time.