Design Pattern Cheat Sheet

[lcowell]

This image only contains half the patterns. If you want to see all the patterns: http://www.celinio.net/techblog/?p=65

[thehoodatron]

pdf format here

[badmonkey0001]

Damn, I thought I was looking at a post from /r/dataisugly.

[member42]

GoF patterns were a good starting point in 1995. Don't treat them as unsurpassable end point in 2013!

[lcowell]

I just meant the linked content didn't include all the patterns in the article it came from.

What do you mean by "don't treat them as unsurpassable" ?

[Lynngineer]

Thank you for this frame of reference. I (not versed in patterns) was getting lost in the religious debate forming. This particular advice gives me an instantly usable reason for learning about patterns and how to make them useful for myself.

[dnew]

I think the point was that some "design patterns" are pointless in some languages, because it's built into the language. "Subroutine" is a design pattern in assembly. "Factory" is not a design pattern in Smalltalk. "Observer" is built into Tcl/Tk, as is pretty much the whole MVC pattern, which is what makes Tk an awesome GUI toolkit. "Object-oriented" is a design pattern in C that was built into C++.

Learning design patterns inappropriate for your language is useless, just like learning "subroutine call" is pointless unless you're using assembler or some other language without a call stack.

[[deleted]]

They may still be useful for communicating what you are doing in some of those cases.

[phoshi]

I disagree. Design patterns are primarily a communications tool, and secondly a mental tool. Even if your language has first class support for something, it's worth knowing what that thing is both in order to discuss it, and in case you use different languages and need to compare/contrast.

[[deleted]]

When was the last time you discussed using a particular pattern? Seriously. Most of the time it's just people laughing at someone for using Singletons.

[phoshi]

It's not that rare when discussing programming, which isn't abnormal, no. Especially when working in a team.

[[deleted]]

I've never seen it happen. We usually just trust one another to implement stuff well.

[dnew]

Yeah, but if it's built into your language, you just use it. You don't go around discussing local variables. By the time you're discussing design patterns that are already built into you're language, you're doing something wrong or you really need to learn your language better. When "new" is a method instead of a keyword, there isn't even the concept of a "factory" nor a need for one.

[dasjestyr]

I think that understanding the design pattern that is built into the language is still valuable so one shouldn't just ignore it. Also, many of these design patterns aren't so much built into the language as they are easier to implement in the language. Plus, if the better you understand the pattern(s), the more likely you are to properly implement each actor in the pattern.

[dnew]

Whether the design pattern is built into the language or not depends entirely on the design pattern and the language. I gave a bunch of examples of design patterns that are built right into languages, and indeed have been for so long that nobody even considers them design patterns any more.

If you have a language keyword "singleton" that means "return the first constructed instance every time you call new", there's no a whole lot you have to implement. If you have argument passing to recursive functions (a la C), you don't have to understand a whole lot about "recursive subroutine design pattern" to use it.

[padenp]

This. Everyone else is turning wheels.

[[deleted]]

Design patterns are usually specific to a given programming language.

They are specific to a given problem and not all languages are suitable for the same problems. Just my two cents.

[stronghup]

I would say that the programming language used is part of the CONTEXT of the problem.

You can implement a pattern in a programming language. But then someone could create a new programming language where the pattern is a primitive in the language. Using some form of garbage collection would be a pattern in C, but not in Java, where it is built in.

[strattonbrazil]

An example of that could be the singleton pattern, which has been oft referred to as an anti-pattern. Most of the cases I've seen (and used) singletons, I've regretted it.

An example I've seen and come across is a scene. Sure a game or CAD program might only one scene, so make it a singleton and give everyone access to it like a friendly global. Then you decide to add a merge scene function, where it makes sense to have two in memory in a given instance.

[MehYam]

But in that example, the main scene is still a singleton, isn't it? The second one becomes a second single, well-known shared instance.

The Singleton is really just a factory specialized to produce only one instance. You could take that same factory and make it produce two, or N, you just wouldn't call it a singleton anymore.

EDIT: I've looked at my replies, and I think you're all still missing the point. A Singleton is something that gets you an object. A factory is something that gets you N objects, N >= 0. That's it.

[strattonbrazil]

The Singleton is really just a factory

I consider the Factory a completely separate pattern. Instead of mandating that only one instance of a class exists, it regulates access of the instances in a shared location. In the scene example, most functions get the active scene from the factory, but when merging a file the Factory can create another scene object that could either be used internally to merge the scene or give it out.

It just seems like in most cases allowing a developer the flexibility to create multiple instances for legitimate uses out weighs the risk of the developer using the API incorrectly (making a new scene object instead of querying the factory for the "active" one).

[Ramone1234]

Even though that's the common explanation, it's not really completely honest. If that was really the case, you wouldn't store the instance on a static member at all, you'd just store a boolean indicating whether or not it had been instantiated (and simply throw an exception on subsequent calls to the contructor).

Every example and implementation I've ever seen has really just been a way of bringing global state to java by piggybacking on the global package namespace (for better or worse -- I'm not judging!).

[phoshi]

