Software development field has progressed massively in the time it has existed. From first programs in machine code to high-level language-based applications with complex structures. These days even the simplest of the applications you make is likely to be quite complicated even in its fresh form. Programmers evolve their level of understanding their applications and also their approaches to development. When you first start writing your first “Hello, World!” application, you rarely even consider aspects like architecture, performance, or maintainability. More experienced developers have to adopt more mature ways of understanding the code, and knowing the best ways to write the code and ensure that this code will be easily maintained not just by them, but by legacy developers too.
One of the most important things an experienced developer is ought to know is Design Patterns. Knowing what are those is one thing. The more important one is to know when and where to apply this or the other. Operating with patterns also have an aspect of communication with other developers on the team. One will no longer need to explain that the system must have one-to-many relationship between “updater” and “updatees”, when “updater’s” state changes. Instead the developer can simply say that we should implement Observer Pattern in this instance. Other developers will instantly know what this person is talking about. Clear and concise communication will be set up, whether it is between fellow developers or in documentation.
Before we go on further, let’s determine a clear definition for a Pattern.
A Pattern
is a solution to a problem in a context.
We have three important parts on our hands: context, problem, and solution. The context is a situation where a pattern can be applied. A particular situation constitutes to a particular pattern. That’s how we know which pattern to apply when we are presented with the context. The problem is a goal one is trying to achieve. What is it that you are trying to solve? What is the desired result? The solution is a design that can be applied, i.e. one of the patterns.
Our definition doesn’t really give a lot of insight into what pattern exactly is. Rather it gives you a meta-framework for what pattern is: context can vary, problems can vary, and depending on both of those, we might have different solutions each time.
Patterns have classification. They are categorized mainly in 3 groups: creational, behavioral, and structural. Creational patterns deal with object creation and instantiation, and aim at decoupling of client from the objects it wants to create. Examples of creational patterns are Singleton and Factory. Behavioral patterns deal with how objects communicate and interact together. Examples being Template Method and Iterator. Structural patterns allow you to create greater structures than classes and objects themselves. Adapter and Facade being good examples among those. Sometimes patterns also get divided on Class patterns and Object patterns. Class patterns describe how classes relate to each other via inheritance. This relationship is instantiated at compile time. Object patterns deal with relationships between objects and are mostly installed via composition. This kind of relationship is more flexible since it is defined during runtime.
There are many resources online on learning design patterns, take even this blog 🙂 . If you enjoy studying using books instead, there are some books called Design Pattern Catalogs. They list all of the patterns know to software development world: from the most used and well-known to the least. Patterns are laid out in a manner where you get description of the pattern, of contexts in which it is best applicable, and problems that it is best at solving. Very organized collection and a great tool for learning and reference!
One last thing to remember about usage of Design Pattern is not to overuse them. While it is great to know them and know how to apply them, if the context is simple and will not require you to develop over-the-top flexible application, do it the simplest way possible, which may also mean not to use a pattern at all. Means should justify the costs in time and complexity. If you are developing a one-page website, you don’t need to conjure the all-powerful MVC. The simplest solution will do the best.
Keep the context and the problem in your mind when you consider which pattern to apply! The solution will appear very quickly once all of the constraints are defined precisely. Use patterns wisely.
Abstrakt Kode 