Design Patterns – A comprehensible guide

https://github.com/kamranahmedse/design-patterns-for-humans/blob/master/README.md

268 110 9 years ago

TillE• 9 years ago

I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived.

Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.

sna1l• 9 years ago

It would be great if there was a resource with real world examples, since I have this exact same problem.

jneal• 9 years ago

I'd say when I was first learning about many of the design patterns, this was my biggest hurdle as well. The examples and analogies were unrelated to real-world scenarios and didn't do much to help me understand the concepts.

It wasn't until I came up with my own real-world examples that were specific to my domain and really applied the design patterns in practice that I really started to understand everything. I don't think it's really the real-world example that helped so much as the actual process it took to arrive at an implementation.

macintux• 9 years ago

Disclaimer: I haven't looked at it in many years, but I seem to recall Fowler's Enterprise Patterns[1], while covering a higher layer of abstraction, grounded in real world problems.

[1] https://www.martinfowler.com/articles/enterprisePatterns.htm...

keithnz• 9 years ago

Grady booch was working on a "handbook of software architecture". What he was doing is go to companies and look at how systems have been built.

there's a presentation https://pdfs.semanticscholar.org/242a/61777fd7f0f7ded8d9326e...

He was looking at the structure, and the patterns in real world systems

rezashirazian2• 9 years ago

I implemented some of the more popular design patterns using more real life like examples. You might find them useful :

https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

callumprentice• 9 years ago

Reminds me of physics books from college where they might say "a horse is approaching a barn door at relativist speeds..." - always seemed much too contrived and I'd maybe have preferred "an exotic particle is moving towards an electron at...".

danielbarla• 9 years ago

I know I might be in the minority, but this kind of stuff doesn't bother me at all. The silly abstraction is essentially there to highlight which part of the problem / lesson you should be focusing on, and to stop you from going off on a tangent and getting bogged down in the gritty details.

Going with your exotic particle example, once they've framed the problem like that, there's an implied expectation of reality and correctness which is likely going to be missing from an introductory example.

Sir_Cmpwn• 9 years ago

The physical behavior of a horse is better understood than that of an electron and might make it easier to consider the subject at hand, though. We know what path the horse will travel and we know that when the horse reaches the barn, it will go splat (well, in this case the barn will go splat). There are several competing theories that could describe what happens with the electron and the exotic particle, though.

Also, it's fun to picture a horse travelling at relatavistic speeds :)

Jugurtha• 9 years ago

Check out Soviet books. You don't get the feeling the authors assume you're mentally challenged as you do in most other books.

This is all fun, but I think knowing how to apply knowledge is an important part. Many don't have a problem with electrons and pulleys, but put a real world example and they're out of their wits compared to someone who uses to dead reckoning.

https://mirtitles.org/

There's an interesting book on the site by Belikov: "General Methods for Solving Physics Problems".

joe_the_user• 9 years ago

It's not so much they're contrived but that starting with real world, physical examples is ultimately not helpful. OO objects are not physical objects and the sooner someone realizes this, the better.

hackits5• 9 years ago

Questions like “Which paradigm is better for modeling the real world” are virtually meaningless. The choice depends upon how the world is conceptualized, and what additional properties are expected of the model.

rezashirazian2• 9 years ago

A while ago, as an exercise I decided to implement some of the more popular design patterns in Swift, using more real life like examples. If you're interested you can find it here: https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

JamesBarney• 9 years ago

Right, stop making pained carpentry analogies. I couldn't build a wooden box to save my life, but I do have 7 years of professional software experience. I would much prefer if you drew from that experience.

Traubenfuchs• 9 years ago

Be careful what you wish for. We can always take the "zoo animals with varying legs" classes and interfaces out of the box again.

morbidhawk• 9 years ago

In addition to contrived examples impairing comprehension I even think a real-world example fails to help the reader capture the most important piece of information about design patterns, and that's the context around when to use them. Giving a worked-out example while teaching the concept has the limitation that the reader didn't discover the pattern themselves in code, instead it was ripped out of a code base and handed to them without context of its use. And instead of seeing it as an option that was selected to be used in a particular code scenario it is instead presented as a fully-worked solution that can be plugged in anywhere and describing when to use it in words isn't as effective as discovering it being used in a code base you've been learning from.

Quite frankly, in my radical opinion, I think learning about programming through reading about it (books, articles, blog posts, etc) isn't very useful once you are past being a beginning programmer. To be a better programmer reading code is the only way I've seen good progress with learning new abilities that don't cause me to over-engineer my own solutions. This might not work for everyone but for me reading code daily has been a silver bullet to programming knowledge that a book or design pattern article could never capture for me.

ilugaslifg2• 9 years ago

Object-oriented programming is a disease, and I can't wait until we're collectively done with it.

All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language.

The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and carry around in their heads, is a crime against our profession.

