Design Patterns Can Be Very Evil

Published on 2015-03-15.

"Design Patterns - Elements of Reusable Object Oriented Software", is a software engineering book which describes recurring solutions to common problems in software design. The book has been very influential to the field of software engineering and it is viewed upon as an important source for object-oriented design theory and practice. The authors are often referred to as the Gang of Four (GoF).

Why is it that in the world of academics, and in the computer engineering part specifically, so many people become religiously obsessed, rather fanatical, with ideas, principles, and theories?

In the community of the PHP programming language such people roam, crawl, and creep in all the major forums, chat rooms, and websites spreading their misguided propaganda and ignorance.

If we regard the book about design patterns as not related to software engineering, but related to the day-to-day life, and if we went back in time to the Stone Age, and the same kind of religious fanatics existed, mankind would have been grinned to a halt. We would still be using sticks and stone.

Maybe it is because of the nature of academic circles, but in the real world, when practice meets and beats theory, religious fanatics are frowned upon.

When we think "common problem" and we blindly start to think "common solution", we totally miss out on creativity and innovation.

No, no, don't try to solve that problem yourself you idiot! Use a design pattern!

-- Some religious nutjob.

The work of the GoF is great. They thought about preventing reoccurring problems in software design, and they have some great ideas that works both in theory and in practice. However, the very concept of "a design pattern" is very dangerous and in the hands of the wrong people it can be devastating to a business.

In the real world of software engineering, design patterns very often leads to complication and cumbersome maintenance, especially when overused. Most of the time there is a really simple and creative solution, but if people are religiously possessed by design patterns, they never find it. Rather than focusing on design patterns, focus should be on creativity, innovation, and good coding principles which are validated by pactice.

There exists a multitude of design principles and a good part of those are also described in the first chapter of the "Design Patterns" book by the GoF.

However, sometimes such advice are often contrary to practical principles such as:

Practical principles doesn't prevent you from thinking innovative, rather on the contrary.

Paul Weaton, a SUN certified Java programmer, has a great short article about Evil Design Patterns in which he states:

I think patterns started off as generally recognized best solutions for common problems.

But now that they have been around for a while and we have experienced applications being made ten times more complicated than they need to be because people try to cram in all they patterns that they have read about ("my application is well architected, because it is loaded to the gills with patterns.") my impression of the value of the pattern has shifted a bit.

I now think that the primary purpose of patterns is to expand our vocabulary. I can say "singleton" and we all know what that means. There may be a dozen different ways to implement a singleton - it doesn't have to be done exactly like the GoF book or some web page.

I think that any pattern being used in an application could/should(/must!) be trumped by "the simplest thing that could possibly work."

And one last thing ... puh-leeze, let's not get suckered by some putz who creates his own web page declaring a pattern. It's only a pattern when it is generally recognized by the greater minds of computer science. And let's add to that there are a lot of intern engineers working for big companies that we trust that have the ability to post content ("IBM Department of Uber Genius Types Declare 'The Squeaky Duck Pattern'"). And there are some books that print some of this garbage too.

The best approach is always the pracmatic approach which means that you deal with things in a sensible and realistically way that is based on practical rather than theoretical solutions.