[Developers] The 'philosophy' interface changes

[Bert Bril]

Hi all,


One of the complaints we get from time to time, is that the interfaces 
change between minor releases. Quite a bit. Too much.

Indeed, we do change interfaces. We understand that this may be 
inconvenient. But we think the alternative is worse.

There are many examples of tools and frameworks that keep their 
interfaces constant over a long period of time. This can be a very good 
thing, not in the least for the developers programming against the 
interface.

The flip side of this approach is a mismatch between 'actual' and 
'desired' interface that starts as soon as the first release comes out.

In OpendTect we work, very much, Agile. This also means constant re-work 
of, basically, everything. What you will see in such a system is that 
fundamental interfaces change less and less, but more specific 
interfaces keep changing a lot to accommodate the latest developments.

To counter the impact of interface changes, an option is to use design 
tricks. A very common one is to use something sometimes called the 
'envelope/letter' or 'Cheshire cat' pattern (basically, the interface 
holds only a pointer to an implementation class). This is used in COIN, 
for example. It can be very effective if binary compatibility is 
essential. The flip side is extra indirection, maintenance, and less 
understandability.


All in all, we have chosen to do nothing limiting interface changes 
other than the amount of work required within OpendTect. That by itself 
is already enough to stop one from changing, say, BufferStringSet::get() 
to BufferStringSet::getElement(). Still, if at some point in time this 
may be a topic, we try to err on the side of change! The last thing we 
want is mummified services that do not longer reflect the intention of 
the class, just to avoid breaking interfaces.


So that's why we do it. You thought it was personal. But it's not.


"Agile development costs. And right here is where you start paying. In 
sweat." [from the TV series 'Fame', adapted].


/Bert

-- 
-- Bert Bril / OpendTect developer at dGB
-- mailto:Bert.Bril at opendtect.org , http://opendtect.org