Modern C ++ design note Chapter 1 Policy-based Class Design

Chapter 1, policy-based Class Design

If your field of knowledge is a circle, as your knowledge grows,
The longer the perimeter. In other words, the greater the intersection of knowledge that you do not understand, the more ignorant you may feel. This is just a few pages.
After design. It seems that a new space has been opened for itself, and C ++ can still be written like this :). This is a surprise from the first policy-based Class
Design begins.

Institute
Policy-based design: Policy-based design, also known, which is defined by haoku on Wiki.
As policy-based class design or policy-based programming, is a computer
Programming paradigm based on an idiom for C ++ known as your ies. it
Has been described as a compile-time variant of the Strategy pattern,
And has connections with C ++ template metaprogramming. It was first
Popularized by Andrei Alexandrescu with his 2001 book Modern C ++ Design
And his column generic in the C/C ++ users
Journal. In fact, this definition on Wiki is almost the same as it was not said, a programming method, a variant of the Strategy Mode. In our own vernacular, policy is the first
Class defines some interfaces or templates (this is a bit like those in strategy), and the specific template class inherits these policies.
Class, so that you can selectively assemble and instantiate the new type you want. This avoids multiple inheritance issues such as type and copy status switching.

Let's look at an example.
Template <
Typename output_policy,
Typename language_policy
>
Class helloworld
: Public output_policy,
Public parameter age_policy
{
Using output_policy: print;
Using required age_policy: message;
Public:
// Behaviour Method
Void run ()
{
// Two policy methods
Print (message ());
}
};

# Include

Class helloworld_outputpolicy_writetocout
{
Protected:

Template <typename message_type>
Void print (message_type message)
{
STD: cout <message <STD: Endl;
}
};

# Include

Class helloworld_languagepolicy_english
{
Protected:
STD: String message ()
{
Return "Hello, world! ";
}
};

Class helloworld_languagepolicy_german {
Protected:
STD: String message ()
{
Return "Hallo welt! ";
}
};

Int main ()
{
/* Example 1 */

Typedef
Helloworld <
Helloworld_outputpolicy_writetocout,
Helloworld_languagepolicy_english
>
My_hello_world_type;

My_hello_world_type hello_world;
Hello_world.run (); // returns Hello world!

/* Example 2
* Does the same but uses another policy, the language has changed
*/

Typedef
Helloworld <
Helloworld_outputpolicy_writetocout,
Helloworld_languagepolicy_german
>
My_other_hello_world_type;

My_other_hello_world_type hello_world2;
Hello_world2.run (); // returns Hallo welt!
}

Very
Obviously, helloworld_outputpolicy_writetocout, helloworld_languagepolicy_german, and
Helloworld_languagepolicy_english is three policies
Class, I think it is silly to say that at least a bunch of new classes are not displayed (for example, you do not need to redefine a bunch of new classes yourself ).
Helloworldouputenglish, helloworldouputgerman and other similar new classes, of course, the compiler did this during actual instantiation.
It's just that you don't need to do this manually, and there won't be a bunch of building blocks you need to maintain! )
Therefore, in principle, it is a good choice for many dynamic strategy applications to be handed over to the policy class.
Class also has the advantage of finding errors right away during compilation. You Need To Know syntax valid but semantic error is more
SUX than invalid syntax, a good libraray implementation should try to avoid the existence of such a semantic error.
Now let's make some changes and add an interface in helloworld_languagepolicy_english.
STD: String message2 ()
{
Return "2 Hello, world! ";
}
Add an interface in helloworld
Void run2 ()
{
Print (message2 ());
}
However
If we add the hello_world.run2 (); statement in the main function, there is no problem. However, it is compiled when hello_world2.run2 (); is added.
Error c3861: 'message2': identifier not found.
Obviously, helloworld_languagepolicy_german does not have such an interface. Therefore, policy is used.
In class, the compiler can help you do some type checks, instead of letting you use the so-called time-consuming rtti to know your exact type during running, you will determine whether to support a specific class.
To avoid the type check during the runtime.
If we look at these policies more carefully
We can find that it is protected. this is not accidental. From the very beginning, the C ++ teacher taught us that the base class should have virtual destructor. Otherwise
It cannot be a good analysis structure. However, we do not recommend the expensive method of virtual destructor. As long as we set the policy class destructor to protected,
Therefore, you cannot instantiate these policies separately.
Class, only our design can seamlessly call their destructor to correctly destroy used resources. It seems to be a great idea.
Let's write it here today. Let's take a long time...