dang3• 9 years ago

This sort of heated rant makes for a bad HN comment, regardless of how correct your views are. It leads to flamewars, which we don't want here, so please don't post like this.

Even if you took out the rantiness, the comment is still too generic to actually be saying anything. So to convert it to a good HN comment, you would need to both de-flamebait it and add information (e.g. specific examples).

catshirt3• 9 years ago

i enjoyed the conviction.

iak8god2• 9 years ago

I dislike OOP. It's my least favorite paradigm. The "objects-first" approach to teaching programming was such a bad idea.

All that said, there is a place for OOP. And while a world without OOP would be a better place than a world without FP (if we had to choose), I think you'll be waiting a looong time for that world to materialize.

cmoscoso• 9 years ago

That world is already here, just not evenly distributed.

LyndsySimon3• 9 years ago

I've spent the vast majority of my career in OO-centric projects, but between my experience in Javascript and Clojure I've begun to see OO as FP with a layer of syntactic sugar. Objects are just closures at the end of the day, after all.

The mental fun was when it dawned on me that most of the benefit from the FP I was falling in love with was coming not from FP itself, but from the liberal use of immutability... and that OOP can be written in a way that similarly embraces immutability.

I don't know if my OO code got better or worse from an outside perspective once I realized that, but it certainly made it easier for me to reason about my experimental side projects.

dkn• 9 years ago

arcane toxic names

Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns.

Just an inflammatory comment.

mavelikara4• 9 years ago

Yes, and quite rich coming from the crowd which throws around Functors, Applicatives, Monads, Kiesli, CoYoneda etc.

djeunneun• 9 years ago

Why is it a disease, honest question.

hackits5• 9 years ago

To do OOP good requires a lot of forward thinking and careful planning. Though most of the two are lacking supply when you're dealing with large teams of programmers and you end up with some IFactoryAbstractInterfaceInvoker eg... the kingdom of nouns game.

The other main concern was it was over-hyped with consultants running around to all businesses during the dot net time with xml with no empirical evidence to backup their claims.

The whole OOP was a giant experiment.

hota_mazi3• 9 years ago

All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language.

If you think FP is mutually exclusive with OOP, you understand neither.

OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

FP operates at a more granular level, basically how you implement your methods.

And by the way, FP has design patterns as well.

FP and OOP are extremely complementary.

runT1ME• 9 years ago

OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

This is not true, ad hoc polymorphism works fine without subtype polymorphism.

wenbert• 9 years ago

Thanks for this. And I just realised, examples are in PHP!

swsieber• 9 years ago

I think the reason that some of these patterns seem so terrible in real code is limited static type systems / OO - I'm specifically looking at Java, and it's terrible type erasure, and poor (but getting better) functional programming support.

ktRolster4• 9 years ago

The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.

krapp3• 9 years ago

You can implement design patterns with functions, but functions themselves are not a design pattern.

icebraining• 9 years ago

Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on the subject: http://www.norvig.com/design-patterns/design-patterns.pdf)

ktRolster4• 9 years ago

Says someone who's never used a language that only had gosub. Figuring out how to use functions appropriately is one of the most important skills of software engineering.

BuuQu9hu• 9 years ago

Design patterns are patterns which can be used for designs. All patterns can be used for designs; "design pattern" as a phrase merely signals that the pattern was described in a certain book.

Functions are too simple and concrete to be patterns. A function is a mapping from one set to another. Even category theory manages to fully generalize functions several different ways without managing to define something as general as a pattern.

So, you might ask, what are patterns? Patterns are things which repeat somehow. That's it. There might be more to it, but I have yet to find it.

I'm glad that you like Lisp, but it's not the beginning nor the end of programming. For example, the Post correspondence problem is Turing-complete. So are Wang tiles. Where's your functions now?

ktRolster4• 9 years ago

I've read your comment several times, but I'm not sure what you're saying, actually. Certainly functions have been described in several books. No one is said that functions are the only design pattern.

waynecolvin• 9 years ago

I believe ktRolster may be refering to "Procedural Abstration". The term is used in SICP [1] (the Wizard Book using scheme, previously freshman programming text at MIT).

Abstration can take many forms. But can often be described as "seperating things that change and/or repeat from those that don't", or something like that.

The last paragraph may be a joke, or based on one of the Principles in the O'Reilly Design Patterns [2] book.

[1] https://mitpress.mit.edu/sicp/ [2] http://shop.oreilly.com/product/mobile/9780596007126.do

opk2• 9 years ago

The main value of the design patterns is that they have given names to things that were already common and fairly intuitive to a half decent programmer.

But I've come across many people trying to use them as a guide for how to write code - and misunderstanding them. Factory in particular is often misunderstood. It is mainly useful when you have parallel class hierarchies not as some odd wrapper around all the constructors in the software.

