Developers, having seen the light regarding the usefulness of patterns, try to use them wherever they can, regardless of whether the pattern is appropriate.

The resulting code tends to be full of factories that only ever return a single thing, that thing being a proxy to a delegate that wraps a class that has a method that has the three lines of code you actually want to execute.

----
'''Discussion'''

This should be mis-use of patterns.
----
Funny sample of that AntiPattern: I worked once in a very big software company that just discovered the GangOfFour DesignPatternsBook. Some managers, being far away from the real life code for too long, thought it was a good idea to put as an objective to each developer in their group the implementation of a DesignPattern in the year after the training! The situation became rapidly totally silly because:
* The shared industrial code (quite repetitive and not a place for innovation) could not allow every developer to implement a pattern from the book;
* Every developer was trying hard to figure out how to do that and was deteriorating the meaning of the pattern itself (most of them were ready to argue about it for hours);
* The code was progressively turning itself into a BigSoupOfClasses.
The most funny thing about all that in that all developers were engineers and so were able to understand that every theorem (pattern) was coming with strict application clauses and that every other use was not recommended or even a very BadThing. The management was deaf to those arguments because it was a way to give the developers InappropriateTechnicalObjective''''''s.
----
CategoryAntiPattern CategoryDevelopmentAntiPattern