Design Patterns in Software Engineering
An Introduction to Design Patterns.
In a recent mock technical interview, the interviewer mentioned understanding design patterns is important to have a grasp as a developer in the field. I thought it would be worthwhile to understand design patterns in software engineering a bit more.So, let’s see what they are all about!
Overall, design patterns are actually somewhat straightforward, they are documented solutions to commonly occurring problems in software engineering.They can be extremely useful when used in the right situation. They are usually implemented when people notice a problem with their design, i.e. having an issue with runtime/performance, or when something should be working easily, but isn’t.Typically, design patterns show up as three different types: Creational Patterns, Structural Patterns, and Behavioral Patterns.
Let’s break it down!
What is a design pattern?
Design Patterns are a common solution to a common programming problem.
They are techniques used for making code more flexible and having it meet certain criteria.
A design or implementation structure that achieves a particular purpose.
The three main types of design patterns are Creational, Structural, and Behavioral, and within those types are quite a few sub design patterns. See the image below for a breakdown in the different design pattern and their sub categories.
Creational
Creational design patterns deal with various object creation mechanisms. These kind of mechanims allows for more flexible and reusable code, they allow for the abstracting of complex logic by creating objects from a client and provide a cleaner interface to solve problems as they arise.
Let’s focus on the Factory Method Pattern. A factory method is a method that manufactures objects of a particular type.
Structural
The structural design patterns let us compose different objects in a large structure. These patterns help in building relationships between different objects while making the structure flexible and efficient.
Adapter Pattern: Let’s say you have to build a charts library and it accepts data in a structured JSON object to render beautiful charts. You have one legacy API that returns the response in XML format. We have to use this response and generate charts, but the charts library accepts a JSON object. We will write a function to convert this XML to JSON as required. This very function that lets us connect two incompatible structures is an adapter.
Behavioral
The behavioral design patterns focus on improving communication between different objects in a system.
The Chain of Responsiblity Pattern: This design pattern lets us build a system where each request passes through a chain of handlers. The handler either processes the request and passes it to another one in the chain, or it simply rejects the request. This pattern is commonly used in systems where sequential checks are required to be performed on the incoming requests.
Conclusion
Of course there is quite a bit to unpack here. I look forward to delving deeper into the other many subcategories of design patterns and getting more knowledge with time and experience. Thanks for reading, and happy hacking!