dack2• 9 years ago

I'm not sure what you mean by parallel class hierarchies. I use a factory if I have a class that needs to be able to make an instance of some other class, but shouldn't know about how to construct it (i.e. it doesn't need to know about the dependencies that other class might need to function).

mikekchar3• 9 years ago

I shouldn't speak for the OP, but I think they are referring to the fact that the factory pattern very naturally shows up when you also have the bridge pattern. You have 2 (or more) parallel class hierarchies and you need a way to construct the objects from the correct hierarchy.

You are also correct that it happens in other places too. Some people overuse it, though. They abstract out the construction of their objects for no reason at all. You already have a constructor -- usually there no need to have an object that contains all the constructors.

qznc• 9 years ago

I also do not understand "parallel class hierarchies".

Here is another use case for a factory: Building an AST data structure in a compiler. There are nodes to represent Constants, Addition, FunctionCalls, etc and you have to build a tree structure, which represents a program.

Now consider the case, where you build the addition of two constants ("36 + 6"). Using constructors, it could like like: new Add(new Const("36"), new Const("6"));

Using a factory: f.newAdd(f.newConst("36"), f.newConst("6"))

The advantage of the factory is that it can optimize on the fly and return a Const("42") node instead of an Add.

yoodenvranx3• 9 years ago

The one you mean is called "Factory Method Pattern" in the Gang of Four book. The other one should be called "Simple Factory" or something like that.

They are very different things which unfortunately have very similar names.

opk2• 9 years ago

I don't really see what you call a "Simple Factory" as being covered in the Gang of four book. I should have been clear about meaning Factory Method but the terminology is often apparent in class naming. So for the "Abstract Factory" pattern, I would use "Kit" in class naming. I would reserve "Factory" for the "Factory Method" pattern. Pointlessly wrapping constructors in a separate class and calling it a factory doesn't really get you anything. Neither does contriving a parallel hierarchy to pointlessly allow the use of the "Factory Method" pattern - something that I have also seen.

kowdermeister• 9 years ago

Don't underestimate the power of naming things. If you can't name a paradigm you used then your solution is just something that does the job.

The value of design patterns and giving them appropriate name is to have a common language, a basis for communication. Sharing ideas or giving instructions is much simpler when you can actually name something with a few words.

alashley2• 9 years ago

I wish there was a resource that goes over design patterns with more abstract concepts/classes. I found the example in GoF to be somewhat useful but at a certain point (near the middle) I got lost in the details.

dack2• 9 years ago

You want more abstract examples? Or more abstract patterns?

alashley2• 9 years ago

More abstract examples.

asitdhal• 9 years ago

That's why GoF book is available in the library.

People write more concrete tutorials and publish online. Abstract literature is for researchers and Concrete literature is for people who need a quick solution.

0x54MUR41• 9 years ago

In my opinion, iluwatar's design pattern guide [1] provides more examples than this. It gives not only implementation examples but also a class diagram and use case for each design pattern. The examples were implemented in Java.

[1] https://github.com/iluwatar/java-design-patterns

coleifer• 9 years ago

Stop the for humans meme. Try-hards use it to signal that they're "in" but its outlived any meaning beyond some meta-meaning which is no meaning at all. Just make your project quality. Don't proclaim it, just do it.

LyndsySimon3• 9 years ago

Note: this comment should not apply to Kenneth Reitz.

brockvond2• 9 years ago

why on github and not on like... medium?

LyndsySimon3• 9 years ago

Off the top of my head:

1. GitHub is a broadly-adopted tool that the author probably already knew how to use

2. It's hard to accept PRs on Medium

3. It allows the author to list the repository on his profile, thereby helping them convey competency to potential employers

4. It's easier to archive a git repo than a Medium post, and easier to rehost elsewhere in the future if/when GitHub dies.

5. Git allows change tracking.

6. It uses Markdown, which can be processed through automated tools to produce a variety of formats, from PDFs for email to EPUB to send to a physical publisher.

brockvond2• 9 years ago

lol - that's a good list. thank you.

js813• 9 years ago

In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps, or GOTOs (as they were colloquially called). And they had a very influential programming book, called "GOTO design patterns". Here's a few examples of design patterns from the book:

- "IF pattern" - If you need to execute code only if some condition is true, you write a conditional GOTO that lands after the code that is to be executed conditionally.

- "IF-ELSE pattern" - If you need to execute code only if some condition is true, and some other code if the condition is false, you use IF-ELSE pattern. It's similar to IF pattern, but at the end of the code in the IF pattern, you add another unconditional GOTO that branches after the code that is to be executed if the condition is false.

- "WHILE pattern" - If you need to repeatedly execute code and check some condition after each execution, you add a conditional GOTO at the end of the code that goes back to the beginning of the code you want to repeatedly execute.

- "BREAK pattern" - This is a pattern to use with the WHILE or UNTIL patterns. If you need to, on some condition, stop repeated execution of the code in the middle of the code, you add a conditional GOTO into the middle of the code that just branches after the repeatedly executed code block.

Everyone was happy with the book. No more messy spaghetti code full of random GOTOs (as was common before the book appeared), because young apprentices memorized all the patterns in the book, and they just applied them rigorously. Also, understanding code became easier, because everybody instantly recognized those patterns in the well written code, and they had a common vocabulary to talk about these things.

One day, a traveler from another world came into this kingdom. He looked at the book and wondered: "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" Unfortunately, he was executed for the heresy.

thom3• 9 years ago

This is, and always has been, a poor criticism of design patterns, by people who think they're just a library of code that idiots are supposed to cut and paste to be better programmers.

A common example from the GoF book is the Strategy pattern - most functional programming snarks will jump in and say you don't need this! We have first class functions you can pass around! And it's entirely true that an implementation of this pattern (a good, simple one even) is just accepting functions as arguments - cool, you probably get it! But the _design_ principle is about making strategies _explicit_ - allowing decisions to be made or policies to be enforced in ways you don't anticipate. I still see _tons_ of libraries written by smart people in functional languages that will still accept an enum of some kind to tell them what do in certain situations (e.g. a lot of HTTP libraries' extremely limited retry logic). That's an explicit design decision - to limit options instead of opening them up. Having a language to talk about the _design decisions_ at a higher level, instead of conflating them with language features, is the whole point. Everybody knows you can pass functions around as arguments, that doesn't necessarily prompt you or make it easier to discuss implementing a Strategy.

