I was looking up the history of design patterns : according to Wikipedia, they originated in 1977/79 and gained popularity in 1994 after the famous Gof4 book was released. I have been in the Software Engineering world for 20 years now : working for small to mid size and large organizations developing commercial software : surprisingly even though Internet and Google have been here for over a decade , design patterns have not made way into software development shops  as much as they should have –  framework developers have probably used them more profusely :  however software built for direct end user still does not make use of design patterns as much.

Based on my experience and exposure plus having tried to gain knowledge of patterns myself here are a few reasons I can think of:

1) Understanding Patterns from Gof4 and other books requires a solid background of at least one Object Oriented language like Java, C++ , C# etc.

2) The concept of patterns can be very abstract : even though understood in theory , practice of existing patterns does not come easy even if you are programming in object oriented languages.

3) Software development is a team effort and patterns cannot be part of the entire architecture of the product unless all developers in the team are comfortable with them. It may require a significant amount of effort and dedication from an IT shop to get everyone up to speed with Patterns, something which a lot of them may not afford to due to time/cost constraints .

4) Although software architecture has always existed, there is more focus in recent years on the formal role of  “Architect” and dedicated positions which concentrate on design / architecture as opposed to implementation. Pure Software Architects do find a lot more time to focus on the Patterns , hence in Software Shops where such Architects exist , you will see more use of the Patterns.

Design Patterns as laid out by G0f4 book and others are undoubtedly great mechanisms to achieve good design of a software system. However I feel that one can still achieve a reasonably well designed implementation if you keep few core values in mind : Performance , Reusability and Refactoring. There should be a constant effort from a team’s side to Refactor the code , which will not only clean code , achieve Reusability as well. In some scenarios there could be a trade off in Performance in trying to achieve Reusability. For example a typical scenario is taking a layered approach in designing reusable layers , however performance could get impacted if the Request and Response have to travel so many layers. So a balance needs to be achieved between the two. This kind of dedicated effort in applying some of these core principles can result in great software whether the code is written in an OO language or not.

Design Patterns are nothing but Common Solutions to recurring problems in Software Application development. So if we all start paying more attention to recurring problems and find Reusable solutions to these problems , we have used/invented design patterns to implement our software. This is not to undermine the formal OO approach of several Design Patterns : they are extremely useful if applied – however if they cannot be applied directly for whatever reason, adhering to practices of Refactoring and Reusability keeping in mind Performance can also result in well written Software.

However if you are a OO programmer I think a thorough understanding of SOLID principles as laid out by Robert C Martin along with GOf4 and several other OO patterns will further help in building a strong architecture.