Java – Are Empty Interfaces Bad Programming Practice?

code smellinterfacesjavaobject-oriented-design

I'm designing an architecture in which I have:

public interface IObjectReader{
    public Object read();
}

public class ConcreteObjectReader implements IObjectReader{
     @Override
     public Object read(){
         //do stuff
         return new Object();
     }
}

Now, if I want to allow a reader to be parameterized, I could create another interface this way:

public interface IParameterizedObjectReader extends IObjectReader {
    public void setParams(Map<String,String> params);
    public Map<String,String> getParams();
}

To me this is reasonable. However, in my project I have also object writers, object processors and so on, and they also need to be, eventually, parameterized.
In this scenario, having two or more interfaces that define the same contract (getParams and setParams) is a very bad idea to me. So I would define an interface IParameter like this:

public interface IParameter{
    public void setParams(Map<String,String> params);
    public Map<String, String> getParams();
}

and I'd make the IParametereziedObjectReader interface (similar for IParameterizedObjectWriter, etc) extend IParameter too, but I'd leave it empty.

Is this a bad idea? Or maybe I should leave only the IParameter interface and delete its subinterfaces?
For clarity I have to say that I don't use these Parameterized interfaces as markers anywhere in my code, so they'd be empty just for an architectural reason.

How would you design this solution differently?

Best Answer

Are empty interfaces (but not marker interfaces) a bad programming practice?

Generally, yes. By definition, empty interfaces provide you nothing. They can be marker interfaces (generally evil), or aliases for another type (occasionally useful due to legacy code when renaming something). But in a greenfield project like this they're just over-engineering and YAGNI.

How would you design this solution differently?

Without knowing more about your requirements, I can't say. But trying to make arbitrary read/write/process, with arbitrary number/shape of parameters is a fool's errand. Systems that can "do anything" aren't providing any useful abstraction over just writing code, and tend to be nightmares to implement and maintain. If you want a scripting language, go use a scripting language.

Related Solutions

Should a String Constant Be Defined if Used Only Once?

Try this. The initial reflection is certainly expensive, but if you're going to use it many many times, which I think you will, this is most certainly a better solution what what you're proposing. I don't like using reflection, but I find myself using it when I don't like the alternative to reflection. I do think that this will save your team a lot of headache, but you must pass the name of the method (in lowercase).

In other words, rather than pass "name", you would pass "fullname" because the name of the get method is "getFullName()".

Map<String, Method> methodMapping = null;

public Object getNode(String name) {
    Map<String, Method> methods = getMethodMapping(contact.getClass());
    return methods.get(name).invoke(contact);
}

public Map<String, Method> getMethodMapping(Class<?> contact) {
    if(methodMapping == null) {
        Map<String, Method> mapping = new HashMap<String, Method>();
        Method[] methods = contact.getDeclaredMethods();
        for(Method method : methods) {
            if(method.getParameterTypes().length() == 0) {
                if(method.getName().startsWith("get")) {
                    mapping.put(method.getName().substring(3).toLower(), method);
                } else if (method.getName().startsWith("is"))) {
                    mapping.put(method.getName().substring(2).toLower(), method);
                }
            }
        }
        methodMapping = mapping;
    }
    return methodMapping;
}

If you need to access data contained within members of contact, you might consider building a wrapper class for contact which has all methods to access any information required. This would also be useful for guaranteeing that the names of the access fields will always remain the same (I.e. if wrapper class has getFullName() and you call with fullname, it will always work even if contact's getFullName() has been renamed -- it would cause compilation error before it would let you do that).

public class ContactWrapper {
    private Contact contact;

    public ContactWrapper(Contact contact) {
        this.contact = contact;
    }

    public String getFullName() {
        return contact.getFullName();
    }
    ...
}

This solution has saved me several times, namely when I wanted to have a single data representation to use in jsf datatables and when that data needed to be exported into a report using jasper (which doesn't handle complicated object accessors well in my experience).

Java – How to handle a set of differing event classes with differing handler interfaces in a single event processor

Visitor Pattern

It won't help here. The best scenario to adopt Visitor Pattern is you have a fixed number of subclasses. However, in your example, you could have a lot of Event in the future. So, if you choose to use Visitor Pattern, every time you add a new kind of Event, you have to modify the Visitor. It's a nightmare.

Reflection

It's the right way to go. You have to sacrifice type safety for more dynamic dispatching. But, we can do something to improve the safety.

Guava EventBus use reflection and annotation to provide both compiling and runtime safety. You can check the implementation if you are interested. In summary, it sacrifice a little safety(you may have an event which doesn't have corresponding handler, which I think is reasonable, but may not for your case), but what you gain is more clean and maintainable code.