main banner

Development

Design Patterns: What and Why, 2nd Part

Understanding big balls of mud, a common Object Oriented world software problem, and how to defeat and avoid them.

As discussed on the previous document, BIG BALLS OF MUD have really powerful reasons and forces working in their favor, but of all the problems stated, Design Patterns address the skills.


Software development has been there for some years, and often we can identify similarities between the problems that have been arising. How do I decouple object instantiation from the places where it is used? How do I simplify the usage of a tree-like structure of indeterminate depth? It turns out a bunch of people (in fact, four people) in the Object Oriented world once gathered to talk about these repeating software problems, to identify them, to isolate them and most importantly, to share the solutions to them. And then they saw that the solutions were similar, so they identified a pattern to solve them. Design Patterns. These people wrote a book about it: Design Patterns: Elements of Reusable Object-Oriented Software and became known as the Gang Of Four.


So what do we get by using Design Patterns? The classic patterns originally described in the GoF book are aimed at object oriented programming, so in order to understand them we must know about Object Oriented Principles. In fact, it is common that people want to learn Design Patterns and as a result they also learn these principles. One of the most important that drive the identification of a Design Pattern is:


Code must be open for extension, but closed for modification. What this means is that we must identify the parts of the system that are most likely to change and isolate them. Then when the changes come in we can create brand new code and touch as less as possible the existing one. One immediate benefit is that the code was already working before the change, which means than it was not only coded, but also tested and debugged. If you only touch as less code as possible as a result of a modification, you only need to test and debug a minor subset of all the features of the system. So you keep it working with less effort.


Once you think about how to divide parts of a system, you’ll understand better the true nature of the Object Oriented programming paradigm, so instead of coding the full system in just one class, you start creating an engine with interchangeable pieces. And understanding one of these pieces is far easier than trying to understand the full system at once.


One problem with acquiring the skills to apply Design Patterns is that often we think that the technology we’re using already solved those problems. And in fact they already solved a lot of them for us. Frameworks, third party libraries, language built-in features, many times the developer works in an already constrained environment where the platform provides many resources needed to solve those problems. But then the code starts growing and begins to look as a little ball of mud. It takes discipline to think about refactoring the code every time a change comes in, but there are already coding conventions that provide a good rule of thumb for when we should start thinking about a refactor and perhaps apply Design Patterns: the human mind can only think on a few pieces of data at the same time, so if a method takes more than five parameters, people starts having trouble remembering them while coding or reading it, if it is bigger than one monitor screen people need to scroll in order to see it completely, and absolutely remember what it was doing at the beginning. If a class is bigger than 500 lines you’ll begin to get lost in it. So having a modular system shares the same motivation like many other great achievements of our civilization: laziness. It’s too much work having to remember hundreds of lines of code at the same time. Give me just a few.


In order to apply Design Patterns you need to know which ones are available, what problem do they solve and what are their strengths and weaknesses. It’s like a toolbox, perhaps you’ll never use a drill but you know that it is used to make holes. There are a lot of resources listing this kind of information, including the GoF book. Another great book that is specially aimed at learning them is Head First Design Patterns. Perhaps by solving the skill obstacle to have a clean system there will be less BIG BALLS OF MUD out there.


German M.

German has many years of experience working as a developer and his experience is very valuable!

Articles