Talk:Policy-based design

Untitled

While it seems sensible to have a small wikipedia on this subject, wouldn't the current content of this article be more appropriate at wikibooks? Thue | talk 14:35, 15 Jul 2004 (UTC)

Example

This example really shows nothing ... Policies encapsulate concepts. What concept is this in the example? 141.3.26.29 12:23, 2 June 2006 (UTC)

Simple Example (Polished)

template<
    typename output_policy,
    typename language_policy
>
class HelloWorld
  : public output_policy,//should be private
    public language_policy//should be private

in the example shown HelloWorld IS-NOT-A output_policy or language_policy so it should be private Inheritance. as it is IMPLEMENTED-IN-TERMS-OF Relationship

Wrong. Policies should always be inherited using public inheritance, since using private inheritance precludes the policies from enriching the interface of the host class (i.e. adding methods which pass through the host class from the policy to the code that uses the host class), which is a key feature of the policy idiom, and mentioned in the article. This is not OOP, so OOP principles of when to use public vs. private inheritance don't apply (also mentioned in the article). BradAustin2 (talk) 10:42, 29 November 2008 (UTC)

This is not the point the original comment was making. In the example, only the host class use the policy, where its Run method is-implemented-in-terms-of the policies. Whether or not we use public or private inheritance depends on the specific use case. In this use-case, private inheritance will fit the picture better.

Public inheritance bring the problem that you can have a pointer to the Base, and let it point to a host object. It may not be desirable in this case, since the user can call delete upon such a pointer. Making the destructor protected so that this doesn't happen should be the least.

*If* you want to enrich your interface using the policies that you inherit from, you can still do that when using private inheritance, by a using-declaration in public/protected access sections.

So it is not *that* easy as you made it sound like. However, i don't care changing the article. Just my two cents. 84.174.222.121 (talk) 02:14, 29 May 2009 (UTC)

I understand the point the original comment was making. I don't think you understand mine.

The host class is written without any knowledge of the policy classes that are passed to it, beyond what it specifically needs to know about. HelloWorld expects the output policy to have a Print() method, and the language policy to have a Message() method. But that does *not* mean that those are the only methods that any given version of those policies can have. The point of inheriting the policies publicly is not so that Run() and Message() are visible from the outside (which they shouldn't be), but rather so that any other methods that the policies may have, and that HelloWorld doesn't even know about, can be visible from the outside, if the policies want them to be. That's what interface enrichment is about.

Here's an example:

#include <fstream>

class HelloWorld_OutputPolicy_WriteToFile
{
    std::string file_name;

public:

    void SetFileName( const std::string & value )
    {
        file_name = value;
    }

protected:

    template< typename message_type >
    void Print( message_type message )
    {
        assert( ! file_name.empty() );
        std::ofstream my_stream( file_name.c_str() );
        my_stream << message << std::endl;
        my_stream.close();
    }

};

int main()
{
    typedef
        HelloWorld<
            HelloWorld_OutputPolicy_WriteToFile,
            HelloWorld_LanguagePolicy_English
        >
            yet_another_hello_world_type;

    yet_another_hello_world_type hello_world3;
    hello_world3.SetFileName( "MyFile.txt" );
    hello_world3.Run();
}

If HelloWorld inherits the output policy privately, then main() can't access SetFileName(), which it needs to in order to communicate the file name to the policy. HelloWorld can't pass SetFileName() on manually, as you suggest, because HelloWorld doesn't even know about SetFileName(). You can't know, when you write a host class, what methods your policies may want to pass through you to your user, so the host needs to just pass on everything (by inheriting publicly) and let the policy deal with visibility issues (by declaring its methods either public or protected).

I understand the motivation to avoid bugs of the sort where an object is deleted via a pointer to a base class. But managing the lifetime of an object of a host class using a pointer to the policy class just isn't something that is normally done anyway. So the added safety advantage of using private inheritance is very small, and not worth the cost of precluding interface enrichment. (But if you want to give the policies a protected destructor, that's fine, and certainly doesn't hurt anything.)BradAustin2 (talk) 23:03, 23 June 2009 (UTC)

for See Also section

It seems this idiom is looking similar to Object Teams extensions of Java - see http://en.wikipedia.org/wiki/Role-oriented_programming. Can someone, experienced in C++, confirm this my idea and add reference to the article or reject it and explain me my mistake? —Preceding unsigned comment added by 212.55.117.106 (talk) 11:06, 10 August 2010 (UTC)

Checked for copy-written material?

I just changed the opening sentences of the last two paragraphs of the overview. They were written in the manner of an author talking to the reader (or instructor to student) in the way *many* technical books are written. This leads me to suspect that some of the content may have come from a book. I did some spot checking against Modern C++ Design but did not find any support for this suspicion.

If others, more well read than me, can spot check this it would make for a better article. Just use the version prior to my edit. Arbalest Mike (talk) 20:44, 12 August 2014 (UTC)

Suggest merge to Modern C++ Design

This design approach is a well known application of genericity, and the name "policy-based design" is simply the terminology used for this approach in a particular book. For example, this approach is widely used in the ML languages, for which parametric modules (functors) are specifically designed, and even in C++ its use is well-known, e.g. allocators for memory management policy.

The article itself states that the book simply popularized the term, but does not give any discussion on this prior usage or citations to prior publications. This article is not suitable for a separate encyclopedic article, and should be merged with the article of the book itself- Modern C++ Design.128.122.4.235 (talk) 12:53, 26 March 2018 (UTC)