Design Patterns in Object-oriented Programming
The programming world today is not what it used to be. The importance of keeping with the latest trends, technologies, and architectural designs patterns can never be overemphasized. According to Christopher Alexander, “The elements of language are entities called patterns. Each pattern describes a problem that occurs over and over again, and then describes the solution to that problem over a million times without ever doing it the same way twice”.
What exactly are design patterns??
Scott Millett (author of ASP.NET Design Patterns), has defined design Patterns as high-level abstract solutions templates. They are kind of like blueprints for solutions as opposed to being solutions themselves. A perfect example would be freezing water in a square container. The square-shaped ice you get is the solution you need, but the container was what gave shape to your solution. And that is what design patterns do, shape or refactor your code into a reusable solution to solve common problems in software design.
Why are Design Patterns Important??
Design Patterns are essential to software design because it is an effective way to provide solutions to complex problems. Having a solid knowledge of design patterns makes it easier to communicate easily and effectively with other members of a team without having to worry about details like code readability.
What makes them so powerful is the fact that they have been tested and confirmed to solve important design problems. Design patterns are all about the reuse of solutions, and in 2021, most of the problems that will be encountered have probably been solved a number of times. This has provided a pattern to solving a similar problem now or in the future.
Categories of Design Patterns
A set of common design patterns have been accounted for in a book titled Design Patterns: Elements of Reusable Object-Oriented Software written by four budding programmers in the 90’s known as the Gang of Four (GoF). They itemized 23 design patterns and sectioned them into 3 groups:
Creational Patterns: These patterns deal with object creation. They add more flexibility in deciding which objects are required for particular cases and solve the complexity that may arise during object creation. The design patterns in this category are Abstract Factory, Builder, Factory Method, Prototype, and Singleton.
Structural Patterns: These patterns deal with relationships between different objects and how they interact to form larger complex objects with new functionalities added. They are Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy.
Behavioral Patterns: They deal with the communication between objects. These patterns are Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor.
Common Design Principles
If you have had a couple of years under your belt writing object-oriented programs. Chances are you already know a couple of the design principles stated below:
Keep It Simple Stupid (KISS): This is self-explanatory enough. Avoid using overly complicated code and just keep it simple. That’s how you can avoid unnecessary complexities.
Don’t Repeat Yourself (DRY): This is one of the first things you learn as a programmer. If you have to repeat a block of code, abstract it out to a single location and reference it. That would save time and make your code really clean.
Tell, Don’t Ask: It's easy, tell objects what actions you want them to perform. If you have to check the state of the object then decide on what it should do, you have decimated this rule.
You Ain’t Gonna Need It (YAGNI): If you are not going to use it, don’t include it in your code. This principle just emphasizes the importance of putting only functionalities required by the application and removing other features that are not necessary.
Separation of Concerns (SoC): It is simply breaking down an application into distinct features that encompass unique data and behavior that is used by other classes. This increases code maintainability and reuse.
Other Design Principles
There are a lot of other principles to understand in object-oriented programming like the almighty SOLID principles by Robert C Martin and basic design practices such as Test Driven Development (TDD), Domain Driven Development (DDD), Behavior Driven Development (BDD).
But I want to make sure it is properly understood that although design patterns are extremely helpful, they are not necessary in all cases. Not all problems need a design pattern because like Scott Millett said “It is true that design patterns can help make a complex problem simple, but they can also make simple problems complex”.
So, if you have provided a solution that is clear and maintainable without a design pattern, it is all good too. Don’t try to incorporate a design pattern by force or else you would overcomplicate your design.
Thank you for reading..
(Most of the ideas here are from ASP.NET Design Pattern: Scott Millett, if you are a budding .NET developer like me, you can check it out.. It is a good read ^_^)
