Design Patterns (Patterns) — JS: Polymorphism

A design pattern is an approach to solving a typical problem. We've previously looked at some of them, from different types of dispatching to Strategy and Factory. There are a lot of these patterns, and new ones are being invented every day, and every programmer has their own patterns they use for doing their tasks.

Patterns, in general, aren't related to the concept of OOP, but they are structured and described in OOP. Therefore, this topic is especially common in languages with class structures, such as Java, C#, or PHP. And most of these patterns come down to how to properly apply subtype polymorphism in different situations. Here are just a few of the widely known ones that rely on polymorphism:

• Adapter
• Strategy
• Abstract factory
• Bridge
• Composite
• Decorator
• Mediator
• Chain of responsibility
• Observer
• Status
• Template method
• Visitor

Some of them are abstraction-related and have an internal state, others are ordinary functions packed into classes only for the sake of polymorphism (but can also be implemented by ordinary functions that are dispatched in different ways).

Polymorphism in Patterns or Pattern Creation Pattern

Most of the patterns that are associated with polymorphism follow the same principle. If you know it, you'll be able to make the right decisions on your own, without even knowing about the pattern for this situation. The key idea is that you take the whole multitude of behaviors and create your own class for each one.

For example, in Strategy, the number of strategy classes is the same as the number of different ways to calculate. If there are five of them, you have to create five classes. That is, at least in class languages. In languages where functions are preferred, five different functions will be created, and it will still be Strategy.

Antipatterns

The existence of patterns means there are also antipatterns - these are typical mistakes that programmers make. Many of them have quite specific, often humorous, names, such as "big ball of mud" or "god object". The most surprising thing is that approaches that used to be thought of as patterns sometimes spill over into the anti-pattern section. The most striking example is the "Singleton" pattern - an object that can only exist in a single instance. As life has shown, this is almost always bad. In addition, code with singletons is extremely difficult to test.

Learning patterns

Newcomers who've read enough articles and heard enough from their elders are very concerned about learning patterns. Do they need to be taught? How much should you teach them? What books should be used, etc.?

Let's try to figure it out. As practice shows, everyone talks about patterns, but very few people actually read them, understand them and can reasonably apply them. There are several reasons for this. Firstly, it's extremely difficult to implement a pattern without encountering the real problem it solves. Secondly, a genuine understanding of patterns is tied to the things we've been parsing throughout the profession: naming (which is really damn important), managing states, side effects, abstractions, extensibility, subtype polymorphism. Without an understanding of these things, trying to use patterns will almost certainly turn into a cargo cult. And from the list above, patterns are last in terms of the effect they have on code.

It's important to understand that patterns are not the cause, but the consequence. Beware the “solution looking for a problem” mentality. First of all, you need to understand the situation, and then the pattern will emerge. And it's perfectly normal for the first few years (or more) of your development career, the problems will be solved when they're solved. Learning happens through mistakes and incorrect decisions, this is not to be feared or avoided. The main thing is consistent improvement, and here is where books and mentors (at work or online) can help. We wrote about the best way to read books, including pattern books, in this article.

Recommended materials

1. Single responsibility principle
2. Anti-patterns
3. Patterns of Enterprise Application Architecture

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.