Design Patterns: are they so difficult to understand?

Introduction:

Design patterns provide a template solution to a number of different problems, encountered while developing object-oriented software. They do not offer any finished source code (e.g. in the form of library), but more or less they provide enough description on the way how to solve a particular problem. They have been used for around 40 years and they have proven to be good (they are essential part of the skill-set of any software developer). They ease the process of software development in the way of providing a common language for the developers with different level of experience. But in order to use them, one must understand them very well. Although they are very mature concept, people nowadays are still arguing what is the best way to study them. According to some, the first step is to read a book which explains them. Other think that first a developer should learn how to test, then how to refactor and in the end how to apply them. But everyone agree that essential part of study is to start coding with them as soon as possible. In the next few sections I will cover two design patterns I have used in projects developed by me and I will also explain the steps I took in order to understand them.

 

Single Responsibility Principle:

The single responsibility principle is one of the five steps covered in the SOLID design and its states that a class should do only one thing. The idea behind this object-oriented design, is that if all the steps are applied while developing a particular piece of software, the end product will be a robust system that is easy to maintain and in the meantime is open for extensions.

Last summer I had the opportunity to work on a relatively big project with some experienced developers. I was the main developer of the project and I was receiving supervision and advices from my colleagues. I had to develop a sub component of the main application, capable of querying data from the RSS feed of the Apple iTunes store and storing into a database. Basically the steps for accomplishing this task were the follows:

  1. Query the RSS with some parameters and received the result of the query in the form of XML file.
  2. Parse the XML, extract some values from it and used the extracted information to create more lookup queries.
  3. Receive the response from the lookup queries in the form of JSON files, parse it and store it in the database.

So in general I end up with 5 classes (Main class, two classes for parsing XML and JSON, and a utility class with all the functions I needed) for accomplishing this task. They were logically structured in the same way as the requirements stated above. The component was working as expected and then I showed it to my supervisor. He said that it will do the job, but I need to do some serious refactoring if I want it to be readable by other developers. And by that he meant that if this structure makes sense in my head, this doesn’t ensure that it will do the same if other people look at it. The thing he proposed was to implement the single responsibility principle and further split my classes into more logical entities. After some refactoring, I end up with 8 different classes which were structured in the following way: Main class, two classes expressing the structure of both the XML and the JSON files, two more classes for parsing them, one class for generating both XML and JSON queries, a database handler class and a class representing the end product of the component. So to summarize I have changed the structure of the component in such a way that every class was responsible to do only one thing. At the end this made sense to me as well, because it was definitely easy to debug, and because I gave meaningful names to the classes, a developer who only knew the main idea of my project was able to understand the structure and the logic I am following just in a matter of few minutes.

Factory Pattern:

The Factory pattern is another heavily used concept. In general a factory class returns at runtime one of several possible objects that share a common superclass. The possible cases for using it is when the developer wants to provide an interface for creating objects or simply to encapsulate the object creation.

A few years ago I had to contribute for the developing of a tower defence game in JavaFX. The game was simple as it consisted of single map with multiple levels of monsters and five different towers. This was the first time when I saw the factory pattern in action. While I was browsing the source code, in the package responsible for creating the units in the game, there were a number of different classes:

  1. An abstract class called EnemyUnit with private attributes name (string) and damage (double), and public methods for attacking, moving, displaying and setting the damage and the name.
  2. Six different classes representing the different types of monsters in the game, each of them implementing the abstract class EnemyUnit with setters for name and damage.
  3. A class called EnemyUnitFactory which returns an object of class EnemyUnit. The factory class consists of a list of key-value pairs where key is an integer from 1 to 6 and the values are one of the six different unit classes. When the class is invoked, a random number generator generates an integer (with range from 1 to 6) and uses it to access one of the elements in the list. After the element is accessed and object of the given type is created and returned.

This design expresses the main idea behind the factory pattern which is to ensure that the factory has only one job – to create enemy units at run time, and also ensures that there is only one class capable of creating ships.

 

Conclusion:

There are a lot of different design patterns who can be used straight away, or need some tailoring in order to fit in the project. Nevertheless they have proved to be useful and in my opinion every software developer should be familiar with them. There are numerous books with excellent explanation about different design patterns, but according to me the best way to understand them is with coding and practicing.

References:

  1. http://en.wikipedia.org/wiki/Software_design_pattern
  2. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#
  3. http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
  4. http://en.wikipedia.org/wiki/Factory_method_pattern
  5. http://www.oodesign.com/factory-pattern.html