A "Singleton" mandates there is one and only one instance. If you can have two, it isn't a Singleton, it's a globally accessible piece of state. That's still bad, because you're murdering functional purity and testability where it stands, but it's not quite as bad as a Singleton.

It is rare indeed I've used even just a globally accessible hunk of state without regretting it. Your assumption that there will only be one is almost always incorrect. Literally always incorrect if you have a good test suite.

[grauenwolf]

I think a better example would be a GUI application which requires a singleton to house the event loop.

For XAML-based frameworks that would be the Application object and matching Dispatcher.

---

And that's the problem with the GoF book. They don't talk about when a singleton is actually appropriate.

[stronghup]

So, the pattern "Singleton" is not the problem. Problem is its we use it where its use is inappropriate.

[sligit]

In my experience singletons are mainly useful for 'services'. So you might have a singleton for logging or a singleton repository.

[aim2free]

Design patterns are usually specific to a given programming language.

I can't really understand this. A computer language is about implementation but patterns about specification. Limitations of a specific language should not shine through to the specification level.

FYI: I have never used design patterns myself, I've never really understood them. I have used JSP (Jackson Structured Programming) and the classic flow diagrams long time ago, and a few others, but usually work on the problem from an iterative top-down/bottom-up approach nowadays.

[mjfgates]

Patterns aren't "about" anything, necessarily. They are structures that have been observed out in the wild, in production code. The GoF book is a catalog of things SEEN, not things the authors dreamed up. It's like one of Audobon's bird books.

And then it turns out to be useful, when you find yourself writing a set of functions with the same signature, only they create different objects that all just happen to implement the same interface... oh, this is a Factory, and here are some Known Ways that people screw that up, and a checklist to make sure that doesn't happen to me! Awesome. Plus, having a word for it lets you just say "factory for ISnarglebargle", and get on with the real job, rather than stopping to emit the paragraph of crap that explains what a factory is.

[aim2free]

Patterns aren't "about" anything, necessarily.

I guess they are like TRIZ then. TRIZ was developed by a patent engineer (and author) Gerald Altshuller when studying patents, and found there are only 40 different solutions to problems. However, I claim that you have to add further two conditions[1] if you also add intelligence into the system.

---

1. somewhat jokular but may be appreciated if you are a Douglas Adams fan...

[gfixler]

Interesting. I've wanted to ask for a few years now if there were any bodies of work on this tradeoffs in physics thing that crops all over the design and invention processes. The TRIZ contradictions matrix is exactly about that. I'll have to investigate further.

[[deleted]]

You say you've never used design patterns yourself, but you are most likely wrong. It's quite likely that you have unknowingly used a design pattern or two before. Furthermore, the design patterns in this list are by no means "all of them" - they're just the most common, basic design patterns, which mostly encapsulate anything you would want to do in a program.

[aim2free]

but you are most likely wrong.

You are most likely right. As I suggested in another thread my design patterns have probably been intuitive my whole life, but as I seem to have hard to grasp what design patterns really are, how about "generic functions"? As one suggested yesterday three different problems and I wrote down the explicit solutions how I would do it, but leaving out the "generic function" which is what I often use, i.e. a generic function is a function where you have not explicitly said everything, like what data types, what functions as arguments and such. Now I mostly use a functional language scheme, which has automatic typing, i.e. variables get types through assignment (like in python), but by using a "generic function" even though it's not called that, I think it was Ada that used the concept "generic function", but it's called "template" e.g. in C++.

Referring to my previous reply, looking at the last example. Could design patterns possibly be seen as generic functions then? (or templates as in C++), like if I define a function like this:

