Gang of Four - Design Patterns - are those pattern samples coded in outdated way?

Question

So to clarify my question... each pattern in infamous GoF book - Design Patterns Elements of Reusable Object-Oriented Software - has its code samples in C++.

A

Answer 1

Authors has used the code as examples, not that they've written production code. Production code are more robust and checks for errors and exceptions. Such books usually don't show these, neither do they contain try-catch block or other business-logic.

The book is intended for ideas, concepts, as to how to design your program to solve commonly occurring software problems, rather than what syntax or code to use. Also, wherever the authors has used raw pointers, you can replace them with smart pointers and the likes (if possible), to make it more robust.

However, dynamic polymorphism can be acheived only through pointers or references, so they're something that're still valid, and used even in production code.

Besides, its also true that in the last decade the way C++ code is written has changed a lot. So you can incorporate these new techniques with the old idea/patterns presented in the GOF's book. For example, Andrei Alexandrescu has used templates to implement many patterns (old patterns) in his book:

Modern C++ Design: Generic Programming and Design Patterns Applied

Answer 2

They are a little out-dated, yes. But part of the point of those books is that these patterns are useful in several different languages and with several different styles. So while the code is a little old in the tooth, the ideas behind it aren't, and those ideas are what's important in those books.

I would like to see some pattern implementations that took advantage of meta-programming techniques. I strongly suspect some patterns, such as Bridge, Adapter and possibly Facade are much less tedious to implement using meta-programming. From the other answer, and reading the description, it looks like Modern C++ Design: Generic Programming and Design Patterns Applied might be a good book for this sort of thing. I can't personally vouch for it though.

Other than the possible use of generic programming and template techniques, the main differences are that bare pointers are a rare thing in C++ nowadays. There are effective smart pointer types that should usually be used instead because they handle a lot of the resource management issues for you. Frankly, unless you know really well what you are doing, I would not recommend attempting a generic programming based design anyway.

Here are some examples of which sorts of smart pointers to use in various contexts. These examples assume that you have a C++ that includes the TR1 (Technical Report 1) extensions:

When you have a pointer to something that is wholly owned by the object pointing to it, use ::std::auto_ptr (or ::std::unique_ptr in C++1x). Keep in mind that ::std::auto_ptr cannot be stored in STL containers, but ::std::unique_ptr does not have this problem. Examples might be the Component pattern (as long as no two sub-components were shared), the Facade pattern, and the Adapter pattern. Also, the Factory pattern should likely be producing ::std::auto_ptrs (or ::std::unique_ptrs in C++1x) unless there is a really good reason to be producing ::std::shared_ptrs.

When you have a pointer to something that has shared ownership, used ::std::tr1::shared_ptr. For example, the Flyweight pattern. Also, in some cases, the Component pattern may have this property as well. It may also be useful in Bridge pattern.

When you have a pointer to something that to something that you do not logically own, then a ::std::tr1::weak_ptr is the way to go. Keep in mind that if you use ::std::tr1::weak_ptr you should also use ::std::tr1::shared_ptr for all the objects that do logically own (or share ownership) of the pointed to item. An example for this is the Observer pattern.