Design Patterns: Wise Solutions to Save Time and Money

 
By Sibers Unix Developer Maxim Aksanov

Accompanied by Sibers PHP Developer Konstantin Sherpaev

Is it possible to quickly add features to your applications without having to completely rewrite them from scratch?

As a customer have you ever thought about the technical structure of your development project? Of course, you are probably thinking “Isn’t that your job?” Regardless of occupational designation, you are still probably aware that every application inherently has an abstract structure. Sooner or later you might want to change it, and thus you should have an understanding of at least the basic structure. A clear and good structure includes certain patterns of development, which is exactly what we are going to debate in this entry. These patterns, when used in the design of your application, can save significant development time and allow developers to use a number of useful features. So, what exactly are design patterns, and when they are useful for your tasks?

Design patterns are fixed templates which are used by developers for building a basic application frame. The frame choice depends on the specific features and purposes of the application. Since some application features are similar, developers create models for how to solve the most frequent design problems. These models are effective, internationally accepted design patterns. For these patterns work well, you need to consider what functions and supplements your application will need during the specification phase, as well as what you might want to add. In this phase developers can identify and reserve some “free places” for these components.

If developers ignore design patterns when creating application versions, adding every new feature, even a simple one, is going to become a very difficult task requiring a great deal of the developer’s time. In fact, it will result in rewriting the entire source functioning code. By sharing your project plans with your project manager upfront, your team will be able to change the code according to your desires with minimal difficulty and minimal time.

This particular issue has come to light a number of times with our own customers. One such example of this type of project involved an application that did not have any patterns in its structure. Each time our customer wanted to add a new feature, we had to add more and more work around. It was too complicated for us, but seemed very simple for the customer. He thought such minor additions could not possibly take hours of development. So, when the next feature addition was estimated to take 40 hours of work, we decided to apply design patterns. This task took 60 hours, but as a result we could add every new feature in just 4 hours. In addition, further support became simpler, and the customer, needless to say, was quite satisfied.

Another important advantage to using design patterns is their international recognition. These patterns speed up the transfer of your project to other developers in the event that you want to change the team, or want to make further additions with another provider some time after the project concludes. The new provider or developer will not have to spend hours working from scratch, and your money is going to be allocated more wisely.

However, the key to using patterns may is to use them wisely. The worst way to use patterns is to use them in all cases, with all variants in the same application in place, which will not be needed for some additions. This will actually increase the development time, and will result in complicating the code. Even worse, the next developers will have to spend much more time to repair the matter.

Types of Design Patterns

According to the Gang of Four, the authors of the book Design Patterns: Elements of Reusable Object-Oriented Software, there are 23 design patterns. These patterns are then divided into 3 functional categories: Creational, Structural, and Behavioral Patterns. Let’s briefly describe each and look at some case studies from our own practice.

Creational design patterns deal with object creation mechanisms, and attempt to create objects in a manner suitable to the situation. The basic form of object creation designed without patterns could result in design problems or excessive complexity. Creational design patterns solve this problem by controlling object creation.

Structural design patterns ease the process by finding a simple way to realize relationships between entities in the code.

Behavioral design patterns identify common communication patterns between objects and then realize these patterns. These patterns increase flexibility in carrying out communication between the objects.

Example 1

One project the Sibers team developed involved using the WebSpider module. WebSpider is a website downloading program that is used for analyzing and recording information in a database. For this project we completed multithread downloading by using a special algorithm.

Another application in the project required a different supplementary module — AvailabilityWatchet. While developing this application we found that this unit had the same structure and functionality as WebSpider, however the downloading algorithm was slightly different. In this case we had two possibilities: copy the process thread characteristics and correct them for new tasks, or redevelop the first module with a design pattern without code copying. It was a much wiser decision to follow the second variant, in case similar applications appear again and again. Therefore, we decided to apply a design pattern Factory Method. This pattern makes it possible to describe the logic of a process once in the basic technical class. In the new module we described a simple class which created concrete objects. As a result we created a technical class to manage abstract threads. In each module we had to briefly describe peculiarities of management and how the application met new needs.

Thus, the Creational design pattern was most beneficial in this situation.

Even more importantly, we were able to greatly simplify the addition of new units with similar structures without having to spend any time on new coding, as all we needed to do was use the design pattern established in our code.

The design pattern used allowed us to decrease the amount of code, making it more structured and readable. This meant there was less potential for developer mistakes. Overall, the process was a great advantage for us as it decreased the development time for further modules.

Example 2

Another of our case studies involved developing a site downloader which required data to be transferred in the same format. PHP language was used in the development process.

Downloading was needed to accomplish this task, and was started repeatedly. Since the design pattern using downloader had to be initialized for every feature and every time, be it Loginer or Extractor, a solution was needed as the process was quite inconvenient.

We then used Creational pattern Singleton for the downloader, which had a request generation method description. This downloader’s major advantage was logging request data, thus allowing us to process several parallel requests.

***

These cases clearly show the necessary and beneficial usage of design patterns. When we began analyzing the excessive use of patterns in our practice, we only came up with a handful of cases where developers erroneously used a certain type of a pattern. The effect was obvious as the application had a big code dimension, experienced trouble with testing, and worked with objects that required many unnecessary actions. If you see similar symptoms in your project, it is a sign of using an incorrect pattern. However, this does not mean that all the patterns have to be removed. When developers replace just the pattern used erroneously with the correct pattern, everything ran smoothly, and worked effectively.

By now it should be clear how using appropriate design patterns can simplify the process of development, save time and money, as well as improve the functionality of the application. You should also be aware that developing such patterns can take some time, but the extra cost will most definitely pay for itself in the long run. If the code is written without such patterns, which may be less expensive upfront and may seem unnecessary for some customers, any further desirable features in the application may result in many hours of development time, in spite of being consider “minor” or negligible. Now it’s time for you to make a decision as to whether to allow developers to use these suggested design patterns for your project or not.