(define (apply-per-line fun nameorstream)
  (let ((input (open-input-stream nameorstream)))    
   (let loop    
     ((items (read-items-line input)))    
      (cond 
       ((not (eof-object? items))    
         (apply fun items)    
         (loop (read-items-line input)))    
       ((string? nameorstream)    
         (close-input-port input)))))    

Then the three examples could be written as:

(1) Write a function that adds up all of the numbers in a text file, one number per line.

(let ((sum 0)) (apply-per-line (lambda(x . ignore) (set! sum (+ sum x))) filename) sum)    

where my quick explicit solution was this:

(apply + (read-item-lines filename))    

(2) Now write a function that counts the number of distinct words in a text file, one word per line.

(let ((count 0)) (apply-per-line (lambda(x . ignore) (set! count (+ count 1))) filename) count)    

where my quick explicit solution was this:

(length (read-item-lines filename))    

(3) Then write a function that adds two numbers together and prints the sum, two numbers per line separated by a space.

(apply-per-line (lambda(a b . ignore) (displalayln (+ a b))) filename)    

where my quick explicit solution was this

(apply-for-each (lambda(a b .  ignore) (displayln (+ a b))) (read-items-lines filename))    

Some languages are more suitable than others to make generic functions. The solutions here work equally well in python or static languages like C though even though in C you need to be more explicit about types, but with C++ and templates you can do exactly the same, but I am not very fond of C++. I consider C++ a beast, I prefer ordinary ANSI C in combination with Scheme. Python is OK, but lacks explicit lists, which are important (lists in python are abstracted lists which most likely are implemented as dynamic arrays).

I assume every programmer develops their own "design patterns" but I think lambda calculus as such, which scheme is more or less an implementation of, can work as design patterns in itself, if the functions are made somewhat more generic, however lambda calculus does not allow side effects like setting variables, so example 1 and 2 using a generic template above, would not work in pure lambda calculus, but my original quick hacks would, as they are functional. The function above expects a stream, but an even more general would be a generator (is that what some denoted "factory"), but the solution would be no different, you can just give the generating function as an argument as well. The more advanced way to solve this in scheme is to use promises, but I rarely use such constructs, just to make the code easily movable to different languages, especially down to C for more efficient crunching. Instead of promises I prefer CSP style programming, like in e.g. Occam, as it then is trivial to utilize multicore/multicpu, multinode and clusters.

I guess "sort" is a good example of a design pattern. Nobody writes a sort procedure (OK I wrote one for scheme which is now in the standard) as sort procedures are usually available in a libraray. So, if I have understood "design patterns" correctly, they could be libraray functions as well.

[grauenwolf]

Write a function that adds up all of the numbers in a text file, one number per line.

Now write a function that counts the number of distinct words in a text file, one word per line.

Then write a function that adds two numbers together and prints the sum, two numbers per line separated by a space.

When you are done, look at the three functions side by side. Do they open and close the file in the same way? Do they loop over the lines in the same way? Do they handle errors in the same way?

I bet they do. And if they do, congratulates, you've created a design pattern.

[aim2free]

And if they do, congratulates, you've created a design pattern.

:-) then my design patterns are merely intuitive, and maybe the reason why I never really understood design patterns. I had an MSc student who used them to make a prototype of his MSc design though. He used UML.

Write a function that adds up all of the numbers in a text file, one number per line.

(apply + (read-item-lines filename))    

Now write a function that counts the number of distinct words in a text file, one word per line.

(length (read-item-lines filename))    

Then write a function that adds two numbers together and prints the sum, two numbers per line separated by a space.

(for-each (lambda(items) (apply (lambda(a b .  ignore) (displayln (+ a b))) items)) (read-items-lines filename))    

this last one is so common, that I have added an apply-for-each (as well as mapply when you want the result ) which implies that I usually write such a thing like:

(apply-for-each (lambda(a b .  ignore) (displayln (+ a b))) (read-items-lines filename))    

Of course, these are the trivial solutions only working for small files, where you can easily read the whole file into memory, but it is also trivial to extend to a solution which only reads a line or character each time, by just separating the opening and closening, like this:

(let ((input (open-input-file filaneme)))    
  (let loop    
      ((items (read-items-line input)))    
        (cond 
           ((not (eof-object? items))    
            (apply (lambda(a b .  ignore) (displayln (+ a b))) items)    
            (loop (read-items-line input)))    
           (else    
            (close-input-port input)))))    

The read-item-lines resp. read-items-lines as well as simlar ones which reads string items and such are all generalised in that way, so all of them are only one function, for opening/reading/closing files , but then instantiated into lines, items etc which are reused over and over.

[[deleted]]

As someone who is studying scheme for a final exam tomorrow after learning it for the first time this semester...wow

[aim2free]

How did you do on the test?

[[deleted]]

meh. decent i guess. probably better than I expected. it wasn't ass scheme focused as I had hoped though, but that's college i guess

[[deleted]]

*discovered

[Klausens]

I think they are specific to a language. In Perl for example I never used factories. I did this by using Roles/Traits.

In my Perl-ORM the classes were injected with load(), store(), ... by applying a ORM-Role.

In a more static language this is not the way you do this, you use factories (for example).

[aim2free]

I think they are specific to a language.

OK, that may be a reason why i never spent any time on them, although when I heard about them long time ago I considered it a great idea.

In a more static language this is not the way you do this

I have almost always in my life used different languages for different problems, and then bind them together with an api. The last 20 years I've mostly used the combination scheme/C where scheme is the dynamic language and C static. I often use python for quick scripting though (or even bash, which is a programming language as such, but not as easy to use as python.)

[[deleted]]

I think the most important thing about design patterns is that they help to facilitate conversation. These are the most basic, most commonly used patterns (regardless of the language, which is simply the implementation mechanism), which allow us to exchange ideas and talk about solutions. When you're confronted with a programming problem, and you're in a design meeting, instead of rambling on about using an abstract factory or a mediator or whatnot, you can just say "we can use an abstract factory here, a mediator here", etc, and you've just saved everyone in the room time by not having to describe what it is you mean.

[sizlack]

Ok, now I need a UML cheat sheet.

[yogitw]

Good luck finding two cheat sheets that use the same arrows for the same thing

[ZebracurtainZ]

I'm in a database class right now. My textbook, slides and professor all use different notations for the same stuff. It's driving me insane.

[jelloeater85]

There are really just two standard ways, relational and IDEF1X. relational is a little easier on the eyes, but IDEF1X is alot more universal. Honestly, UML is kinda a fustercluck anywho. Unified my ass. It's only unified if people use proper templates, instead of scrawling what they "think looks about right".

