An Exact Interface

Last updated on 2012-12-11

A lot of thought is invested in creating Object Oriented programs, specially when creating their models. We want to have a simple yet powerful model, where objects can act in many different ways (polymorphism), some of them which have a fairly common implementation that can be reused all over the class hierarchy. To achieve this goal we (programmers) create either very explicit abstract base classes or interfaces. But it also shows that we are lazy.
For example, the org.eclipse.draw2d.IFigure. It has 109 methods (yes, I counted them), most of them surely useful for a generic figure like containsPoint or getBackgroundColor, but at some point things started to get out of hand with the addition of setFont (do all figures have a font?) or erase (does someone know what the implementation in Figure does?). Even worse, someone decided to add this to the interface: internalGetEventDispatcher with a strong remark that this method should not be called (the why is it in the interface???). Furthermore we have property listeners, mouse listeners, focus listeners and all of the gang.
So what is my problem, you are probably asking? Thing is that I am having the same problem in the small model that I am creating for my OPM editor. I have a OPMNode which defines a connectible element in the diagram, and inheriting from it I have OPMThing, OPMState and OPMStructuralLinkAggregator which all share the connectible property, but at the same time their connections behave differently – a OPMStructuralLinkAggregator can only connect using primitive OPMLink connections while the others can connect more freely. Furthermore, I would like to have helper methods in my model to find (for example) all outgoing structural links of a specific kind, in a specific OPMNode… but wait! this method would be irrelevant for the aggregator node!
So what could be the solution? there are a number of possible solutions, starting with ignoring the small voice in my head and just adding the method to the OPMNode. Another thing that I could do is add another step in the hierarchy between OPMNode and OPMThing/OPMState and implement this method here. But add another class just for a small number of methods (I don’t like large hierarchies)? We could also implement this using multiple interfaces and casting to the correct interface when needed.
I’m not sure that there is a correct answer to this problem… for now I will simply ignore the voices in my head until either things get really ugly or the app is completed (many people call this way of thinking “agility”).
BTW, does is a Circle a Point? many people think that way. Even worse, someone taught that Rectangle extends Point! Preposterous.