The costs and benefits of interfaces

Craig Chapman’s blog … a new article posted :

Actually, Craig Chapman’s blog, not Jason (they’re unrelated despite the name and Delphi involvement). :crazy_face:

1 Like

Thanks @ianbarker … uk meeting was only a few days ago, and I am a bear of little brain. :slight_smile:

I have been using Delphi for almost 30 years now, I have come across many styles of programming. From a mere maintenance of code point of view, interfaces have caused me to lose much hair. Having maintained many systems written in Delphi, it is the hardest thing to find out where the code is going when interfaces are used. The code just calls a method and is up to black magic where that actual method is implemented. I really wish those who love interfaces would understand the incredible pain they put a maintenance programmer through, especially on mature products with millions of lines of code.

1 Like

Can you expand on what the issue is fundamentally related to?

I mean, the point of an interface is to present behaviour where the implementation is irrelevant to the rest of the code … so I can imagine :

  • maybe the interfaced code is not acting in a pure manner ?

  • maybe the calling code is not properly independent of the interfaced code ?

  • maybe it is lifetime related because Delphi conflates automatic lifetime with implementation hiding ?

  • or maybe it’s that grokking interfaces is tougher than “less technical” data types, and that affects usage ?

Paul, are you talking to me? I thought I was clear, it is with regards to tracing where the implementation code is, at any particular point in time, to track down the code that needs maintenance.

I’m just curious … what kind of maintenance ?

Do you mean as in altering the ‘contract’ of the interface … ?

Or eg like having to use a different online payment company, but keeping the same interface ?

Mostly the maintenance is not in the actual interface code, but in the implementation code. The trick when a product depends on interface technology. The coder has to find what implementation code is being executed. In my last major product I maintained, a lot of time was spent trying to find the actual implementation code that needs modifying.

1 Like

Finding the implementation of an interface is not that difficult - but it is more difficult than it should be - that’s a limitation of the Delphi IDE, not of interfaces as such.

FWIW I use gexperts grep tool which is faster than the IDE’s built in search. I don’t find it so onerous that I would avoid what I consider to be an essential language feature.

As for the the performance issues, yes don’t use them in tight loops where peformance matters, but for the most part the peformance really isn’t an issue.

I use interfaces extensively and I have also profiled my application extensively and the biggest performance issue is code that goes to the memory manager a lot.

I rewrote my parser/ast framework (not public, part of FinalBuilder) using records rather than interfaces for the tokens and got a massive performance boost (I forget the exact number, but somewhere around 60% faster) - not easy to get those sorts of gains on a 20yr old code base that has been heavily optimised. Using vTune I was able to prove that the perf incease was from avoiding calling int othe memory manager.

We have had many discussions here over the years about the benefits etc of interfaces.