Make code future proof using design patterns

Abstract

A developer always has the desire to keep his code future proof. It is common for code to be revised after a certain period because many times expansions are not built future ready. There are a multitude of ways in which this can be achieved. A proven approach is utilizing design patterns. Another verified method is the use of a software architecture, which makes sure that all functionalities communicate at the same manner. In the ideal world both approaches are combined. At project Everyware, we have experienced the exact scenario that was described earlier. We needed to alter certain pieces of our application. We did this by drawing a new scheme, which contains multiple design patterns. Because of the successful rework of our program, we were able to make new components in a short amount of time. It was a real eye-opener to see how much a design pattern can do for a software project.

This article discusses:

· Applying the best design pattern for a certain situation.

· Preventing duplicate code in a project.

· When not to use a design pattern.

Keywords:

Design patterns, Software architecture.

Introduction

As a child, you had a difficult choice to make while being in the candy shop. The first choice that had to be made was the type of candy. The most common options are Chocolate, lollipops or licorice. After picking the type of candy, you still needed to pick the sort of taste. The above metaphor represents design patterns at its best. Just as with the candy, there are three categories of design patterns for object-oriented programming. Those are creational, structural and behavioral design patterns. Each of those categories also has a various number of divisions.

Design patterns are key if you want to keep a project future ready. It is hard to determine where a design pattern is necessary. Usually, it is only found out whilst running into a problem. The trick is to think ahead. A helpful tip is to think about what happens if a new feature is being added in the future.

There is also a downside of using design patterns. Code using design patterns does get more complex for a new developer joining the project. Another mistake that can be made is to mismatch design patterns. In other words: Use a design pattern whilst it is not required.

To understand the importance of design patterns, let us consider the pros and cons of utilizing patterns. Design patterns are common knowledge. It may be complex for a new developer to fully understand it, but after that he will not ever have trouble with it again. A design pattern is mostly used for future extensions. Any additions in the future will provide minimal changes in the core of your code. The only con of using a design pattern is that it might be unnecessary. In that case may be better to implement it partially.

Related works

In the article Journal of Software Engineering and Applications all creational, structural and behavioral patterns are listed. This article also concludes that design patterns have been a turning point in software development, since a template can be used for more than one specific framework. This makes sense. Writing code with design patterns ensures that it is future proof, since many design patterns anticipate for potential extensions.

The article Software Architecture and Software Design states that it makes sense to combine architecture and design patterns. It also concludes that there is not a specific rule that can be applied at all places. This is too flat. It is obviously possible to think about probable expansions in the future.

Analysis

Given the advantages and challenges of being future proof, design patterns are an excellent solution. The vital improvements:

· Minimal changes are required to add a new feature. It may take some time for a new developer to get used to the design patterns that are already in place. However, after this period the developer will be able to add new functionality rapidly.

· Duplicate code can be avoided. A design pattern may also prevent duplicate code from existing, since many patterns implement on builder a certain model in a similar way.

In our product we used certain design patterns to make sure that question and answer types may be added rapidly. We used a factory method for both entities. A factory method is a creational pattern. It enables the creation of an entity in one place. The factory methods return their own interface. Those interfaces are implemented by question-and-answer models. Both models use the template method pattern, which is a behavioral pattern. All basic functions are defined in the parent class. Specific steps can be overridden in the children classes.

Conclusion and recommendations

It is clear why and how design patterns make an application future proof. If the correct design pattern is in place, minimal adjustments are necessary when a new feature is being added. Identic code can be dodged while using a design pattern. Also, this has been showed in the analysis, where the template method put all standard functions into one class.

It is sassy to apply a design pattern as soon as possible. This will prevent many hours being spent on refactoring later on. It may seem irrelevant now, but later in the process it can be punished. Finally, it is also smart to keep the diagrams of your architecture up to date. A diagram provides a bird-eye view on a part of a project.

Of course, a design pattern is not always the solution. In some cases, there is no such thing as a perfect fit. In those studies, it is recommended to take some ideas of a certain pattern, but do not implement the pattern in its full fashion.

References

Edwin, N. M. (2014). Software Frameworks, Architectural and Design Patterns. Journal of Software Engineering and Applications, 07(08), 670–678. https://doi.org/10.4236/jsea.2014.78061

Jaiswal, M. (2019). Software Architecture and Software Design. SSRN Electronic Journal, 6(11), 2452–2454. https://doi.org/10.2139/ssrn.3772387

Collaborators

Bram Sliepen, Matthew Tanti, Sven Goossens, Kenneth Gerrits, Olivier van Houdt, Onyi Lam.