Design patterns have become an integral part of modern design.
A design pattern in software development is a repeatable architectural design that represents a solution to a design problem within a frequently occurring context.
Simply said it's a typical solution for a typical problem. The term came to programming from architecture. In the 1970s, architect Christopher Alexander compiled a set of design patterns, typical solutions for various architectural tasks. A decade and a half later, this idea was borrowed and adapted for the development of SmallTalk graphical shells. Now patterns are everywhere, constantly being invented and reinvented. Some of them describe tasks related to small pieces of code, others define, for example, ways of working in distributed systems. And the last ones are independent of the programming language. It's interesting to note that some patterns in languages emerged as a result of the limitations of the languages themselves and investigating how to get around them.
We already know at least one design pattern from the “static properties and methods” lesson. It's called Money and it's an object-value.
class Money {
constructor(amount, currency = 'usd') {
this.amount = amount;
this.currency = currency;
}
}
You may be surprised that a whole pattern has been invented for such a primitive task, and you'd be right to be surprised. A pattern is not necessarily something complicated and available only to a select few. A pattern is any task that is repeated without no matter how difficult the solution may be estimated to be. So, whether you like it or not, you already have design patterns in your code, even if you don't know about it. However, some typical solutions are extremely difficult to achieve on their own.
How important is it to learn design patterns? Most of the template descriptions on the Internet are tied to a particular book. Not all of the patterns described in it are useful and can be found in ordinary life. Many of them are language-specific and don't apply in the same way to other languages. There are many more patterns (by orders of magnitude) that are not described in this book.
Patterns beget antipatterns. An antipattern is the same generic solution (generic because it's used frequently), but it causes more problems than it solves. Usually, such decisions arise from a lack of understanding of cause-and-effect relationships in code.
We'll be familiarizing ourselves with patterns and antipatterns throughout the rest of the course.
Recommended materials
Are there any more questions? Ask them in the Discussion section.
The Hexlet support team or other students will answer you.
For full access to the course you need a professional subscription.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.
