Pass-through objects

Take a look at this class:

public class ThingHandler : IThingHandler
{
	private readonly IUnderlyingThingHandler _underlyingThingHandler;

	public ThingHandler(IUnderlyingThingHandler underlyingThingHandler)
	{
		_underlyingThingHandler = underlyingThingHandler;
	}

	public Thing GetThing(int parameter)
	{
		return _underlyingThingHandler.GetThing(parameter);
	}
}

I've seen variants of this everywhere I've worked. Sometimes it doesn't have the dependency injected, sometimes it catches and immediately rethrows exceptions from the underlying method, sometimes a bunch of these are amalgamated into an enormous god object with an ambiguous name like LogicLayer. The specifics don't matter, because I always end up asking the same question -

"What value does this thing provide?"

It's not abstracting anything. There's no useful computation being performed. It's not buying anything in terms of inversion of control or testability. All it's doing is adding an extra level to the call stack and exercising your dependency injection framework a little more.

Most importantly, it's not separating your application into distinct logical layers, unless you have a specific desire for a "do nothing" layer. Truth is, most problems don't fit neatly into the multiple-tier model, which is why I much prefer grouping things by responsibility rather than trying to shoehorn bits of them into some arbitrary data access or business logic pigeonhole. If you don't do this, then find yourself building a bunch of do-nothing, pass-through objects it's a good sign that your problem isn't one that neatly decomposes into homogenous layers.

Code should be simple and reveal its intention. Pass-through objects don't reveal any intention; more often, they obscure it by requiring more searching and clicking through source files in the IDE to find out what's actually going on. There's no point writing code that does nothing!