Design patterns aren't a static, finite set of code snippets, and I actually think things like the linked post that mostly treat them that way aren't helpful. They give you a way of naming and talking about components of a design, possibly at a higher granularity than your programming language (and sure, different languages have different granularities).

We've been hearing this same exact criticism for literally 20 years and it's boring at this point. I get that most people don't bother creating new design patterns in public these days (because they've internalised that modern languages have 'design patterns' built in), but if you look at something like React and think it's just JavaScript and there are no design decisions in there worthy of reifying, I think that's sad and unproductive.

js813• 9 years ago

My main point (just to make sure we are on the same page) was that whatever patterns are, we should also tell computers "look, here I use this pattern", and not rely just on humans to see it. Unfortunately, computers are idiot savants, so this very well might require those to be formally defined.

Anyway, I think we have an ontological disagreement here. I don't believe the "design patterns" which cannot be formally defined are useful, or even that they exist. I consider them to be just phantoms, which when you attempt to formally define them, you either understand them much better (to the point where you can see how they are related), or they disappear as something that was misconceived in the first place. You seem to think that there is something real.. fine.

Possibly, why I see it that way is my mathematical training. In mathematics, this battle was fought more than a century ago and the formalism camp won. That doesn't mean that intuition is completely useless.. just that people mostly keep their intuitions (and inspirations and analogies) for themselves, and when they communicate, they strive to be formal.

To your React example - it's not a pattern, it's a piece of concrete reusable code. We don't need "React pattern", but we need React. Just like mathematicians, we should communicate "patterns" via reusable code.

cessor2• 9 years ago

"Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?"

I often asked myself this question! Why do I have to say

    public class DatabaseConnectionSingleton {
        public static DatabaseConnectionSingleton getInstance (){ ... };
    }

and then get an object using:

    var db = DatabaseConnectionSingleton.getInstance();

Why can't I say

    public singleton DatabaseConnection {...}

and just go

    var db = new DatabaseConnection();

and let my runtime make sure that I get the appropriate instance? Left aside the discussion of how useful that pattern is, I would like my language to be more powerful. I am aware of alternatives (Borgs in Python) and that many people consider Singletons an antipattern, as it helps introduce globally shared state, etc. but then, why do I have to care about how instances are implemented?

After all, in C#, foreach interacts with iterators, why not push other mechanisms down into the language in the same way?

Ideas:

    // Unit of work, commits changes before the reference gets removed from stack
    public unit CustomerForm { } 

    // There can be only one.
    public singleton DatabaseConnectionHighlander {}

    // Any method called updates values in some way
    public builder QueryString {}

kdevrou• 9 years ago

Just one of many reasons that Scala is such an attractive option for Java developers:

// There is only one object DatabaseConnectionConnor {}

prefect42• 9 years ago

One can argue these topics until the cows come home, and possibly later. One can strongly argue for/against imperative programming, functional programming, OOP, design patterns, Design Patterns with Cool Names, Design Patterns as Implemented in Your Favorite Language, etc... At the end of the day, the only thing that matters is whether your team thinks your source code is structured or not. If you're on a team of one, well then you have your future self to contend with.

Design Patterns – A comprehensible guide

Related Stories