Object Oriented Programming
Object oriented programming is one of the major programming paradigms and it is the main paradigm for the C# language. As software developers, it is important to master most of its concepts and good practices. In this post I will briefly discuss what design patterns are, the main ones, and how we can start learning them.
According to Wikipedia, a design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.
I like to see them as recipes we can use to resolve common challenges when programming in an object oriented language.
Design patterns were initially created to standardize the construction of new buildings in the decade of the 70s. An Austrian architect named Christopher Alexander wrote a book named A Pattern Language which discussed the usage of patterns in the construction field.
After him, some others scientists tried to apply patterns for the production of software. The most famous book on this subject is the one called Design Patterns: Elements of Reusable Object-Oriented Software written by the so-called Gang of Four (GoF) in 1994. This book became a reference on the subject and it's still being studied by software developers up to this day.
The book of the GoF describes 23 individual design patterns grouped in three categories.
Provide solutions to the problem of who should have the responsibility of creating objects of specific type and how it should be done.
Some of them are Factory, Builder, Prototype and Singleton.
Provide solutions to the challenge of how to compose objects or how different entities should relate to each other.
Some of them are Decorator, Facade, Composite, Adapter and Proxy.
Provide solutions to the problem of how objects should communicate to each other.
Some of them are Strategy, Command, Interpreter, Iterator, Observer.
At this moment many more patterns have been identified, so the list doesn't stop at only 23. In fact, I just listed a few examples here based on the ones identified in the book of the GoF.
You might be thinking: Wow, this looks very complex. What's the point of learning this? Well, that's a good question. Whereas some developers prefer to rely on principles like SOLID instead of applying pre-made formulas or solutions, there are many benefits of using design patterns. I'll go over them.
Most of the issues we find when creating software are not unique to us. Many other developers in the past faced them already. The good things is that they also came up with good solutions for them. As those solutions got standardized we just need to learn them and apply them instead of coming up with a new one that might take us a lot of effort to end up being just the same - or maybe worse.
Using pre-made solutions with a name makes communication easier. We don't usually work alone, but in teams comprised of other developers. Whenever we discuss approaches to building our software, we can easily mention the design patterns we want to apply and be understood by our peers, without having to explain all its details.
Deliver better software
This is what I think to be the best reason. These patterns tend to minimize the risk for many of the issues with software development. They try to minimize coupling, maximize cohesion, and make our software generally more scalable.
When talking about design patterns, there are some information that is usually mentioned. At this point I will mention the main ones which are:
Name and classification
Problem it solves (or intent)
The pattern itself (or the solution)
This is a small example from Refactoring Guru, which I think is an excellent resource to learn design patterns.
Name and classification:
Factory Method is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.
Problem it solves:
Imagine that you’re creating a logistics management application. The first version of your app can only handle transportation by trucks, so the bulk of your code lives inside the
After a while, your app becomes pretty popular. Each day you receive dozens of requests from sea transportation companies to incorporate sea logistics into the app.
Adding a new class to the program isn’t that simple if the rest of the code is already coupled to existing classes.
Great news, right? But how about the code? At present, most of your code is coupled to the
Shipsinto the app would require making changes to the entire codebase. Moreover, if later you decide to add another type of transportation to the app, you will probably need to make all of these changes again.
As a result, you will end up with pretty nasty code, riddled with conditionals that switch the app’s behavior depending on the class of transportation objects.
The Factory Method pattern suggests that you replace direct object construction calls (using the
newoperator) with calls to a special factory method. Don’t worry: the objects are still created via the
newoperator, but it’s being called from within the factory method. Objects returned by a factory method are often referred to as products.
There are many other attributes related to a design pattern, like: applicability or context, structure (usually diagrams), participants, collaboration, implementation and consequences, sample code, known uses, related patterns, pattern structure.
As we saw in this article, there are many benefits for the usage of design patterns. However, it can feel daunting to see how many they are. We don't need to know them all. We can totally focus on a few of them, the most important ones, and make sure we understand them well and know how to apply them.
In the next posts I will go over most of them and present some code examples so that we can make sure we understand them well.
You can subscribe to the newsletter to receive a notification when I publish a new post.