A design pattern is an approach to solving typical problems. We have previously looked at some of them — from different types of dispatching to Strategy and Factory.
There are many design patterns, and the programming community invents new ones daily. So, every programmer has their favorite ones for doing their tasks.
Generally, patterns are not related to the concept of OOP, but they are structured and described in OOP. Therefore, this topic is common in languages with class structures, such as Java, C#, or PHP.
Most of these patterns come down to how to 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 patterns are abstraction-related and have an internal state; others are ordinary functions packed into classes only for polymorphism (we can implement them by regular functions 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 can make the right decisions on your own, without even knowing about the pattern for this situation. The key idea is to take the whole multitude of behaviors and create your class for each behavior.
For example, in Strategy, the number of strategy classes is the same as the number of ways to calculate. If there are five of them, you have to create five classes. That is, at least in class languages.
We can create five functions in languages where functions are preferred. In that case, it remains to be Strategy.
Antipatterns
The existence of patterns means there are also antipatterns — typical mistakes that programmers make. They usually have funny 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 antipattern 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 hard to test.
Learning patterns
Newcomers are usually concerned about learning patterns. Should I know all of them by heart? How many patterns should I know? What books should I read?
Let us 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 is hard to implement a pattern without encountering the real problem it solves.
Secondly, we get a genuine understanding of patterns through the other things important for our profession:
- Naming
- Managing states
- Side effects
- Abstractions
- Extensibility
- Subtype polymorphism
If you don't understand these things, trying to use patterns will almost certainly turn into a cargo cult. From the list above, patterns have the smallest impact on the quality of your code.
It is crucial to understand that patterns are not the cause, but the consequence. Beware of the “Solution looking for a problem” mentality.
First, you need to understand the situation, and then the pattern will emerge. For the first few years of your development career, it is perfectly normal to solve problems the way you can. We learn through mistakes and incorrect decisions, so don't be afraid. The main thing is consistent improvement, and here is where books and mentors can help.
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.
