The illusion of reuse; the fallacy of misnomer
Udi Dahan expressed many interesting thoughts here http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/ . Those thoughts strongly resonate with some of mine, although I don’t fully agree with everything he says. I just want to
rant and whine a bit share some of my observations on this subject.
Someone writes a component that performs a complex business function and has a very simple interface. You just call Machine.Work() – it’s that easy. It’s extremely easy to reuse, and this reuse saves you tons of lines of code. So it’s claimed to be highly reusable. But it’s not. Under the hood of this Machine there are so many responsibilities and dependencies, that make it too specialized. So the reuse is really limited to a handful of scenarios. No problem – we can parameterize the machine at the cost of just a few extra lines of code for the caller. Machine.Mode=a; Machine.Kind=b; Machine.BypassUnneededStuff=true; Machine.Work(). Well, you see, in my particular case the resulting behavior is not precisely what I expect, in addition you introduced bugs because you didn’t cover all m to the power n combinations of parameters in your unit test. And the next set of parameters that you add will likely break other use cases.
This is how in my opinion extra dependencies are introduced and the SRP and loose coupling are sacrificed in the name of illusory reuse. But real Reuse is sacrificed too! “Illusory reuse” means that reuse was the intent, but it’s not the result. (Note: When Udi writes “dependencies multiply by reuse”, he means something very different. But I’m not arguing)
Building blocks are more reusable than the machine that is built out of them. So please give me access to those blocks and I’ll just build the machine that I need. This is what Design Patterns are all about. Loosely couple reasonably sized blocks. Reassemble them to solve the task at hand.
A couple of real-world examples.
ADO.Net provides reusable building blocks: Connection, Command, Reader. Every other business app developer seems to be dissatisfied with the level of reuse that they offer: too many lines of code are needed to accomplish a typical task. So they come up with SmartSqlLittleHelper that saves up to 10 lines of code in 80% of reuse cases. In 20% of cases it leaks connections, abuses pooling, or just incapable to fulfill the scenario.
ASP.Net provides reusable UI controls. And we can really increase the level of reuse by customizing their look, building composite controls, etc. But this is not good enough! Let’s bake in data access, business rules and some custom state persistence. Now we’re talking reuse: just drop this control on your form and your FilterableEmployeeListWithButtons is ready! Man, I deal with such controls every day at work. I’d say they do what you need in less than 10% of cases. And when they don’t, the developer would just go ahead and bake more knowledge into them. And that developer would not necessarily be the one who originally wrote the control. And that developer would not necessarily know how to write controls (state persistence, event order, lifecycle). If you can feel my pain, you understand what I mean by “illusory reuse”.