Notes from Andre Alexandrescu’s Modern C++ Design

Here are my highlights from Andre Alexandrescu’s Modern C++ Design: Generic Programming and Design Patterns Applied.

  1. Policy-Based Class Design
    • Overview:

      Policy-based class design fosters assembling a class with complex behavoir out of many little classes (called policies), each of which takes care of only one behavioral or structural aspect.

    • The challenge in any design is that you’re forced to choose a solution from a combinatorial solution space.
      • Experienced designers are like experienced chess players: they can see many “moves” in the future and anticipate tradeoffs from a particular “correct” design choice.
    • A “do-it-all” interface will fail because of the growing gap between syntactically valid and semantically valid uses of the library.
    • Design-targeted libraries need to help user-crafted designs to enforce their own constraints, rather than enforcing predefined constraints.
    • Policy-based design combines the advantages of multiple inheritance and templates, while simultaneously avoiding their weaknesses.
      • Policy: a class interface (or class template interface) with inner type definitions, member functions, and member variables that emphasizes behavior rather than type.
        • Reminiscent of the Strategy design pattern
        • Unique advantages: static binding and type knowledge
      • Unlike a Java-style interface, a policy “interface” is loosely defined. They specify syntactic structures that should be valid rather than the exact functions that should be implemented.
        • As a consequence, different implementations of a policy may have different (or extended) behavior.
          • If you use a function not provided by all policy classes, your code will work just fine until you change concrete policies (as you would expect).
      • Host classes assemble policies together into a single complex unit. (E.g., WidgetManager uses the Creator policy to define how widgets get created (p. 9).)
      • By using template template parameters, you can avoid redundant (or easily inferred) parameters and give the host class access to the template. Thus, do this:
         // Libarary code
         template <template <class Created> class CreationPolicy>
         class WidgetManager : public CreationPolicy<Widget> {}
        
        
         // App code
         typedef WidgetManager<OpNewCreator> MyWidgetManager;
        

        (The Widget in the library class’s inheritance allows it to specify the type it works with—it is the Created class.)

      • Combining policy classes in a single host class:
         // Library code
         template <class T, template<class> class CheckingPolicy, template<class> class ThreadingModel>
         class SmartPtr;
        
        
         // App code
         typedef SmartPtr<Widget, NoChecking, SingleThreaded> WidgetPtr;
        
        • The most important thing to consider in decomposing a class into policies is that the policies should ideally be orthogonal (they shouldn’t interact).
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s