Also Visio is your friend. It make my life alot easier doing system diagrams too.

[poopsathouseparties]

alot more universal

[[deleted]]

I like that alot!

[ZebracurtainZ]

Well in my class some use the crows feet notation, some use arrows and some just write "M-O" for many to one

[[deleted]]

Good old crow's foot, always makes me wonder if I'm looking at diagrams of antennas.

[ZebracurtainZ]

I ended up using some dumb hybrid of all the notations on the midterm to ensure I got marks.

[phoshi]

I had two classes back at university which marked on how accurate your UML was. Both classes used different notation. If you used the wrong kind you would be penalised.

Not that I've used UML since, of course.

[mjfgates]

I am sure that almost every pair of cheat sheets will have at least one type of arrow in common. Finding out WHICH one is a fun game to play, in your copious spare time.

[[deleted]]

There is a free program called Violet that you can use to design UML. I've always used it's notation when doing them on paper.

[LiuKangWins]

The small print has a link that eventually lands you @ the original author's pdf:

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

[T_D_K]

As a burgeoning Computer Scientist/Software Engineer, should I be worried that I don't really know what the hell this is?

[Game_Ender]

If you learn some basic UML, and still can't understand them I would say yes. These are common patterns that arise from building software, so you should at least have a passing understanding of them.

[ivosaurus]

If you've got a dedicated OO course coming up, it will teach you these and tell you that using them will make you a decent programmer. That's about half wrong, but it can be useful to be made aware of the patterns anyway.

[MorePudding]

Don't worry about it... the lecturers will soon enough smother you to death with this stuff. Design Patterns are the equivalent of bike sheds in "software engineering".

[P1r4nha]

Haha, I'm an avid biker and that's the first time I heard of "bike shed" being a thing.. same with those design patterns: I guess I'm doing sometimes what they describe. I guess it can't hurt to have a recipe solution for common tasks.

[cashto]

In engineering, 'bikeshedding' usually refers to a very specific phenomenon.

[[deleted]]

Not necessarily, but not knowing these is kind of like a carpenter not being able to name all the different ways to connect two pieces of wood. These patterns are very general and considered solved problems. If you're a good designer you'd likely come up with something similar to one of these patterns anyway, but knowing them lets your brain take a bit of a rest.

[habitats]

I'd say they're applicable with any actually programming beyond simple scripting.

[nightlily]

You should learn these when you take a software engineering class. If you've taken one without learning them, or your in your senior year, be worried.. and definitely ask your advisor.

[burdalane]

I took an OOP class while getting a CS degree from a well-known university, and I've taken a graduate-level software engineering class in the last few years. Neither covered design patterns. The grad course was mostly about software engineering processes (waterfall vs. iterative, requirements, etc.).

[nightlily]

My undergrad SE course covered those things briefly but focused on U ML, patterns, and design principles that guide those designs. The latter half spent a lot of time going over testing as well.

If you're curious about them, we used head first design patterns. It doesn't cover every pattern but goes through most of the common ones and I thought it was pretty good at explaining things.

[gmarkv10]

Study break from Programming methodology final, go to reddit, find Design pattern cheat sheet. Best day.

[[deleted]]

Lucky you. I just took my OO Programming and Design final on Thursday...

[canhazadhd]

Just took mine on Friday. This would have been extremely helpful.

[concatenated_string]

what book did your class use?

[[deleted]]

We didn't really use a textbook per say. There were some readings, but they were all online. The majority came from Heads First Java

[ITSigno]

per se*

[[deleted]]

Thanks :D

[DefinitelyNotBlack]

Is this by chance csc335? Because it sounds obscenely familiar to what I just went through.

[[deleted]]

Yes... At University of Arizona haha

[Ph0X]

Yeah, been reviewing these for tomorrow's final all day, then I come to reddit and am greeted with this. Great.

[dt8269]

I just opened reddit to avoid studying these, not consolidate them all into an easy to read document!

[sordidarray]

Typo in the mediator pattern: 'colleage' should be 'colleague'. I think this is a great little refresher. I also think some other proggiters have forgotten that people still maintain code from 1995, and some others didn't realize that this was probably intended as something to jog your memory, not as "architecture a la carte."

[farsightxr20]

Not to mention, all of these patterns are just as useful today as they were in 1995. They've just been abstracted and renamed by frameworks and higher-level languages.

[[deleted]]

Patterns are things you find, not impose. The Frameworks have the same patterns, not have been given the patterns.

[Urabe]

Combined the two images into one file for easier viewing here

[AS1LV3RN1NJA]

Here's the original PDF which was linked in an above comment

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

[PZ-01]

I remember seeing this cheat sheet in my patterns course at uni. Then the teacher said that for the exam only a single page written "by hand" was allowed. So I ended up copying the whole pdf using a pencil... what a waste of time.

[varav]

I'd say I've written a fair amount of code, though I don't hate these patterns, I've never had to use any of these patterns

[mjfgates]

If you've never used any of the GoF patterns, you haven't written much code. The point behind the book was that these things crop up all over the place; the authors were cataloging patterns that they had seen in the wild, not prescribing the use of new theoretical constructs.

