How does software architect help me to choose software patterns?
Hey, it’s me again here to ask a question to software architects. In my stories, mostly, I choose questions as a title. To emphasize my writing would be enough as an answer. Oh wait, is it also a pattern that I apply? :)
Story title shows itself that we’ve already decided to use a pattern in our software project. Do we exactly know what design pattern means? How do we decide to use the selected XYZ pattern? How can we describe this as a design pattern? For example, could merge sort be considered as a design pattern? Let’s find out.
Before going deep down into this topic, we need to find the answer to this question, what is the pattern? It presents a useful solution for a recurring design problem. Do you realize what we need more? Perfect, you are good at that, a design problem. Let’s start with identifying the design problem.
Before applying the selected XYZ pattern, we might want to get advice from a good software architect. Probably asks, “Hey X, before applying this pattern imprudently, did you analyze exactly what needs to be resolved? Of which scope and from which domain? Did you consider constraints of the requirement? What will be the consequences of this solution?”.
As you realize, a good software architect needs a lot of answers during even the identification step. For example, if the scope is not explained well, the software architect might suggest a software design pattern instead of an architectural pattern or vice versa. Of course, it is not a final decision, could be revocable. A good software architect should ask after the identification step: “How do we decide to use that XYZ pattern? Do we have any other options?”. A new chapter is online now: Checking for available patterns.
First thing first, if anyone does not know about XYZ pattern in pattern universe, congratulations you have a new problem! Unknown patterns or the thing which was thought of as a pattern bring risks to the table. In such cases, software architects must always stay on guard. To mitigate an issue, the right question should be asked, “Have you already checked for available patterns?”.
You recognize that XYZ pattern is actually as known as XYZ sort algorithm. So, what is the difference? Is it still useful as a pattern? No, please do not do. An algorithm gives a recipe for how to solve the problem step by step by performing small instructions. A design pattern is like a blueprint: a structured collection of objects and associations and actions to accomplish some goal.
There are many different patterns, but only a few of them could fit your problem. Therefore, it is mandatory to narrow down the pattern space into useful patterns that address the problem. There are many different books that could help us to choose the right pattern, for example GoF design patterns or POSA series.
However, if we cannot find any feasible pattern for a specific problem, what should we do? Do not force yourself to suggest a design pattern for every problem. If there is no available pattern, just provide the solution without the pattern. Otherwise, we are ready for analyzing the consequences.
Now, we have a decision for a pattern and we know that resolving the right problem in the right way. However, this is still not a final step for choosing a pattern. In software architecture, there might be some trade-offs between quality attributes. Only you have to do is, analyze requirements and constraints, apply the right design tactics and find the enough - not must be the best -solution. If the price to pay for the selected pattern does not outweigh its benefits, we might say that we are on the right track. For example, developers might not be familiar with exceptional design patterns. Furthermore, it may cost a few days to understand the pattern and apply it. In this case, you should suggest the simplest solution as much as possible. Using a rare pattern does not make us a genius or legend! Perfect, now we are implementing the selected pattern stage. By the way, again if it does not fit your problem, do not push other people to use design patterns.
A good architect does not implement the selected design pattern, or does he? It could be another story title for me but now we must focus on implementation. As a software architect, you should guide developers on integrating the pattern into legacy design. Be sure that with a new pattern, everything works fine as expected by extending test scenarios. However, team realize that XYZ pattern would not be enough and you might need another pattern as known as ABC. Perfect, their maturity level is high and they start implementing it immediately. Keep up the good work! Oh, wait… Implementing two different patterns at the same time is safe?
The problem might require multiple patterns but each pattern must be applied individually. Prioritize design problems from the most important to the least. Afterwards, do it same thing in each iteration until all subproblems are addressed to the selected patterns in the right way. Combining the patterns deserves to be written a separate story for itself.
During the implementation phase, developers might start complaining about a potential solution that does not fit best. To prevent such an issue, you should consider it “Patterns are not constant things”. It means you can do tailoring on it and adapt the selected pattern for your needs.
All things are done and we should be happy. Do we have to follow any other steps? Of course, the final step is “Reviewing and refactoring if necessary”.
Until now, we describe a lot of steps to select the right pattern. Even though we follow the all rules or guidelines, do not forget that we are human beings. We can be wrong or might give wrong decisions. We must be aware of how can we mitigate wrong decisions. Reviewing and refactoring. If the most suitable pattern does not fit in our architecture, it misleads us in the development phase. You are not late for own your funeral, we have a room for a review and refactoring. Then please go back to step “Checking for available patterns” and find an alternative pattern for your problem. Go through each step again and tailor it if necessary.
As a result, there are many steps we have to follow for selecting the right pattern for our problem. In this journey, software architects should understand why you need a design pattern for your problem, consider alternative patterns, suggest architectural patterns if necessary, make sure patterns fit the context and requirements, keep eye on integrating design pattern during the implementation phase, and refactoring it if necessary. Do not forget a design pattern is just a tool not a silver bullet that needs to be applied with care.
