A response to https://dzone.com/articles/is-your-code-too-concrete, where Edmund Kirwan hypothesizes that using interfaces delays the onset of Mud.
A few observations:
* Any well-factored system will have more direct dependencies than methods. More methods than direct dependencies indicates that code re-use is very low.
* For any well-structured system, the relationship between direct dependencies and indirect dependencies will be linear, not exponential. The buttons and string experimental result is not surprising, but would only apply to software systems where people really do create interconnections at random. The whole purpose of modular program structure is explicitly to prevent this.
* Abstract interfaces are in no way a necessary condition for modular programming.
* Finally, the notion that interfaces act as a termination point for dependencies seems a little odd. An interface merely represents a point at which a dependency chain becomes potentially undiscoverable by static analysis. Unquestionably the dependencies are still there, otherwise your call to that method at runtime wouldn’t do anything.
So I suspect that what Edmund has discovered is a correlation between the use of interfaces and modular program structure. But that is just a correlation. A few years back there was an unfortunate vogue for creating an interface for each and every class, a practice which turned out to be entirely compatible with a Big Ball of Mud architecture. The button and string experiment provides an interesting support for modular programming, but I don’t know that it says much about interfaces.
Looking at this statement:
“Program to an interface, not an implementation”
Changing it to this:
“Program to a contract, not an implementation”
That is something I can live with and work by.
I agree that abstract interfaces are not needed, and would take that a step farther. The hardest code to reverse engineer for me is always anything that uses implicit invocation in its many forms, be it an abstract factory, or whatever. With that in mind, I would change his second rule to:
“Avoid implicit invocation as much as possible”.
I find that most forms of implicit invocation make me fee very smart and programmer-y at the time I write the code, but near homicidal a year later when I come back to that code. That triple evaluation loop, that abstract factory, they felt very clever when I wrote them. Not so much later. Favoring write-time over read-later-time ends badly for me.
Hi Jamie,
Since you responded so thoughtfully to Edmund’s article, I was wondering if you’d also like to accept an invitation to the Most Valuable Bloggers program. Send me an email and let me know if you’d like me to induct you into the program!
Pingback: Do Interfaces Terminate Dependencies? | JAVA