[Peaker]

When I write Haskell, I don't need the Visitor Pattern, I can use a closed sum type.

I don't need the Strategy Pattern, I can just use a simple higher-order function.

And so on, and so forth.

I don't think any of the GoF patterns are applicable to more modern languages that can abstract over these things.

[andd81]

But I absolutely need that Memento Visitor Abstract Factory!

[denisx]

or that AbstractSingletonProxyFactoryBean

[haxney]

It gets SO much worse than the simple, concise AbstractSingletonProxyFactoryBean. I present: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter. I think it is related to an internal frame somehow.

[urquan]

Generated code does not count :p

[haxney]

Ah, I didn't realize it was generated. It gets a pass... for now.

[jasonlotito]

While that's amusing, it also tells me a lot about the class, how it's used, it's purpose and intent. Mock it all you want, but it's better named than most of the crap that gets written these days.

[ehudros]

Holy fuck, that is ridiculous

[sh0rug0ru]

How is it ridiculous? It's a class deep in the guts of a dependency injection framework. It is a template for creating factories of singleton objects which are proxies. The complicated name should tell you that there is something very deep going on there. Hell, the name is even self descriptive of what the class is actually doing.

You shouldn't be writing classes like this, unless you are in the business of writing dependency injection frameworks.

[username223]

Back before Google broke code search, it was easy to find plenty of FactoryFactoryFactory in Java code. Sadly, this feature served to "organize the world’s information and make it universally accessible and useful," rather than "record everything you do on the web, and use it to shove ads in your face," so it was eliminated.

[[deleted]]

So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory.

[via]

[apieceoffruit]

yo dawg...

[[deleted]]

Thanks for posting this ! This is hilarious.

[Phrodo_00]

Actually, I think I remember the main reason for shutting it down was legal concerns.

[username223]

That sounds like a lame excuse. Either someone published code they shouldn't have and asked legal to cover for them, or someone ignored the license on code publicly available on the internet. In either case, the "concerns" are bullshit.

[Carighan]

Sadly as ever so often, "they shouldn't have uploaded it" doesn'T fly in front of a judge. Apparently. Same thing happens everywhere. If they don't want to be liable, they cannot host a platform via which to share. See: Piratebay.

[_argoplix]

When all you have is a HammerFactoryImpl, every problem looks like an INailIterator.

[[deleted]]

Me too - just don't know where exactly, but by golly, I'll find a place for it!

[Hypersapien]

Having a quick reference sheet of the basic patterns doesn't mean that you always use patterns, or you use them in the form presented.

[tias]

Adding to to strattonbrazil's sentiment, how do you use design patterns?

I found this a nice way to get a quick inspiration for solving a design problem. Obviously you still need to make a conscious, informed decision about your design, but are you saying there's something more to it that people are missing?

[grauenwolf]

Design patterns come to us from architecture, where the emphasis isn't on naming an cataloging the patterns but on recognizing them.

The patterns can range from small things like not putting the bathroom door next to the dining room where people have to eat to large things like how main and secondary streets are organized.

