If you examine the progress of software development over our history, one aspect of improvement is the way we represent the software while creating it. I began by writing assembly language for very slow microprocessors (the Motorolla 6809e, which ran at less that a megahertz)... today very few developers write code this close to the hardware.
But even assembler was not, in fact, what the computer ran. The representation of the code, created by me, was converted by a hex loader into the actual language of the computer. This is also true for C, and Pascal, and Haskel, and Java, etc... A software developer does not, generally speaking, create software. The developer creates some level of abstract representation of the software, which is converted by a compiler and/or runtime interpreter into the actual language of the machine.
We know this, but sometime don't take this into consideration when picking and choosing languages and techniques. Each language creates a different kind of abstract representation, and more powerful abstractions create more maintainable code.
One of the earliest languages that I was exposed to that contained the notion of an "object" was C++. As a C programmer of many years, I found the construct of "object" to be an interesting one, of perhaps some limited use. Objects could contain private data and implementing code, and thus could help to prevent unwanted side-effects from occuring when the system was changed. In other words, objects were a way of encapsulating state and functionality.
This is true, of course, and led to an object-based approach and object-based languages like Visual Basic. C++ "had objects", but you could program in C style if you wanted to, and most of us had been. Java, and later C#, did not give you such an option. Everything had to be an object.
Because of this, eventually I, like my colleagues, realized that objects could be far more useful and powerful if we thought of them differently and used them differently. The notion of "object-oriented" led us to consider that objects could lead us to a fundamentally different way of modeling, and thus could radically change (and improve) our success in building and maintaining systems.
suspect most people reading this experienced a similar insight at some point along the way; objects are good, but object-oriented programming is where their true power comes from.
At PMI we think a similar distinction can be made about design patterns. Learning patterns can be useful, but the real power of patterns does not lie in simply learing and "using" them, it lies in the notion of "pattern-oriented development". This is not a trivial distinction, any more than "object-oriented" is, and it takes time to make it clear just how patterns can yeild the most value to the development process.
Our training in patterns has this ambitious goal -- not just to teach you a set of patterns. That we could do fairly easily and, frankly, you could probably learn them just as easily on your own. The value of taking the patterns training we offer is that we teach you what it means to be "pattern-oriented", and the power and leverage this will give you when creating, maintaining, debugging, and enhancing your software.
We do this by explanation, demonstration, and by giving you an opportunity to experience this technique through classroom exercises.