This is something that had been bothering me ever since I got my own copy of “Design Patterns,” it started after I finished reading the Creational Patterns. “Why is this so difficult?” I thought to myself, patterns felt incomplete, they weren’t solutions, more like frameworks for solutions.
In Data Structures, we created Abstract Data Types in C using structs and typedefs, these ADTs provide encapsulation in C, similar to Classes in C++, except they are more difficult to implement. We were following the “Class” pattern in C, trying to overcome a limitation of the C programming language. It wasn’t until C++ that we were finally able to implement encapsulation easily with Classes.
Back to the Factory family of patterns. After programming with Ruby and Python I realized we can use Meta Classes, classes that define classes at run time, as a substitute for the Factory patterns.
With this type of programming, we don’t need to have factories and products, because these meta-classes are the factories. Languages such as Python and Rubysupport Meta programming, don’t suffer from the limitations of Java/C++/C#. If meta programming were available to us in C++/Java/C#, then we wouldn’t have to rely on Factory patterns, instead we would use meta-classes.
Also, while thumbing through my Java Design Patterns book, I finally realized that sometimes you have to use the Adapter pattern because Java doesn’t allow multiple inheritance. I understand that multiple inheritance can be dangerous, but, it is still a limitation of the language.
I’m sure other patterns from the GoF have their own counterparts as language features in other languages, but I don’t know them, yet.
Related posts:
While dynamic (“duck”) typed languages like python or ruby allow for quick meta classes, the same can be done in C# (albeit a bit more work is required). A Factory isn’t used to overcome a language limitation IMO, it is to further supply encapsulation and most importantly: adhere to the DRY principle.
Also, in your point on why patterns are more like frameworks for solutions, rather than solutions themselves… I think that they are more portable this way, and are generic so that they may gain more usage. No one solution will work for all types of software, but the community has extracted (as computer scientists do so well) a common set of tools that anyone can use (or not use) in their designs.
You should read Analysis Patterns by Martin Fowler. It supplies more concrete solutions to typical software problems. It suggests an object model and interaction techniques for health care, insurance, and a few others.
Ben Scheirman - 25 Sep 06 at 7:08 am
I think C# and the .net CLR don’t fully implement meta programming.
I’m still going back to the “Class” Pattern in C. You’re creating structs and typedefs when what you really need are classes. It’s almost as if I’m breaking the DRY principle by doing the same things over and over again. Wouldn’t it be cool if you could just create a “factory pattern” class that you could reuse?
I want to read Analysis Patterns by Martin Fowler, but it isn’t available here.
Shey's Rebellion - 25 Sep 06 at 6:14 pm
I agree that design patterns are missing language features. If I see a pattern in my code, it usually means I’m missing some abstraction.
http://c2.com/cgi/wiki/Wiki?AreDesignPatternsMissingLanguageFeatures
wtetzner - 20 Jun 09 at 8:00 am