Some anonymous soul emailed me regarding my “Design patterns are from hell!” post, arguing that “somehow, knowing patterns exist is the same as knowing different data structures exist” and that “understanding the different ways for creating objects (hello creational patterns) is like understanding the implications of deciding to use a dequeue rather than an array or rather than a linked list.”
I was also bravely asked what I thought about these statements. Well, guess what, since one can never diss design patterns enough, this is what I think…
They’re from hell!
No, there are no similarities between data structures and algorithms on one side and design patterns on the other side! Rather, there are lots of distinctions but the perhaps most important one is that data structures and algorithms are language independent whereas design patterns are language dependent. Data structures and algorithms are forever, whereas design patterns are as fleeting as the object-oriented languages for which they have been (predominantly) proposed. (That fact alone should warrant little to no attention being paid to design patterns. And if you don’t understand why OO is fleeting, time to learn a second language, other than C++.)
A second important distinction is that data structures and algorithms do not come encumbered with preferred usages. They just are. A programmer has to make deliberate choices — has to think — before selecting one over the other. Thinking is what makes, or breaks, the programmer.
In contrast, design patterns are purported “master programmer advice” strongly suggesting to young or otherwise impressionable programmers that the design patterns convey important concepts, practices, or principles that have been “prethought.” However, design patterns are not “master programmer advice!” Any master programmer would know that you cannot simply dish out a small number of generic solutions for generic situations, but that every situation is (potentially) different and warrants its own (potential) solution.
Far from “master programmers,” design patterns are the work of people who do conferences, talks, and books for a living, to further their own cause; they’re the work of academics who live in their heads and have never worked on real projects to see what kind of shit code their abstract ideas produce when put in practice; they’re the work of people who couldn’t care less about what toxic miasma they have unleashed because they’re too busy speaking at Software Development to push their consulting gigs to the fools who bought into the snake oil.
Design patterns are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it.
Design patterns really are from hell!
That’s what I think.
I had to register just to post a comment saying I agree.
Having taking a great interest in lisp recently, coming from C++ and java, I have experienced first hand that many, if not most, of the design patterns in the book of the same name are just bandaids for the gushing wounds of those languages.
Like many before me I would also recommend learing something completely different for an enlightening experience.
Good choices are:
Haskell
Lisp
Smalltalk
Forth
And also to learn about the history of those languages and the people behind them to gain some perspective. Because the java (and to a lesser degree C++) camp keeps rediscovering a lot of ideas that have been around for decades just because they don’t know their history.
ps.
Snake Oil Software seems like a cool company name :)
/mac
Is there no way to edit comments?
Feels stupid posting a second comment to “edit” your first one.
Anyway, I forgot a language:
Erlang
And I will also be as bold as to mention my (current) personal favourite which is a sort of mix of erlang and lisp: Clojure (www.clojure.org), although it does not focus on distributed computing like erlang does but rather concurrency in same-process applications.
/mac
It is time for a reconciliation with patterns !
I don’t share the same hatred for patterns, they are one way to solve a problem or a type of problems, like a generic answer
The error I see often is designing up front with patterns, while patterns is a design structure that (very often) _emerges_ from your implementation
Patterns also introduce an unnecessary level of abstraction, who feel confident to work on a “visitor for composites” ? The cryptic nomenclature says nothing about what you want to do… It would be simpler to say that you need to save (recursive) data.
Design patterns are a counter-reaction against 50 years of unreadable, unmainanable, shitty code produced by bit-fiddlers who learned programming long ago and want to stay “cool” cause that reminds them of when they lost their virginity…
I’m tired of cleaning up code from people who prioritize being hardcore over good code architecture with the argument that it saves you 1 fps and 1 byte mem. (cleaning up = rewriting from scratch)
I’d agree with supzi. When I’ve seen groups start designing with patterns (especially academic groups), they’ve ended up with huge messes. However, during maintenance, patterns have been very valuable both to me personally and to groups that I’ve observed. Maybe it’s that some of the codebases I’ve dealt with were pretty amateur in quality, but it’s one way to talk about the way code should work when you’re planning a rewrite.
For example, one codebase that I’m familiar with right now might benefit from a little pattern-like thought. Due to cruft, there are at least three different implementations of a stereotypical callback mechanism in the codebase. They’re all named and documented wildly differently. They all work, and have adequate performance, but the service provided by all three is the same – and since this is a library intended for reuse the code would be a lot more legible and a bit more maintainable if they were unified.
Contrary to your assertions above, the Gang of Four book is pretty dogmatic about saying that patterns need to be varied to fit the situation, and giving examples of how you might do so. The one or two more recent pattern books that I’ve read weren’t as conscientious, but then I’d agree with you that some of them are shovelware on paper.
Christer, don’t you think you’re overreacting a bit? But I suppose that’s what the Internet is all about and it keeps things entertaining, so go for it :-)
Seriously, I agree 100% with your earlier post. Design Patterns are counterproductive as soon as people start thinking of solving problems through patterns.
But it doesn’t hurt to have a knowledge of patterns. It makes discussing program architecture easier, and they can help understand new code faster. Flawed as they are, they’re a higher-level abstraction than lines of code and data structures. So they can help a bit in that direction.
Hi Noel,
It is rare that you’ll find me say that any knowledge is bad, but on this one I have to disagree with you. The problem isn’t that knowledge of patterns is completely useless and programmers are much better off spending time learning useful knowledge like data structures and algorithms, even though that’s a true statement as far as I’m concerned. The problem is that patterns are as bad as, well, guns. Guns kill people, and pattern thinking causes brain rot.
There’s ton of people who incorrectly think and propagate that patterns are master programmer advice when they really are over-engineered solutions for deficiencies of object-oriented programming languages. I don’t like over-engineered solutions and I don’t like object-oriented programming languages, so fleeting terminology for shit stuff like that is not something I’m likely to promote any time.
I realize reading the mindless drivel of Design Patterns might give some programmers instant satisfaction because everyone talks about patterns and they now feel smarter having read about them, but in reality these programmers would be better off beating their heads against Knuth because that will actually make them smarter, not just feel like they are. (Knuth is a hard read, but avoiding solving hard problems isn’t the way of becoming a master programmer any more than is studying Design Patterns. If Knuth is too much, read Skiena’s book.)
I mean, if someone thinks they are a better programmer for knowing the “visitor” and “observer” patterns, but they don’t know, say, what a skiplist is, how to perform a k-nearest neighbor search, or how to apply dynamic programming to a problem then they’re fools.
And, no, I’m not overreacting. :) I’m just making sure my point comes across loud and clear, because there needs to be a lot of shouting to counterbalance all the published bullshit about patterns. I was hoping the problem would just go away, but as it isn’t, I’ll use my little soapbox to make it painfully clear that I, for one, think they’re a scourge of programming/design.
I’ve been programming games and engines for twenty years and never came across a problem requiring k-nearest neighbor search, dynamic programming or skiplists. What does that mean?
If I wanted to attract hits to some webpage I might declare that they’re completely useless and anyone devoting time and brain cells to understanding a memorizing these data structures and algorithms are idiots.
On the other hand, I might be more reasonable and realise that it might be handy to know the names and workings of these algorithms if one day I would need them and had to describe how my solution works to somebody else. And even though I personally haven’t found much use for these constructs, I recognize that having a name for something is a good thing and aids communication.
Patterns will exist whether you acknowledge them or not, and whether you use OO to implement them or not. Even if you were implementing your skiplist traversal function in x86 assembly issuing a callback to some user defined function you would still have implemented the visitor pattern. They’re just vocabulary to aid communication, and pattern books are really no different from algorithm books.
If someone overengineers using patterns it’s really no different from someone using a skip list to search a set of 10 items. All knowledge is pointless shit if you don’t know how or when to apply it.
Just want to share some personal experience on this. Back when I have just graduated, I found my self trying to understand why people programming certain way. At beginning, I thought those fancy patterns are really smart and ingenious that I would hope to use it somewhere.
After few years of experience now, I think of those fancy patterns useless but from a different standing… Most of them are not hardware aware as all. As console programmer, I think we need to put the hardware up front then any patterns or tricks. I am glad that when I start to write a new system now, first thing I think of is how can it takes advantage of the hardware rather then which “algorithm” or “data structure” I should use.
bionicbeagle, yes, there are patterns everywhere, but that doesn’t warrant giving them names as if they are important. We do not talk about the “handkerchief pattern” or “hammer V-claw pattern” even though the former is an accepted solution for blowing your nose and the latter is the accepted method for pulling out a nail. Calling something a “visitor pattern” is therefore pretentious nonsense to make some people feel more important when uttering the term and to help others sell more books.
As for what it means that you’ve never come across a problem where k-nearest neighbor search is relevant? That tells people that you’ve never implemented a photon mapper. That you’re claiming never to have come across a problem where dynamic programming would be relevant shows that you are ignorant about what dynamic programming is. (Hint: Dijkstra’s algorithm is a classic example of dynamic programming.) Studying the skiplist teaches you that there is such a thing as probabilistic data structures, which expand your understanding unlike, say, arbitrary labeling of obvious or irrelevant stuff.
Christer, nothing force you to use someone else terminology. If someone come and ask you help about a design issue, you may answer with a design, it doesn’t matter if you call it “factory” or the “christer preferred method for ubber object creation ” or “the ying-yang apocalypse”
Behind each pattern; there’s a motivation and a proposed clean solution. It’s up to you to learn from it.
On the other hand, K-nearest neighbor, skip-lists, Dijkstra shortest path are algorithms. They are solutions preferred for their (speed, memory, cache, I/O…) efficiency, not implementation. You can still use the smart “ying yang apocalypse” technique during the implementation.
Patterns and algorithms are not mutually exclusive. You don’t have to chose “be patterns” or “be algorithmic”. A “master programmer” like our beloved blogger will judiciously pick the right algorithm and will use smart software design to get a clean, maintainable and readable implementation.
And I will add: object oriented paradigm has defects, but it has the opportunity, in many cases, to ease development and clarify the code. It is just a tool and like any other tool: use it well, where appropriate, and it will be infinitely valuable. OO was invented more than 20 years ago and it gained vast popularity over the years. Looking at its evolution, I think it is wrong to describe it as “fleeting”.
‘Calling something a “visitor pattern” is therefore pretentious nonsense to make some people feel more important when uttering the term and to help others sell more books.’
While there’s certainly an element of that, dismissing the entire concept of design patterns for that reason is probably a case of throwing the baby out with the bath water…
As a few other have pointed out, where design patterns are the most useful are for communication. When I look at someone’s code and they’ve written an algorithm in terms of functions like “Dispatch”, “Visit”, etc. it’s very clear what they’re trying to accomplish, and it’s very easy to edit and maintain the code. Conversely had one programmer decided to call it “ExecuteAssociatedAction” or “vpfnPerTypeFunctionCallbackHandlerThing” – perhaps even in the same body of code – it might not be as clear ;)
So one place where people miss the boat definitely is that there’s no point in trying to explain something in terms of patterns to someone who isn’t familiar with them… they’re just a communicational tool, so there’s no point in speaking to someone in a language that they don’t understand. That said, the point in the patterns is to unify the language. I think anyone who has worked with a diverse body of developers knows that there are a lot of different names for these kinds of things, so settling on some standards is a good thing.
“That you’re claiming never to have come across a problem where dynamic programming would be relevant shows that you are ignorant about what dynamic programming is.”
Arguably dynamic programming is more of a pattern than an algorithm though :)
‘I am glad that when I start to write a new system now, first thing I think of is how can it takes advantage of the hardware rather then which “algorithm” or “data structure” I should use.’
Definitely true, and people certainly need to start favoring data-driven designs over code designs in this day and age of massively parallel computing (although the two need not be mutually exclusive). I’d take it a step further though and say that people who think too much about the specific hardware quirks that they’re dealing with and not enough about fundamental things like computational complexity, memory access patterns, etc. are also missing the boat though.
“Arguably dynamic programming is more of a pattern than an algorithm though :)”
Perfect, and no smiley needed! I was hoping someone would get that dynamic programming is very pattern-like. Thanks for your perceptiveness Andrew! (And note, nowhere did I suggest it was an algorithm.) Indeed, and similarly you could make the case that “divide and conquer” is a programming pattern. But notice the distinction: we don’t say “dynamic programming pattern” or “divide and conquer pattern” (nor, as I pointed out, do we say “handkerchief pattern”).
The presence of the “pattern” term (the “‘pattern’ pattern” if you will) is the indicator of what’s the problem here. Standard terminology appears naturally, as witnessed by terms like “divide and conquer”, “dynamic programming”, “callback”, etc.
What the Book from Hell did was to force standard terminology down everyone’s throat, instead of letting natural selection have its course. This has resulted in a bunch of mindless sheep now thinking that there is some sort of inherent value to “visitor patterns”, and worse, that anything categorized as a “pattern” is good.
It goes without saying that terminology is important, but relevant and precise terminology arises natually, from a need! “Callback”, for example, never had this cult or passionate discourse about its being, because that term arouse naturally. But there was never a natural need for labeling of encapculated global variables as “singletons” or other similarly trivial concepts as “visitor”, “observer”, or what-have-you patterns. These patterns are entirely artificial concepts, borne out of the only need they were ever close to — the need for academic masturbation!
Fair enough, I think I understand what you’re saying now. While I wouldn’t peg the guilt entirely on academia, I do generally agree with your point :)
Way before design patterns, I used to keep a toolbox of interesting and effective ways to solve specific problems, which I called “mechanisms”. It was just an informal, personal collection of things that I knew worked; most other programmers I’d worked with back then were similar.
It is, in all fairness, the underlying idea behind quotes like “don’t reinvent the wheel”. For simple common problems it is faster to start somewhere known, and then work your way into the full solution. I don’t need to reinvent the concept behind the wheel, but I will need to tailor a specific instance of that idea to my current needs.
In so long as ‘patterns’ are really used as such, they form very good places to start. They have actually existed in some form or another, long before more specific abstractions like data-structures, but always at an informal unorganized level. We all tend to reuse our earlier solutions towards problems that we see over and over again, and if you program long enough, just about everything you see now will come to the surface again at some point. Patterns (before they went off course) were just a simple formalization of that existing process. If we can’t learn from our previous efforts, then we are doomed to rewrite the same code (and the same bugs) over and over again.
Paul
http://theprogrammersparadox.blogspot.com
My trackback hasn’t shown up for some reason, so here’s my response. In summary: Almost nobody who comments on the matter actually understands what Design Patterns was on about.
I guess my main problem with design patterns is that it has never been clear to me exactly what they ‘do’.
Do they help me get a program working?
Can they make my program faster? Shorter? Use less memory?
Will they reduce the number of bugs in my program?
As near as I can tell, all of the benefits ascribed to design patterns derive from magical thinking rather than some natural reason. The idea that patterns somehow ‘help’ your code is analogous to ritualistic practices such as Feng-Shui or voodoo. In my opinion design pattern literature is just like astrological horoscopes in that they purports equally nebulous benefits.
-Mik
Design patterns have a use: they are nouns. Nouns with lengthy definitions and a specific domain, but nouns nonetheless. Their use is in extending a spoken language to allow us to talk about aspects of the software design domain without getting bogged down in the specifics.
Think for a moment about buildings, specifically cathedrals. In Europe I saw a huge old cathedral – so large that it had arches down from the main building onto separate pillars to support the walls and roof. It are very tall, given how long ago they must have been built. There were tall, thin windows with pointed arches, and many decorative carvings. Inside it was very light for a heavy stone building, and the ceilings were vaulted.
Or I could have said that it was a Gothic cathedral.
My partner is a fashion designer and has an interest in art and classical architecture. I have learned a lot about software design from discussing fashion and architecture with her — in particular that communication is severely hampered without domain-specific words. Terms like “Gothic architecture”, “Georgian coat” and “Victorian corset” succinctly convey a massive amount of information that would otherwise take many words and pictures to explain; yet they simultaneously avoid implementation detail (size, color, trim, etc).
Psychologically we handle complexity by breaking it down into identifiable parts that we can stereotype. The more powerful abstractions/stereotypes we have available to us the better we are able to handle complexity.
Design patterns give us names for common stereotypes/abstractions in software design.
Twylite, you’re a freaking genius! Why didn’t I see that before?! Wow. Let’s make up some word patterns for architecture right now. And, just like Humpty Dumpty we can choose to make the words mean whatever we want them to mean! Let’s see…
Wow, it’s amazing how well it works!
“Design patterns give us names for common stereotypes/abstractions in software design.”
No. These patterns are only “common” because someone wrote down some shit in a book and code monkeys started flinging it into every piece of code they write because they heard someone else say it was expert advice.
Christer:
Have you also got a name for someone who publicly posts opinion pieces, and then rudely slams visitors who try their best to discuss to them in good faith?
Or perhaps we should try and figure out if we can find one that fits, that has just evolved organically? Unfortunately, I can think of several :(
Otherwise, interesting and provocative discussion.
aThirdParty, I didn’t think it was necessary to state this, but I guess it is. Here’s how it works…
I post things on my blog because, well, I like to. You come here of your own free will and read my posts if it suits you. If you think what I post is meaningless drivel, you go away. If you think it’s not and decide to stay, and have something insightful to add — whether pro or con — you are welcome to post a comment and share your thoughts. My policy is to approve all non-spam comments unless they are pure vitriol.
However, if you post a comment that is a vapid generalization (or just vapid in general), totally nonconstructive, or that makes it clear that you haven’t read a single word of what was previously said (and “design patterns are nouns and therefore valid” hits all three), expect to get an earful back.
AI programmers will recognize this as reinforcement learning using a negative payoff.
>My policy is to approve all non-spam comments unless they are pure vitriol.
I wasn’t sure if my comment would be approved – I admire/respect your integrity.
>AI programmers will recognize this as reinforcement learning using a negative payoff.
a technique that works well in certain simple machine learning situations.
But if you use that as evidence of it’s utility as a technique for yielding better comments, you should stop writing about design patterns and start reading about people skills.
I think your attitude to your blog is likely to create a situation where people that agree with you post, and people that disagree stay away; considering your impressive reputation, and evident harshness you might quickly find constructive criticism drying up – we should look after our critics, better than our admirers. It is, of course, your blog, and how you run it is your decision.
I posted because I thought you went too far in your belittling of ‘Twylite’s friendly response (which did not sound like the work of an idiot to me) especially considering how un-rigorous your initial posting was.
Respect, though, for standing on your soapbox and taking a swing at something so zealously admired as design patterns; while I disagree with your sweeping statements dismissing the whole concept, there’s definitely an over-reliance on design by overly-complex-cookbook that’s correlated with their use, and it’s good to see the flag being raised.
A brief suggestion – I think you might get more traction in future if you say they are ‘considered harmful’ rather than ‘from hell’…
aThirdParty, thanks for your comments. Here are some questions for you to ponder. (And to avoid (lengthy) replies, I provided the correct answers in parentheses. Don’t peek!)
In order:
1) Of sending it, no. Of making it past the ‘filters’ most people inevitable apply to discard messages that insult or belittle them, yes.
2) Irrelevant/straw-man. A) The reply was hardly feeble-minded. B) My point was you’ll discourage disagreeing replies in general, both feeble minded and sharp witted.
3) Seems you lack compassion. To continue your analogy, how would you feel if a doctor took that position in the isomorphic situation?
4) Accidental, no, but just because I suggested an improvement doesn’t mean I thought your actions were not deliberate. Anyway, I was jesting there.
5) Depends, agreed in general, but I wouldn’t insist on telling that to a man with a gun to my head.
aThirdParty, Twylite’s comment was feeble-minded for the following reasons:
1. He suggests that all nouns are useful. But this is trivially a false statement as once we reach as many nouns as there are concepts, the nouns have lost their abstractive power and have become worthless.
2. He correctly identifies that design patterns have lengthy definitions and a limited domain, but fails to note that they are, in fact, much more limited than so; they are so specific to a particular development methodology and a particular language that they effectively have no expressive power beyond those.
3. Worse, he fails to read the actual message, not seeing — even though it is plain to see in just about every of my comments — that it is not an issue about the descriptive power of “pattern nouns” but one of leading a whole generation of programmers astray thinking that patterns are important when they so are not. To prove his total ignorance of my point, he still posts about the descriptive powers of nouns (and even so, gets it wrong, as per points 1 and 2 above).
In other words: his comment has less relevancy to my post than Palin’s statement about Putin’s head floating in Alaskan airspace had to Couric’s question.
That you did not see this feeble-mindedness in his comment I find disappointing.
You are right on one thing though, I have little compassion for feeble thinking. I find my compassion is better expressed as donations to ACS than as trying to spell things out, as I did in this post, only to find e.g. that some still don’t get a simple reductio ad absurdum argument (point number one, above).
Have you looked at the chapter on design patterns in Richard Gabriel’s “Patterns of Software”? In it, he describes C Alexander’s problem with his pattern language approach as being too large, too coarse, and that there was a smaller, more fundamental organizing force in design going on. He describes this in the context of 2D carpet patterns in “A Foreshadowing of 21st Century Art, The Geometry of Very Early Turkish Carpets”.
So Alexander, in my own words, felt the tail(pattern) wagging the dog(design). I don’t use design patterns per se, but feel they are an attempt at bringing more abstract conventions to programming. Which I am all for, as long as the compiler can check them!
By conventions, I mean if there is a function called “open_blah”, convention suggests a “close_blah” also exists, and these conventions are important for creating navigable space in terra incognita.
http://en.wikipedia.org/wiki/Christopher_Alexander
http://en.wikipedia.org/wiki/Pattern_language
http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
It is sad to see R Gabriel giving his work away. The book is worth buying (I have twice), if you don’t mind more questions than answers. The section on Gabriel’s academic career is very revealing.
>1. He suggests that all nouns are useful. But this is trivially a false statement as once we reach as many nouns as there are concepts, the nouns have lost their abstractive power and have become worthless.
His statements were not certainly constructed in a rigorous manner. I will attempt to do better.
When he says ‘Design patterns have a use: they are nouns.’:
I think it is unreasonable to take this as saying ‘All nouns are useful, design patterns are nouns, therefore design patterns are useful’ which is how you seem to have interpreted it.
I would instead have assumed he was saying that _some_ design patterns are useful because they provide us with useful nouns.
I agree with this argument.
I think some design patterns are useful in that they provide us with a simple way to express a high level abstraction.
Take the Observer pattern. This is clearly a commonly used technique when architecting certain pieces of OO software. It’s all over swing, for example. I’ve also seen implementations in C++ GUIs. I’ve also seen it implemented by people who have never heard of design patterns.
When I meet another developer to discuss architecture, and they suggest using Observer in a certain area, then, much like Twylite’s post says, that quickly conveys a lot of information to me. Assuming, for argument, that observer happened to be the right way to build the software, then is it not useful to have that noun available to quickly communicate the architecture?
This is, I believe, what Twylite was trying to say. I agree in that sometimes certain design patterns provide nouns for high level abstractions that are useful to have. I think this is a good thing, as it can save time, and increase clarity.
I have yet to see you refute this point by sound and reasoned argument.
Note, I am not saying all patterns are useful nouns, just disagreeing with you when you say none of them are. I am also assuming in my hypothetical situation that the choice of the observer pattern was correct independent of any prejudicing knowledge of the pattern. You could argue that knowledge of patterns biases the architecutre towards their use, and that would be a valid point against, but would not diminish the point for.
To make my own position clear, I agree with you that attempting to use design patterns as the initial building blocks of a large OO system is not a good approach to architecture. I have seen situations where it leads to both overcomplex and ill-fitting design.
>2. He correctly identifies that design patterns have lengthy definitions and a limited domain, but fails to note that they are, in fact, much more limited >than so; they are so specific to a particular development methodology and a particular language that they effectively have no expressive power beyond those.
Depending on what your exact definition of pattern and methodology is (care to field one?) they may or may not be specific to a particular development methodology.
But they are certainly not specific to a particular language.
You have said this multiple times, and it is demonstrably rubbish.
The observer pattern, mentioned above, can clearly be seen in Java, C++, and a host of other (OO) languages.
So please retract the point that patterns in general are specific language, or clarify that you in fact meant specific to broad class of language (those that are OO, which is a sizable portion of popular languages).
It’s worth noting that some people define pattern more broadly, and have patterns that are non-OO too – but this might be a semantic irrelevance here, if by Design Pattern you were limiting your discussion to those in the GoF book.
>3. Worse, he fails to read the actual message, not seeing — even though it is plain to see in just about every of my comments — that it is not an issue about the descriptive power of “pattern nouns” but one of leading a whole generation of programmers astray thinking that patterns are important when they so are not. To prove his total ignorance of my point, he still posts about the descriptive powers of nouns (and even so, gets it wrong, as per points 1 and 2 above).
>In other words: his comment has less relevancy to my post than Palin’s statement about Putin’s head floating in Alaskan airspace had to Couric’s question.
Regrettably I am not familiar with the context of the good governors remarks; but I shall assume you are not using the example as one of high relevance.
IMO, you attack design patterns unequivocally, stating they are from hell, and strongly implying they have no possible benefit or use.
He provides an argument in favour of design patterns, which you have not previously mentioned or refuted in your post.
Therefore, I see direct relevance to your post in what he says.
I suspect aThirdParty is none other than Twylite.
Evidence:
1) Timing and focus of posts. aThirdParty seems hell-bent to defend, and further clarify Twylite’s POV.
2) Syntactic similarities; starting a paragraph with “Or …”, the use of ‘-‘ ‘:’, and ‘/’ as word separators.
One example:
aThirdParty: ” … admire/respect”
Twylite: ” … stereotypes/abstractions ”
3) Sentence structure similarities.
4) The slightly too convenient name ‘aThirdParty’.
Perhaps patterns are useful after all. Or I could be having a John Nash moment.
Bah, boring and wrong.
Regarding 1&4, well, as I said, I only stepped in because you were particularly rude to another poster. Hence the name.
Regarding 2&3, well, I know that’s just co-incidence. Go look at IP logs if you have them, I’m betting I’m in a very different geoIP range than Twilyte was.
I made some points in my last post, and rather than deal with them logically, you’ve run off down some sock puppet tangent.
Have to say, expected more than this sort of flawed deduction, or ad hominem style of argument.
Not impressed.
Well, if I’m wrong, I’m wrong. But you might want to read a little bit more carefully next time.
Christer, funny that you mention the “hammer V-claw pattern”. The hammer as a pattern is an example I’ve used in a blog post about design patterns a while ago.
I’d argue that it’d actually be good to compare design patterns to a hammer. They’re no more than a name for an approach to pounding nails into a board – that doesn’t mean you can’t use other items to serve the same purpose, though.
Unfortunately, people tend to view them as solutions to a problem, which they’re not.
I don’t agree that they cause brain rot, though. I think the brain rot is there well before the patterns. It’s just a question of circumstance whether those with rotten brains follow the design pattern crowd, or the crowd of people eschewing design patterns. They’ll be bad programmers whichever side they pick, I think. By the same token, I can’t bring myself to dismiss design patterns as such, just the people who misuse them.
Some more questions for this discussion:
1. Do patterns at all exist in code, and if so at which level of abstraction? That is, is it possible to analyze existing code and identify universal patterns that exist in many types of code from different domains, from programmers with different types of education, between different languages etc?
2. If such patterns do exist in a universal sense, it it then pure evil to use this for knowledge transfer, learning, communication and collaborative design in relation to programming?
3. Or, is it so, that the so called “design patterns” are so broken that they are completely useless in promoting knowledge transfer and communication, because they have nothing to do with the “relevant patterns” that do exist in program code (provided you answered “yes” to question #1)?
“In contrast, design patterns are purported “master programmer advice” strongly suggesting to young or otherwise impressionable programmers that the design patterns convey important concepts, practices, or principles that have been “prethought.””
Never thought of them like that — if I ever designed a system that was similar to something in “the book” it was more coincidence than anything else (and I certainly don’t consider any of those four gentlemen to be “masters” any more than I consider Grady Booch to be so ordained). This of course coming from a guy who learned C++ because he couldn’t find any C books in the library when it came time for the Algorithms course in college (yay for “Algorithms In C++”).
At any rate, design patterns are not exactly language-specific (unless you mean that the GoF patterns apply to imperative programming languages), because I can do the same things in C# that I do in C++. ;) Just wanted to point that out (and sorry if it has already been argued — I just skimmed over most of the comments).
My $0.02
Btw, I have to ask — this is the reductio ad absurdum you mentioned, right?
“I mean, if someone thinks they are a better programmer for knowing the “visitor” and “observer” patterns, but they don’t know, say, what a skiplist is, how to perform a k-nearest neighbor search, or how to apply dynamic programming to a problem then they’re fools.”
Because you clearly aren’t serious here, and are just trying to make a point?
I really have no intention of replying further here, because those who haven’t gotten my message already never will. That said, some final (late) comments:
unwesen, on the silliness that is your “[design patterns are] no more than a name for an approach to pounding nails into a board” analogy. Ask yourself, do carpenters have different names for “approaches to pounding nails into a board”? (Go ask a carpenter. No, really, go do it!) Of course not! Unlike programmers, carpenters are intelligent people, and they wouldn’t even dream of doing something as moronic as assigning a name to nail pounding!
Kenneth, these are all perfect examples of academic questions that have little practical value beyond getting someone a thesis. These questions and attempts at answering them do not belong on my blog. This blog is for discussing real-world issues.
Greg, “language dependent” is not a singular but a plural reference to languages. And, yes, I’m 100% serious, modulo the five somewhat randomly picked subjects of the sentence.
“Greg, “language dependent” is not a singular but a plural reference to languages. And, yes, I’m 100% serious, modulo the five somewhat randomly picked subjects of the sentence.”
Ok, just so long as you aren’t calling the vast majority of perfectly competent, productive, and non-pattern-zombie professional programmers “fools” simply because they have never had cause or need to do photon mapping…because that wasn’t really clear from your earlier clarification.
One thing I keep forgetting to bring up…
Perhaps you see more bad programmers as a director than I do as a lead (which would be kudos to my TD for weeding them out before I have to), but to me, the problem isn’t “design patterns”…it’s “Javaschools” (I’m sure you’ve seen it but for those that haven’t, I strongly recommend “The Perils Of Javaschools”
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
and the link within (which, not coincidentally, buttresses another of your themes), Paul Graham’s “Beating The Averages”
http://www.paulgraham.com/avg.html
Took me a while to realize that you’ve written a reply, christer. Sorry about that.
It’s true that there’s only one way to drive a nail into a piece of wood. On the other hand, there are plenty of ways of joining two pieces of wood (go ask carpenters about that, if you must bring them into the discussion). The “hammer-nail” pattern is just one of them; offhand I’ve personally used the “glue pattern”, the “wood plug” pattern, a combination of the glue and wood plug pattern, the “screw pattern” and even some attempts at proper joinery. err the joinery pattern.
You don’t need to call it a pattern if you hate the word, call it a technique.
Carpenters are lucky compared to us in that even the most complex technique of joining two pieces of wood they employ can be described — not exhaustively, but to the point that they can be identified — in a few informal words. And yet even they resort to formal terms where needed. I recommend starting your reading here: http://en.wikipedia.org/wiki/Woodworking_joints
I see you’re missing the point.
In carpentry, there is no group of “carpentry masters” who holds classes telling carpenters to use the ‘new’ “glue pattern” while poo-pooing the old way of gluing. There is no group who tries to tell other carpenters what to do or what to call it. Carpentry nomenclature occurs naturally, on the job, not from some club of theory-only carpenters selling expensive coursework and books.
Indeed, it appears all other disciplines are quite sane, and it is only in software development where we have enough feeble-minded people that we have been taken in by a bunch of snake-oil salesmen selling made-up, out-of-the-blue, nonsense terminology like, say, “flyweight pattern.”
I repeat:
People thinking any forced pattern-name is important have been bamboozled. They have been fooled, just like people believing in the value of homeopathy, astrology, phrenology, or navel-gazing have been fooled.
Just like I’m sad to see people get harmed by using homeopathic “medicine” I’m greatly saddened to see software developers harming software and their profession by applying “pattern-names” and, worse, “pattern-thinking.”
This has got to be a cool place for a discussion that started 2-3 years ago to still be alive!
I’ve wondered about this thread based on my own experience and I can’t help but agree with Christer.
My first instinct was to wonder how labeling algorithms or data structures is any different than labeling patterns, but algorithms and data structures are much, much more concrete and applying them has very measurable results.
And while this may seem harsh and overly judgmental, in my experience, the best programmers/engineers are the ones that think in terms of data and algorithms. Those are also often the best architects, because they truly understsand what encapsulation means or they otherwise would not be able to seperate data and algorithms (and I don’t consider encapsulation to be an OOP-only concept, I say this because Christer is obviously not an OOP fan!).
By contrast, programmers that litter the code with pattern usage are usually the ones that cause the most trouble. They absolutely have to label whatever code they create with the pattern they picked from the book. Those are the programmers that love to explain how an Adapter is different than a Facade or a Decorator, etc, and who include the pattern names in whatever new classes they’ve created instead of just trying to name a class with something that captures its purpose. They also think that labeling something with a pattern makes it clean, and that it’s okay for WhateverAIObjectFactory to be known by the entire codebase because it’s recognized pattern. They go through great effort to systematically incorporate pattern names in their language and are completely unaware of the “real” problems other engineers are solving daily to make the game fast and ready for ship. To me, those guys are trouble.
Patterns exist, and whether they need to be labeled or not can be debated. All I can say is, when I see very explicit pattern usage, my alarms trigger and I pay special attention! And that’s a reflex that has been burnt in me over time.
—
Oh, just a minor note. One thing to that keeps coming up whenever subjects such as over-engineering, pattern bashing, etc, are in question, is the architecture vs performance/hardcore programmer comparision. I don’t know why, but there is this assumption that you either architect code well or make it fast, and that if it’s fast it must be unmaintainable (one of the earlier comments touched on that). I don’t know why that is. I am in favor of both architecture (not OOP style though, way more in the way of DOD) and obviously speed, but I consider them orthogonal problems. It is actually easier to optimize parts of the code when that code is well isolated, sticks to solving one thing, etc.
Cheers all.
Christer,
> I see you’re missing the point.
I don’t know. I might have missed the point you were trying to make, but I don’t think I’ve missed the point of design patterns.
> In carpentry, there is no group of “carpentry masters” who holds classes telling carpenters to use the
> ‘new’ “glue pattern” while poo-pooing the old way of gluing.
Oh I couldn’t agree with that more! Consultants trying to sell coursed on design patterns, scrum coaches, or certification businesses… pretty much all of them are money making machines with no particular benefit for the buyer, IMO.
I just think it’s well worth looking past that towards what these things they’re peddling actually /do/. As far as I am concerned, learning design patterns does not a better programmer make. But knowing the names of design patterns might make it easier to communicate large, abstract ideas from one programmer to the other. I see benefit in that.
Similarly, I’ve had excellent experiences – as well as terrible experiences – with applying scrum. No amount of scrum coaches I’ve talked to have /improved/ my experiences; on the other hand, the process itself can be applied successfully.
I don’t have a similarly good view of certifications. Sorry, they’re really the spawn of the devil ;)
Hope that makes my point a bit clearer.
You clearly have some strong feelings on this matter. :P In my opinion, you are overstating the matter somewhat. Babies… bathwater… yadda yadda.
That said, it sure is refreshing to find somebody stand up and publicly say denounce something that seems to have been so widely accepted without much apparent scrutiny. Even if I think you’re overstating the issue, I agree that more scrutiny is warranted before you go trying to memorize the design patterns book.
I actually teach a course that covers both Data Structures and Design Patterns. For my part, I try to focus on how these are both about recognizing the repeated patterns that come up in programming. We’ve all developed our own patterns over the years, and the wiser of us have managed to learn some tricks from each other. I try to stress for the students that these patterns are useful as options to consider, and only by understanding exactly how it works would you be able to apply them wisely. However, I see the blank stares in some of the faces, and I know they would rather just memorize “Plank” problems.
I’ll give your ideas more thought before I prepare my lecture notes the next time around.
Keep up the scrutiny!
Matt, there’s a big difference between the word “pattern” as it occurs in a dictionary and the word “pattern” as it is used in design-pattern contexts. It doesn’t seem you see the distinction as you claim we all develop patterns and that tricks are patterns. I couldn’t disagree more.
Do you call everyday life commonalities for “xxx pattern”, like you obviously do for a programming “design pattern?” Like, say, the “opening pattern” which can be applied to car doors, cans, and caps. I doubt you do. In fact, I doubt you label any commonalities outside of programming a pattern (in the “design pattern”-usage sense) even though you clearly could. Ask yourself why is what? No, really. Apply the opening pattern to your mind and consider deeply why we don’t see people talk about “design patterns” in carpentry (the “v-claw pattern”) or mathematics (the “substitution pattern”) or any other field and then draw the obvious conclusion.
And of course I’m overstating! The message would be muddled if I said that something is 98% bad. The message remains the same though: pattern terminology and usage thereof rots the brain.
BTW, data structures have nothing to do with design patterns, and vice versa. Why mix them? Data structures (like algorithms) are language independent, design patterns are language dependent. The former (two) is timeless knowledge. The latter is perishable knowledge (with a best-before date of 1994)!
I couldn’t agree more, 2018 now and the industry is totally plagued with design patterns.
Don’t reinvent the wheel, don’t think…. and when the shit hits the fan people always have the excuse
“oh the pattern was used wrongly”
“oh it was the fault of the guy that is not working here no more”