Examples of design pattern misuse

Question

Design patterns are great in that they distill a potentially complex technique into something idiomatic. Often just the fact that it has a name helps communication and understanding.

The downside is that it makes it easier to try to use them as a silver bullet, applying them to every situation without thinking about the motivation behind them, and taking a second to consider whether a given pattern is really appropriate for the situation.

Unlike this question, I'm not looking for design patterns that are often misused, but I'd love to see some examples of really solid design patterns put to bad use. I'm looking for cases where someone "missed the point" and either applied the wrong pattern, or even implemented it badly.

The point of this is that I'd like to be able to highlight that design patterns aren't an excuse to disable critical analysis. Also, I want to emphasise the need to understand not just what the patterns are, but why they are often a good approach.

Answer 1

I have an application that I maintain that uses a provider pattern for just about everything -- with little need. Multiple levels of inheritance as well. As an example, there's a data provider interface that is implemented by an abstract BaseDataProvider, that is in turn extended by a SqlDataProvider. In each of the hierarchies, there is only one concrete implementation of each type. Apparently the developer got ahold of a Microsoft document on implementing Enterprise Architecture and, because lots of people use this application, decided it needed all the flexibility to support multiple databases, multiple enterprise directories, and multiple calendering systems even though we only use MS SQL Server, Active Directory, and Exchange.

To top it all off, configuration items like credentials, urls, and paths are hard-coded all over the place AND override the data that is passed in via parameters to the more abstract classes. Changing this application is a lot like pulling on a thread in a sweater. The more you pull the more things get unraveled and you end up making changes all over the code to do something that should have been simple.

I'm slowly rewriting it -- partly because the code is awful and partly because it's really three applications rolled up into one, one of which isn't really even needed.

Answer 2

Well, to share a bit of experiance. In C#, I had a nicely cool design which used lots of pattern.. I really used lot of them so to make the story short, I won't name it all. But, when I actually tested with real data, the 10^6 objects didn't "run smoothly" with my beautiful design. And by profiling it, I just saw that all those indirection level of nicely polymorphisms classes, proxy, etc. were just too much.. so I guess I could have rewritten it using better pattern to make it more efficient but I had no time, so I practically hacked it procedurally and until now, well, it works way better.. sigh, sad story.

Answer 3

I have seen an asp.net app where the (then junior, now quite capable) developer had managed to effectively make his codebehinds singletons thinking each page was unique which worked brilliantly on his local machine right up to the point where the testers were fighting for control of the login screen.

Purely a misunderstanding of the scope of "unique" and a mind eager to use these design pattern thingies.