Explain Design Patterns Like I'm Five

Comments

[Nested Software]

Hmmm, it's bit tough to come up with a truly eli5 example for this, but I think the basic idea is reasonably simple: A design pattern is a structure of code that you can apply to many different problems.

I don't think it's generally thought of that way, but to me, even something as simple as a humble for loop is a kind of design pattern. It's used to loop over some kind of iterable and then inside the loop you execute some piece of logic. The for loop is a re-usable structure of code: It can be used for all kinds of different applications. Therefore it's a simple design pattern!

In the 90s, a book called Design Patterns, Elements of Reusable Object-Oriented Software was published. This book became quite influential in the object-oriented programming community. In this book, each pattern is basically a piece of boilerplate code that can be used to reduce duplication and increase flexibility when solving a type of problem. You can think of this pattern code as a kind of harness or scaffolding: You start with this pattern code and then you fill in the actual logic for your specific situation. The Design Patterns book has ideas that are quite common in programming today. For example it describes the proxy/decorator pattern that's used quite a bit in many contexts these days.

Often when someone refers to design patterns, they're either talking specifically about one of the patterns in this book, or they could be talking about patterns that other authors defined later on. For example in 2002, Martin Fowler published another influential book of design patterns around enterprise programming called Patterns of Enterprise Application Architecture. Among other things, this book spends quite a bit of time on design patterns for mapping an object-oriented application to a relational database. You can see some of these patterns mentioned specifically in some ORMs (object-relational mappers), like active record in the Rails framework, or data mapper in SQLAlchemy. That means design patterns can also be useful as a shorthand for communication among developers.

On the negative side, design patterns can become a temptation to over-design one's code, so that's always something to keep in mind. The basic trade-off of design patterns is that they generally give you more flexibility at the cost of increasing the level of abstraction/indirection. It's like anything else: Having a tool in your toolbox is always a good thing, but it doesn't mean you have to apply that tool to every problem you encounter.

[Casey Brooks]

When humanity first started making buildings, they were usually made out of sticks, grasses, mud, etc. This worked well for a long time, it gave people some kind of protection from their environment; helps keep out bugs and predators, gives protection from rain, provides a feeling of general security, etc. In fact, in many places around the world, indigenous peoples still build their houses this way, and that's perfectly OK.

Fast-forward to when larger civilizations started to emerge, and you'll find that the old mud huts and tents just aren't going to work. You've got too many people living in too small an area, and while it may be easy to build or rebuild hut for a single family, it's much more difficult to keep an entire city of huts in good order. And since huts are built right on the ground, a city of huts would grow to cover a very large area, making for an inefficient use of the available area, or limiting the population that could live in a given area. The answer, of course, is to build upward rather than outward, using timbers and large stones to construct many-storied buildings that last a longer time. It may be more difficult to build initially, but the benefits in the long-term are definitely worth it.

And going even further, today's skyscrapers are made out of steel and concrete, not wood and stone, which makes them even stronger and more resilient, able to climb higher and support more people than ever before. While it may have taken thousands of years of engineering technology to get to this point, now that we're here it is really easy to go and build another skyscraper, because all the hard stuff has already been figured out by someone else. Now that we have the patterns figured out for how to build a good skyscraper, we just need to go build it.

And this is the purpose of design patterns, like MVC, MVVM, MVP, Clean/Onion Architecture, and so many others. They are by no-means necessary for small projects, and when working with a small codebase, attempting to follow a design pattern can be quite cumbersome. You probably don't need to build a skyscraper for a village of 20 people, and even a house of stone and timbers may be too much. However, if you are expecting your village (project) to grow significantly, it might be worth it to put a design pattern in place, because it is a whole lot easier to build a skyscraper from a clean foundation than it is having to start with a patch of dirt littered with mud huts. Usually, in this case, it is actually easier to just throw away all the old huts, level the ground as flat as possible, and start over with the intention of strictly following a design pattern.

[Thomas Junkツ]

Design patterns are standard recpies by programming chefs which help you writing tasty applications.

[powerwebdev]

A design pattern is the description of the same solution multiple persons used to solve the same problem, so that further persons don't have to come up with this solution on their own.