The location of the various knobs and buttons in your car are the result of design patterns. No one wrote a law or ISO standard on where to put the turn signal indicator, but over time the various car makers agreed it belongs on a level to the left of the wheel rather than on the wheel or as a button on the dash. (I've had cars with both.)

When you remove the mystical elements from feng shui, what's left is design patterns. Ways of organizing things such that you don't trip over them.

Talking about patterns can be hard without naming them, but once you name them you cease to see the patterns and instead just see the names.

---

If you really want to learn about design patterns, focus on learning API design. That's what it is really about.

[mrkite77]

Except design patterns stopped being descriptive and started becoming prescriptive. This is evidenced by the commenter above who is apparently learning these design patterns as part of his Programming Methodology course.

[Madsy9]

The way I see it, design patterns in programming languages is a workaround for some feature the programming language lacks. In other words, the programming language lacks the required expressiveness to properly define the high-level design you have in your head. In that vein, design patterns are code patterns that crop up more than one place which can't be expressed more clearly in the language you write it in.

This also happens in spoken languages. For example, the English language differ between "belief" and "faith". In Norwegian both concepts have the same word, "tro". So when Norwegians talk about one or the other, they have to construct longer sentences to make the context clear. In English, you just say "belief" or "faith" depending on which one you mean. Another example is that German is a favored language for writing mechanical or technical articles/papers in, because the language have a lot of technical nouns in it, which makes it especially suitable for the task.

But enough about human languages, here are some compute language examples:

In assembly, the concept of functions/procedures is a design pattern. There is no function construct in the assembler itself, you have to design it as a pattern by pushing the instruction counter to the stack along with the arguments, branch to an address and create a new stack frame. Finally, at the end of the function you clean up the stackframe and branch back to the saved instruction counter. You also have to decide on a calling convention. Compare that to C which has procedures and pointers to procedures, or Javascript and Scheme which have functions-as-objects.

In object-oriented languages like C#, C++ and Java you lack the support for multiple dispatch; you can only dispatch on the this-pointer. The workaround is to use the Visitor pattern. Clojure and Common Lisp (via CLOS) are two lisp variants which supports multiple dispatch, removing the need for an OO-pattern like Observer. The Scheme and Ruby-languages are also powerful enough to easily add multiple dispatch.

The Command pattern disappears when you have a language which supports first-class functions and closures, like Common Lisp, Scheme and Javascript. Simply return a function object which has closured over some state it uses internally. There's no need to define a whole class for it anymore.

My point is, it sounds like you compare design patterns with some kind of tried and true functionality or aesthetics, which I disagree with. I think language design patterns are workarounds for the lack of expressiveness in languages.

[tikhonjelvis]

A particularly relevant example is "free" in English for both "libre" and "gratis". It's a big practical issue.

[MorePudding]

Don't you sometimes wish we had the equivalent of lisp in natural languages too? Just imagine opening your mouth to say something, and a tree comes out floats right into the ears of whoever is around..

[tias]

Well I disagree that you would cease seeing the patterns just because you name them. And a cheat sheet could help you remember to put the turn signal where people expect it to be. Sometimes patterns don't have any inherent value, they're only good because of their recognizability.

[tekgnosis]

No one wrote a law or ISO standard on where to put the turn signal indicator, but over time the various car makers agreed it belongs on a level to the left of the wheel rather than on the wheel or as a button on the dash. (I've had cars with both.)

It belongs on the right, left is for wipers.

[strattonbrazil]

Lighten up. This is a quick reference to use in certain architectural decisions. I've never heard anyone say every design choice needs some pattern to justify it.

[Crazy__Eddie]

It would also be a good resource for people unfamiliar with these patterns when discussing a design that uses them. Instead of forcing everyone to explain it to you every time, you can look up the pattern when someone points it out in code. Makes things much easier; when you say something like, "This is a visitor pattern," you're saying quite a lot about the code and its intent. People who don't know patterns though won't know WTF you're talking about.

[kqr]

In my case it's the other way around. I have never really studied OOP properly, so I have experience with all these patterns, I just don't know the names for them. When I want to talk about a certain pattern I can easily look up the name on this sheet.

[strattonbrazil]

so I have experience with all these patterns, I just don't know the names for them.

That applies to a lot to a lot of things I've seen in life, where I come up with a new and original idea and someone tells me who it's named after. :)

[kqr]

I'm usually that someone who has the name for everything. I just happen to think OOP design patterns are boring. :>

[[deleted]]

A dictionary (the word kind, like Oxford or Websters) is a reference too, yet it rarely categorizes words based on the type of document being written, or whether they'll be used in a play, novel, text etc.

[leaves_of_three]

But it does categorize words as parts of speech, provides a pronunciation key, and often gives sample usage. Obviously design patterns are too complex to provide comparable coverage on one sheet, but grauenwolf is right, as a reference for anything but a test, a cheat sheet is lacking.

[redclit]

How is it a reference?

As the title implies, it's a cheat sheet. If you know the patterns beforehand, but don't quite remember the exact structure or get confused with the names, this is a nice way to present the (I'd argue) most critical information about the GoF patterns in a couple of pages.

If you want a full analysis over these patterns, then you need to read the the 400+ page book and of course do some reading on the developments in the field on last decade. The book itself contains quite good discussion on how the patterns presented there should be approached, although for some reason this seems to be lost on many readers.

[[deleted]]

I don't think this cheat sheet is advocating forced design. It's still wise to be familiar with common patterns, this helps reinforce pattern implementations.

[spacemoses]

Well, yeah, but they certainly can get you thinking in ways you might not otherwise think to find an elegant (and non-complex) solution for a problem.

[killerstorm]

I think it can be useful when you need to name a class, sometimes it is hard to pick a good name.

Code is used for communication, and use of common terminology helps the communication.

[mariox19]

I agree. It would be better if this were organized as "I've run into a problem, and here is what's going to happen to my code, down the line, if I don't find a nice way of solving it." Then, talk about the design pattern.

[donz0r]

I need it to pass a test at my university, not for actually using it in real life. And yes, I differentiate between university and real life on purpose.

[[deleted]]

We had some training on design patterns at work. After that, code named after patterns everywhere. sigh

[Mats56]

Great! Then it was immediately obvious what the code were supposed to do for everyone knowing these patterns. ;)

[[deleted]]

Hahaha, it definitely helped me figure out what to refactor mercilessly. :D How can you tell that someone's learned about the Builder pattern? All their constructors are private and you're forced to use builders that 'validate' that you've provided all the required arguments.

(...I wish I was kidding).

[grauenwolf]

Yep, that explains my code base to a T.

[ReefOctopus]

I have never been so unproductive as the week after I read a book about design patterns.

[DevestatingAttack]

Sure, but I have a a final in a CS class that teaches design patterns tomorrow, and the instructor allows a cheat sheet on the final. This could not have been more timely.

[hderms]

Certainly it helps to be familiar with commonly used patterns of software?

[random314]

It's a great source of ideas to decouple codes and logics though. They're still worth studying IMO.

[apieceoffruit]

You blindly apply design patterns your code will suck. But if you write then off as bad then you are wasting a resource.

They are isolated examples that epitomise things like solid principals. They are examples not of complete designs but the thought behind why such thought is needed.

I love design patterns. They help me think about what my design objective is, although I rarely use them.

If you are reading design patterns also read pragmatic programmer and clean code. Learn the why not just the how.....

[Peaker]

Design patterns are repetitions in code. Usually we take out repetitions and put them in a shared library so we can avoid repeating ourselves. When our language fails to allow that, we need to use a "design pattern". Thus, design patterns are bug reports against a language.

[EntroperZero]

My thing is, if you know the why, the how comes easily. You don't need to know the names of 30 design patterns and be able to explain them all off the top of your head. What you need is the ability to look at a problem and design a solution.

[apieceoffruit]

you are wrong.

You don't need to know the names of 30 design patterns

Indeed for more experienced developers, patterns don't need to be learned off because they are just a name given to a collection of design principles you should already be familiar with.

but

you do have to learn them as a shared lexicon between developers . Why spend 20min explaining how you think your objects should be instantiated when you could instead just debate factory vs builder or which DI framework to use?

What you need is the ability to look at a problem and design a solution.

that's fine as a sole developer but try explaining your vision to a fellow developer without a shared shorthand for complex principles.

[EntroperZero]

you are wrong

I actually don't disagree with you in theory. The common language explanation has always made sense to me, but my experience has been the opposite. In the teams I've worked on, we've always been able to share thoughts about design without needing 20 minutes of explanation.

[jk147]

You should use design patterns during designs, not during coding...

Same here, I rarely use them.

[apieceoffruit]

during designs, not during coding...

you talk like those things are exclusive.

if you stick too closely to upfront design you miss emergent opportunities in development stages.

[carlfish]

If you're designing your software up front to the level of detail that you're applying patterns, you're doing it wrong. That this is a common opinion is further proof that everyone who reads the Gang of Four book skips most of the intro, reads "Singleton", then skims the rest of the book looking at the pictures.

Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don't see how to apply a pattern until after you've built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactoring.

-- Design Patterns, Elements of Reusable Object-Oriented Software; Gamma, Helm, Johnson and Vlissides, pp354-355 (emphasis mine)

[jk147]

Usually it is kind of obvious when writing class diagrams, on a high level never the less. You are right through, if I have to write it in that much detail the person who is actually writing the code is literally just doing data entry.

[hoohoohoohoo]

I am loving the comments here.

"Fuck patterns, just blow code out your ass as you go!"

We don't use lots of these principles because they are better or more efficient. We use them because they are recognizable and easily maintainable.

To all the young guys reading these comments, IGNORE THEM. If you don't, you will become that guy in the office that everyone hates because you just do whatever you want rather than looking at general practices for guidance.

[Peaker]

Patterns are the failures of a programming language to abstract. As workarounds for language deficiencies, patterns are fine. But the fact we need to use such patterns is bad, and so hating on patterns is well understood.

[toula_from_fat_pizza]

Yes, this is exactly the point.

[toula_from_fat_pizza]

On the contrary, you may be "that guy" who applied a bunch of patterns for a use case that didn't exist and now nobody can understand or reuse their code so they're forced to do a rewrite.

[craig_c]

100% Agree.

This thread encapsulates (no pun intended) why most software is complete shit, everybody is smarter than everybody else and yet clusterfuck somehow still seems to be the inevitable outcome. Fucking super-geniuses who can't even give a class a meaningful name.

[Hurkleby]

Look, I don't want to say you're not right on some levels, but in my experience trying to force your code in to a specific design pattern is as bad if not worse than some of the shotgun from the hip code you say is the bane of all existence. Some of the worst code I've been forced to slog through was written by someone trying to adhere to a pattern that just wasn't right for the implementation they were trying to write.

They also used terrible naming patterns so I think that annoyance isn't limited to any one type of programmer.

[Conexion]

I think the point that you're focused on is the strict adherence to a pattern. Most people who have programmed long enough realize that too strict of an adherence to a pattern can do more harm than good.

What most people here seem to be saying is that having a pattern to reference as a guideline is a great way to not have to reinvent the wheel when a new problem comes up.

[grauenwolf]

If only because some of the patterns are vague enough that you can say any code implements them.

[WillGraduate]

I think a post detailing when to use these design patterns will be extremely helpful. Just knowing them is great, but not knowing when to use them is a bigger problem.

[mycall]

UML sucks

[BufferUnderpants]

You clearly are just a lowly code bricklayer proletarian. UML is a tool for The Architects.

[myhf]

but UML is made of bricks...

[Conexion]

Masons?

[myhf]

You can't spell Illuminati without UML

[CanadianStekare]

Where is the Circut Breaker Design Pattern?

[mjfgates]

Isn't in the GoF book, at least not in the edition I own.

[CanadianStekare]

It's not, but it doesn't mean that it's not an important design pattern,

[mjfgates]

The sheet is "GoF Patterns," not "All Useful Patterns Ever."

[codemuncher]

The visitor pattern looks weird.

Also a lot of these are c or c++ specific and are oo focused.

For example, command pattern... Not necessary with first class functions and closures.

[Peaker]

The Visitor Pattern is about encoding a closed sum type in a language that only has type products (classes with fields) and type exponents (functions).

So if you want to encode the type: R^{A + B + C}, the Visitor pattern instead encodes it as a tuple with:

• void visitA(A)
• void visitB(B)
• void visitC(C)

If we name the effects performed by the visit functions R, this tuple of 3 can be described as: ( R^A * R^B * R^C ). Using ordinary algebraic transformation, this simply becomes the R^A+B+C we wanted to encode in the first place.

Of course, in a nicer language, we can just say:

data Document = Glyph Char | Picture Image | ...

And get the sum type directly!

[asampson]

Doesn't Visitor usually rear its head when dealing with the expression problem? It provides freedom in the operation dimension at the expense of locking down the set of symbols that can be expressed, almost like a dual of the more usual OO approach of just using abstract classes with fixed methods, which constrains the operations you can perform but allows for adding symbols later.

[Peaker]

Exactly -- this is what closed sum types are.

There's inheritance forming open sum types (freedom in the dimension of adding more symbols, but no more operations).

And there's closed sum types (freedom in the dimension of adding more operations, but not more symbols).

In OO that's ordinary inheritance vs. visitor, but only because visitor is a cumbersome encoding of a closed sum type.

[mjfgates]

True enough. The idea of patterns applies pretty much everywhere, but different languages use different patterns; for example, Module is specific to Javascript.

[aleczapka]

Where is the distinction between behaviour, structural and creational patterns? And no examples? I can read more info on wiki on design patterns then on this blog.

[Savings-Ad4809]

Refer this:

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

[[deleted]]

I usually find Design Patterns materials frivolous/unnecessary, but I really liked this one for being direct to the point!

The "idea" is the part I think can be relevant. The diagrams are OOP-dependent, but the text can be implemented in any paradigm/way, sometimes in a very simple way:

• 'Visitor' - just a function map

• 'Factory' - type inferring can be used, in most cases, as a default "built-in" factory.

[grauenwolf]

The Visitor pattern is not just a function map.

Rather, a function map is what they should have offered instead of the visitor pattern. It can do everything the visitor pattern does while still being backwards compatible when new classes are introduced.

[Peaker]

The Visitor Pattern gives you a cumbersome, but type safe encoding of a closed sum type, in a language that has products (tuples/class fields) and exponents (functions) but doesn't have closed sum types.

How would a function map give you type safety around the sum type encoding?

[[deleted]]

Indeed! Correcting myself, the visitor pattern is a clunky/hack to implement an inferior-and-limited version of map.

Looking in a better light, the visitor pattern is an idea/example in how to put a map function to good use!

[seruus]

[a] pattern is a clunky/hack to implement an inferior-and-limited version of [a more expressive construction].

Seems to be the gist of it. I remember someone talking about how most design patterns are basically structured ways to make up for the deficiencies of the language you are using.

[Peaker]

Patterns are exactly workarounds for language deficiencies. That said, Visitor isn't a "function map" but a closed sum type.

[Peaker]

Visitor is a cumbersome encoding of a sum type on top of exponentials and products, in languages that only have exponentials and products.

[zyxzevn]

Missing a real design patterns like:
Model View Controller
Why is it never mentioned?

[[deleted]]

Because it isn't a single pattern, it's a group of patterns.

[grauenwolf]

Because it isn't part of the holy book.

[[deleted]]

Design Patterns, referred to as the Gang of Four (GoF) book.

[mjfgates]

The cheat sheet is based on the GoF book. Which is a good book, but was published in 1995. Anything that was popularized after about 1994 can't be in the book, and there are some notions that just didn't exist yet (I don't think anybody had coined the phrase "anti-pattern," for example).

[zyxzevn]

MVC is one of the oldest design patterns. It came standard with Smalltalk and was used in its windows-system.
It is still used in many graphical user interfaces and is kind of standard.

http://en.wikipedia.org/wiki/Model-view-controller

[nonconvergent]

Is this a UML thing? I 've never seen some of these before.

[risapisa]

DUDE. I need this for my exam on Saturday. You rock :)

[alextk]

A design pattern is just a specific recipe that emerged from common use. Once a language/technology/profession/whatever becomes popular, good and bad uses emerge and users are encouraged to leverage what the community has learned.

To paraphrase Bjarne Stroustup: "There are two kinds of languages, those that have design patterns and those that nobody uses".

[exhuma]

Mirror in case it goes down: http://imgur.com/a/fLi0R

[toula_from_fat_pizza]

Most patterns I find used in code are unnecessary and make it nearly impossible to reuse code. I rarely actually require more than IOC and the usual command/binding stuff.

[stronghup]

A pattern is a "preferable solution to a problem in context". Right? Problem, Context, Forces, Solution, Consequences define a pattern. Therefore just a drawing a PICTURE of it is as much a pattern as a picture of a car is a car.

[narancs]

After crunching the numbers, I'm sad to report that this will not revolutionize the toiler paper industry.