A World Full Of Patterns


We live in a world that is full of patterns. And what is a pattern anyway? In general a pattern can be described as an arrangement of repeated or corresponding parts. If we are talking about a design pattern is software, then it is a reusable solution to a commonly occurring problem [1], a template of some sorts. So why do people try to find patterns anyway? How are they useful? In the most general case we strive to find patterns in order to get rid of the chaos that surrounds us or maybe when we see a pattern it helps us understand the inner workings of the universe. Who knows? Who cares why we are looking for them? The thing is that patterns are generally a good way of understanding how things are constructed. If you think about it we are an example of nature’s patterns too. Every person is different yes but nevertheless our specie have key features, such as limbs; organs etc..,that categorizes us as being human. And the main reason why we want to see patterns is that once you see that they are not random and when something is not random and there is some repetition within it, some sort of pattern that keeps reoccurring, you understand it better and maybe you can use that understanding in recreating it or using it as a basis for creating something even better.

In this article I will not talk about patterns in that general sense though. Instead I will try to explain their importance in the context of software projects and how they can be helpful for a successful project.

Algorithmic Patterns:

First I will talk about algorithmic patterns. We all have come across an algorithm or two in our time either programming an algorithm or implementing it in a real-world scenario. It is basically a step by step execution of simpler tasks that achieve a harder goal in the end. If the algorithm is well known to your colleagues then there would not be any need of explaining it to them in details and one of the most time consuming tasks when working in a team is to explaining why and how your code works. If it is algorithm known by most then this section of the project can be understood and maintained by others. And in a large-scale system the more people understand how everything works the better.

Programming Patterns:

It has been a long time since the first computers has been invented and since then so many things that were previously done by hand are now automatic. And why would it not be? The whole idea of technologies is to make our lives easier. The more we come across the same problem the more familiar we are with its solution (if we have found it). So the whole idea is if you find something that is recurring more than twice why not implement it a single time as a function/algorithm and then use that when you come across it again and avoid solving it all over again. In small and large-scale systems alike by avoiding repetition the outcome is that the system that has been developed becomes easier to understand hence easier to be maintained, extended and managed.

Patterns in programming can be the whole approach of reaching the solution of a problem. These are design patterns that are basically a way several programmers can communicate on a similar language. Since everybody has its own way of doing things it is often hard to write code in the same style. This is due to different backgrounds or way of thinking in general.  In large-scale systems since the work can’t be done by a single person and most parts are connected to each other there is the issue of being able to connect them properly. This requires a lot of communication and effort. One way of reducing the amount of effort is to implement the different parts of the system in a way that is easier to understand by most people involved. One way to do that is to use design patterns that are well known by the different teams. In other words design patterns become some sort of a shared vocabulary. Such patterns can either be developed or agreed upon by all of the connected teams or be so famous that everybody would know how to use them. In both cases by using design patterns the documentation of the system and the communication between different teams and team members become much easier.

Architectural Patterns:

These are patterns that occur at higher level than design patterns and are basically the way a large system can be organized either by being divided into smaller chunks or be made in an adaptive way. There are many examples of such patterns such as Layered Abstractions, Pipes and Filters, Blackboard, Model-View-Controller, Presentation-Abstraction-Control, Mircokernel, SOA, etc. I will not go into detail explaining every one of them. However I will mention the advantages and disadvantages of implementing such architectural patterns in a large-scale system. The decision a software architect or even an architect makes at the beginning about how the whole system/building would be structured has a huge impact on the project. Every single choice has consequences and every structure that is chosen has advantages and disadvantages. The key is to choose the best that fits the need. By using an already existing pattern as a foundation to your project can help you see issues that you have not considered. Since most of these patterns’ issues are known if you implement one of them you would know what to expect and if the disadvantages do not matter in your case then the architecture fits good to your problem. Of course the idea is to implement an architecture that is tailored to your specific problem but if there are similar solutions and similar architectures why not use them? There is no need to reinvent the wheel. In most cases it is much easier to extend an already existing architecture and modify it according to your needs than start from scratch. Another advantage is that when using an architectural pattern then documentation would be a lot easier since the pattern already has documentation. And since most people leave documentation for a later stage some of the choices made might be forgotten [9] thus leading to incomplete documentation. It is well known that documentation in large-scale systems is very important. It can be used as a manual to a user, or a way of communication between different teams within the project. It does not matter the purpose of it the thing that matters is that it is more useful to be complete than incomplete with some key things omitted. So one way to tackle the problem of documentation is to use an existing architectural pattern and thus reduce the chance of omitting to document some decision. The disadvantages from architectural patterns differ for each and as long as these architectures can be tailored to reduce them they are worth being used as a base to your architecture.


Patterns exist everywhere in the real-world and in software alike. They provide a common ground which can be used for communication between different people or can be used to gain better understanding of different problems. Either way they provide great aid in developing, maintaining and managing large-scale projects that involve a the need of communication, documentation and overall good management.



[1] Wikipedia entry on Design Patterns

[2] Avoiding Repetition M. Fowler. IEEE Software, 18(1), 2001.

[3] Is This a Pattern? T. Winn, P. Calder. IEEE Software, 19(1):59-66, January/February, 2002.

[4] Past, Present, and Future Trends in Software Patterns. F. Buschmann, K. Henney, D.C. Schmidt. IEEE Software, 24(4):31-37, July, 2007.

[5] Design Patterns: Abstraction and Reuse of Object-Oriented Design. Erich Gamma, Richard Helm, Ralph E. Johnson, and John M. Vlissides. 1993. In Proceedings of the 7th European Conference on Object-Oriented Programming (ECOOP ’93), Oscar Nierstrasz (Ed.). Springer-Verlag, London, UK, UK, 406-431.

[6] The Growing Divide in the Patterns World. D. Manolescu, W. Kozaczynski, A. Miller, J. Hogg. IEEE Software, 24(4):61-67, July 2007.

[7] The pros and cons of adopting and applying design patterns in the real world. M.P. Cline. Communications of the ACM, 39(10):47-49, October, 1996.

[8] Design Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, and Vlissides 1995, Addison-Wesley, ISBN 020163361X.

[9] Using Patterns to Capture Architectural Decisions. N.B. Harrison, P. Avgeriou, U. Zdun. IEEE Software, July/August 2007.

[10] Using Architectural Patterns and Blueprints for Service-Oriented Architecture. M. Stal. IEEE Software, March/April 2006.