Tag Archives: style

The Fine Thread between Being a Good Researcher and a Good Programmer

My “day job” is studying a PhD in Information Systems Management, where I am investigating the executable aspects of OPM (the Object-Process Methodology). While doing this I am also developing an open source tool where I am able to create OPM diagrams, and my plans are to use this tool as the interpreter of the OPM modeling language that I am creating (OPP – Object Process Programming).

As a researcher, how the code looks, how much it is tested, patterns, style, etc.. is of no matter to me. What matters is the result: can I prove using the tool that OPP is really a visual programming language which can be executed? On the other hand, as a programmer, all of this things are of interest to me. Writing “good” code is something that must be done always. Writing unit tests should not be optional. The code should be documented. But these two views are in constant battle because of the limited time in the world. If I want to advance faster in my research, I must write “ugly” code, because writing good code takes more time, no matter how good you are. Documentation takes time, writing unit tests take time.

So I am walking this fine line, on the hopes that I will have enough time to create good enough code so that at least complete strangers who download it will be able to read it. And if you are one of these strangers, please forgive me if I didn’t manage to do the job right.

An Exact Interface

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.