Ten years ago, one of my coworkers said “You have to read the ‘Design Patterns’ book! It’s awesome!” I bought the book. I got to page 10, and then I realized that it was a stupid boring waste of time. The “Design Patterns” give complicated names to simple ideas.
In advanced Mathematics, there’s an idea called “Category Theory”. When you do advanced algebra, there are lots of similarities among proofs in different areas. These common themes are grouped together as “Category Theory”. Category Theory is sort of neat, but ultimately useless. “Design Patterns” are like Category Theory. They group together some common themes, but are ultimately useless.
Here is an interesting post by someone else who doesn’t like Design Patterns.
At the time, I didn’t realize the difference between things popular due to hype, and things popular because they’re good. Just like node.js and Rails, “Design Patterns” is an idea with good hype, but not much merit. Unfortunately, there are a lot of clueless people who evaluate the hype and not the content.
The only time Design Patterns might be useful is if you’re on a huge project of 20+ people. However, for a complicated project, you will need more than just the boilerplate Design Patterns. Also, if you use Design Patterns, the number of classes and methods in your project increases. Even for a large project, the cost may outweigh the benefit.
It always is amusing when the head developer at a small startup acts like he’s managing a 50 person team. It’s amusing when they focus on tools that add bureaucratic overhead rather than getting things done. It’s disturbing to interview at some of these flaky startups. Are VCs really that eager to flush capital down the toilet? A VC probably can’t tell the difference between someone with good spin, and someone who has a good idea and the ability to execute.
For example, you could use one of the complicated factory patterns. Or, you can just make sure your objects are properly initialized and destroyed.
If you use the right Design Pattern, you can switch from MySQL to PostgreSQL, and you don’t have to rewrite all the other code! Really? How often do you switch databases? In the meantime, you’re bogging down your program with an extra layer of abstraction.
The “Design Patterns” create the illusion of productivity. You’re writing code that follows the Pattern, rather than your actual application logic. If you use a lot of fancy development methodologies with lots of overhead, that enables you to get the illusion of productivity when you have a large group of barely qualified fools.
It’s also a type of shibboleth. If you think design patterns are awesome, you have a certain personality type. If you think they’re a stupid waste of time, you have another personality type. A stupid hiring manager wants to hire clueless people who go along with the hype, rather than people who think for themselves.
When I go on an interview, and I’m asked a “Design Pattern” question, I mentally translate to the interviewer saying “I’m a stupid retard.” I’m polite anyway. I noticed that the more clueless interviewers ask “Design Patterns” questions. Working for fools isn’t worth it, so I don’t mind being rejected because I don’t know the Design Pattern that answers the question.
“Design Patterns” and “We want MVC experience.” are examples of stupid ideas polluting the software engineering profession. Unfortunately, I’m noticing more and more interviewers asking stupid irrelevant questions. It isn’t enough to be a programmer. I also have to be an expert in their inefficient way of writing software. Those fancy ideas exist to enable mediocre people to pretend they’re getting stuff done. In my experience, those tricks add more overhead without enabling you to do the real work.
I read the Design Patterns book over a decade ago.
My first thoughts after reading the book was that very little was of use to me.
I already knew about the Model-View-Controller pattern from having to use the Swing user interface classes in Java. The Java libraries themselves have the Observer-Observable design pattern.
The thing is that learning these design patterns is not an intellectual feat.
I suspect some people go on about design patterns to try to make themselves sound grand.
The difficult part about writing software is:
a) Getting the software to work.
b) Testing it while you write it so that is really works well and there are no bugs
c) Writing lots of software but still getting it to work
d) Writing lots more software and growing the software, but making it still work
e) Writing fast software
f) Writing software that people love to use
Solving problems is difficult. Writing large amounts of software that is bug free is a talent. Learning Design Patterns for which you will only use 2 – 3 per project is NOT AN INTELLECTUAL FEAT.
If you can’t write good software, you are a clown and will you bleat on about design patterns.
Actually I have the attitude that when I read a book, maybe only a part of it will be directly used by myself.
I was a bit lazy/distracted when I was at university. So a few years ago I re-read an algorithms book. Despite reading the whole book, only one section of one chapter was directly usable by me in the next 6 months.
Of course I already knew the basics and so that’s why reading it again only helped me slightly.
I thought you were just plain stupid from the other rants i read on your blog, but this one makes you a retard. Really? Design patterns are useless?
If you are a real “programmer” as you claim to be, than you are using them without even knowing. I bet you used a singleton at least once in your sorry ass “career”. And yes, that’s a design pattern you morron!
And stop posting comments as anonymous on your own posts. It’s obvious
That’s exactly why design patterns are useless – you don’t need to know them to use them. They are just common sence if you have enough experience. If you don’t have enough experience design patterns will not help you. You can not replace the lack of experience with the knowledge of design patterns.
I’ve actually had to say this in an interview a few times. I tell them I can rattle of the names of various patterns but at the end of the day I’m a developer and there’s a pattern I don’t know by name, chances are I know how to write it anyway and already have!
Singleton pattern is one of the patterns that I use often. I provides a simple solution to a common set of functionality. There a few others that I use and like. With that said, in practice most design patterns not only add complexity to software but also are misused by developers and create a huge mess that is very hard to debug. I have seen developers apply design patterns at a micro level which creates a huge amount of unnecessary complexity and indirection in the software logic flow. I have a degree in computer science and have been a software developer since the late 80s in mostly contract software jobs. I have grown to dislike most design patterns so much that I don’t even apply for projects that use the word design pattern in the job description. That has become more difficult recently as the design pattern cancer spreads. I prefer to work on projects that focus on the actual logic of what the software needs to do than the logic of a misused design pattern and the extra layers of abstraction that they add. And by the way, its spelled “moron” not morron!
Vlad: you are fucked up retard!! Design patterns are at most an obvious banality designed to act as a layer of jargon meant to raise the level of entry into crappy corporate “IT” jobs.
I learned lots of Design and Architectural Patterns (page controller, MVC, ORM’s, etc). I’m a Java and .NET expert. Used it a lot the last 8 years. Today I understand other programmers code and can speak their language (buzz words). Now I’m building a website for myself with the good and old PHP.
Another hilarious thing about design patterns is that they encourage developers to repeat themselves.
Whenever you have a recurring “pattern” in your code, you’re supposed to factor that out into a method or subroutine or whatever.
But in the case of “design” patterns, they encourage you to do the same thing over and over. It’s cut and paste for the ADD generation.
It’s fricking hilarious.
Design patterns sure get too much hype during interviews but being all against them is just as stupid as overusing them.
Just know the tool and use it when useful.
What the interviewer wants to know is: “Do you love programming so much that you spend time reading about these topics will very rarely use?”
Pingback: Software Development Is "Over" - Rex St John
I agree 100% with this. I’m actually design a library to accomplish very specific tasks for a an application I’m writing. Had I chosen a set of patterns or a framework, I would have added so much bloat it wouldn’t have been worth it. But other thing about writing this is that I’m designing the objects to be what they are so that the interface language is consistent with their application. I’ve had the experience in MVC that I’ve had to navigate the business logic through the window of the framework in order to do things “the MVC way”. It’s unbearable. The other thing is that you can be told that doing something a certain way is “wrong” despite the fact that the features are inherent to the language you’re writing in! I find that absurd!
I’ve worked with a couple MVC-style frameworks, and all of them were horrible. (spring/jsp/beans, Ruby on Rails, angular.js, and zend) In each of them, it took about 3x-5x longer than it should have to get stuff done. Also, if you’re writing a complex application, you’ll have to go outside the stuff the framework does for you, and the framework becomes a handicap more than a help.
You ask ANY CS student/programmer they will tell you they are an “expert” at it. How many people do know it? Like under 50 people around the world I am guessing. The dofactory.com site looks retarded, but I had stared into the patterns for a total of 6 month. Every time I reread the patterns it tells me something new and never ends.
I use to feel that I had hit the top of programming skills and was not able to improve my server side. Then I got an interesting contract with one of the big fours. The architect that was leading the project seriously wrote the code in OOP. I was impressed and did not understand anything and had this same reaction as you did about how it was useless. The architect gave me a 15 minute question and answer period after my contract was over.
I asked 3 questions which solved all my questions around this topic and was able to exercise imagination coding in my head with these patterns while staring at the dofactory patterns which killed my mind.
The 3 most important concepts which is a part of the foundation is:
1. The bridge pattern. Aggregating an instance of a object (class A) in a class B. Class B’s methods encapsulate logic in conjunction with calling method(s) of class A in every single method of class B.
2. Polymorphism and loose couple. Class A and class B both inherit of interface/abstract class called IA. Class C aggregates IA as a class level variable. Class C contains methods that encapsulates logic in conjunction with one or more of IA’s methods or signatures. The key is that depending if IA variable in Class C is class A or class B, class C will perform it’s methods in a different way. A good example is the strategy is one way of defining the runtime value of IA variable in class C.
3. A class should be created if a set of primitive variables and class constitutes an entity. Methods in this class are instance methods if it manipulates one or more primitive class variables or calls upon a method in a instance of an object stored in one of it’s class variables. Otherwise a static method is to be used in this class.
Common mistakes that I see in code is:
-use of inheritance (especially with an interface) but not using it for any polymorphic behavior. What is the point of using inheritance in this case?
-All methods in classes are static = wanting to kill server memory
-classes with only class level variables and no methods = logic that manipulates these variables are scattered all over the program.
OO can be used on small or large programs. In small programs, there is more aggregation of classes (bridge pattern) with little or no inheritance. In large program, there will be more or a lot inheritance.
Think about it. You aggregate classes as class variable in another class will actual bring the code to completion if I am describing my thought properly.
Bridge and strategy is the basis of OOP and are the 2 to learn first.
It is possible but takes a lot to figure out and will drive one nuts. Once it is figured out, there is a unlimited growth in one’s skills and there will be no ceiling to be hit.
I completely agree with you. I’m the creator of a community (The Science of Code) that tries to teach Computer Science as a liberal art. I want to translate this article into spanish in order to share it with people who doesn’t speak english. Would you mind if I do it? Obviously giving you the respective credits.