January | 2008 | adam's Xanga Site

Lately I have become really interested in Policy-Based class design. You can blame Andrei Alexandrescu and his book, “Modern C++ Design: Generic Programming and Design Patterns Applied”. It is a pretty awesome book, whether you are a C++ programmer or not. It gives some great insight into some new design patterns that you can not only use in place of traditional OOP design patterns, but can use to augment them.

Using traditional OO, if I was creating a SocketLibrary, I could create a class heirarchy that had SingleThreadedSocket, MultiThreadedSocket, AsyncSocket concrete classes. But then say the client of my socket classes wanted to be able to use different buffering techniques for the underlying os sockets. All of a sudden I could have SingleThreadedBufferedSocket, SingleThreadedNonBufferedSocket, MultiThreadedBufferedSocket, etc…

I have run into this problem with traditional OO programming so many times in my programming job here at xanga. There ends up being one part of the class I want to change, but it is somewhere up in the class hierarchy, so I have to pollute the hierarchy with an override for that functionality. Before you know it, libraries are overly complex, programmers are using the wrong classes, and the probability for mistake rises dramatically.

Andrei’s solution: Policy-Based class design. Here is a brief rundown of Policy-Based class design taken from the book: “In brief, policy-based class design fosters assembling a class with complex behavior out of many little classes, each of which takes care of only one behavioral or structural aspect.” Basically, you can construct your classes to be nothing more than containers for policies, and use the C++ templating engine to pass different policy classes to your container. This forces the designer to think more in terms of decomposing a class into little pieces that a client may want to override, creating policies that most programmers will use by default, but allowing the simple overriding of almost any aspect of the class.

I’ll finish here with an example of a simple policy based class. Say I have a factory of widgets, and I wanted to move how the creation of those widgets is done into a policy.

template <class T>
struct OpNewCreator
{
   static T* Create()
   {
      return new T;
   }
};

template <class T>
struct MallocCreator
{
   static T* Create()
   {
      void* buf = std::malloc(sizeof(T));
      if (!buf) return 0;
      return new(buf) T;
   }
};

template <typename CreationPolicy>
class WidgetFactory : public CreationPolicy
{
…
};

As a user of this library, I can say:

WidgetFactory<MallocCreator<Widget> > myFactory;

Now, whenever WidgetFactory needs to create the object, it will just call the Create() function. If i want my own policy, I can create it and pass it in as the template parameter.

The code might look a little funky, but the book discusses many techniques for making the library syntax much cleaner. I don’t want to duplicate all of his ideas here, so if you are interested, buy his book.

adam's Xanga Site

Month: January 2008

Deleted my MySpace account!

Policy-Based class design

International Delete Your Myspace Account Day

LibNAT Round 2

Pain!

adam