John Fremlin's blog: Purely effective programming

Every function should either perform a calculation or make a call to a remote machine or another process. If a piece of code does not perform one of these useful activities why does it exist? Delete it!

Why should anybody write pointless code like this at all? One reason is that when a weak programmer encounters a problem he or she cannot see how to solve, he or she will create an abstract layer (unimplemented) that gives the solution, and then will try to fill in the layer. This is obviously bad but somehow all too easy to nod along to. Another cause is a desire code ownership: someone wants to own or rewrite a slightly broken subsystem, but can't figure out how to modify it in place, or wish to establish ownership of a new replacement system, so they call down to the old system after mangling the parameters slightly.

What about the C++ pimpl pattern where the top class forwards every call to its implementation class, and similar implementation hiding techniques in Java? Well, like all object orientated abstractions this technique can be useful for large projects with complex and varying consumers. For projects that have merely become large due to the layer after layer of fragile and badly conceived implementation hiding mechanisms, or for parts of those projects which cannot conceivably have more than one caller, there really is no point — and the implementation hiding makes life harder for anybody trying to debug or modify the code.

My favourite example is the pattern where a shim class exposes a bunch of different methods, translates them into an Enum method code with a parameters bundle, and passes them to another class which translates back from the enum to a method call on an implementation class that returns something completely innocuous. This means that adding a parameter requires modifying probably four or five files (given that though there will be only one implementation of each of these components, they will be exposed as descending from abstract interfaces). Unless really carefully thought through the parameters passed to an interface expose a lot of information about the implementation, so little implementation specificity has been hidden at all.

If you have to pass though calls to another interface, make the calls as terse and generic as possible. Don't inspect the parameters. Purely effective programming — if your code doesn't do something, delete it!