Design patterns changed the way people approach to software, and also put Object Oriented Programming in the map and pushed Object Oriented "Modern" languages into everywhere. Before Design patterns software had its own set of problems, and patterns existed but where not formalized. In this talk i explore the history of design patterns, its characteristics and caveats, along with some examples of problems where can be solved with some of the most common design patterns used.
As computer programmers created more complex arquitectures in hardware and software and staff grew bigger, they started to create libraries, frameworks and tools to manage all the complexity that software involves. Improving the arquitechture of software became important for planning, development, maintainance, extensibility and reusability.
In another field (Architecture), Christopher Wolfgang Alexander, was researching on the idea of "Empower people to design at any scale". So between 1977-1979 he created a pattern language that people could use to design buildings and arquitects could use this language to design the specific of this buildings.
Using this same ideas, Kent Beck & Ward Cunningham, tried the pattern language approach for a project they where working on. Worked perfectly and they went and published theyr results on OOPSLA conference. This led to an increasing interest on the idea until 1994, that is when the book known as The Gang of Four was published and is the most consulted book for design patterns in object oriented languages so far.
The book presents a collection of patterns, organized on 3 main groups, and this became the base for many education courses and discussions since those days. The books describes the patterns in a consistent way and this set the basis for all the future patterns, name, problem, solution and consequences. but people learning software design patterns often miss some important things to remember.
This are not bullet proof solutions that can be applied anytime and in mass numbers to guarantee success on the software they are writing. When this happens software increases in complexity and in costs, which is something we don't like. This is because this are strategies to solve a problem not recipees.
Then why should we care to learn them? Because when we are facing software its better to be prepared to solve the problems we will be solving and patterns are tools that we will have to aid us in this task. So the best advice to take from patterns is to learn them all, then forget them all.
Learn to become a better software architect, by choosing the right tools in the right places.