Leo's Technical Blog

Overengineering and design patterns



Leo Soto

java, patterns

Overengineering and design patterns

Posted by Leo Soto on .

java, patterns

Overengineering and design patterns

Posted by Leo Soto on .

Today, a bit of documentation of the Apache WS stack got the attention of many people. Why?. Well, the interface name says all by itself: RequestProcessorFactoryFactory. Then you notice that the default implementation is called "RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory". Now I get why 80 characters per line is a problem for some people!.


Without getting into fully understand that crazy documentation, let's just assume that it is just a central place to get the factories (sorry, I can't say "central place..." again) that are used to get a damn "request processor". Two levels of indirection! Wait, no. Another level of indirection may exist, because something should be responsible of selecting the right "factory factory". That's worse than the abstract factory pattern .

Wait again. Did I imply that the abstract factory pattern is bad? Maybe.

It's just that I buy the argument that many "design patterns" are workarounds for the shortcommings of programming languages. You want two levels of indirections in a sufficient expresive language?. Even that insanity is straightforward:

class TheImplementation:  

def factory():  
    return TheImplementation

def factoryFactory():  
    return factory

theInstance = factoryFactory()()()  

See? No boilerplate pattern involved.

Another example of a workaround pattern? To be somewhat original, I will point to this "javascript module pattern". Please don't get me wrong. I think that it is good. I mean, a good way to workaround the lack of namespaces in javascript.