Just to clearify: By "envelope/letter" I meant a pattern where
the handle object can manage polymorphic objects regardless of
having value or (counted) reference semantics. This is maybe
not what you had in mind.
The name letter/envelope comes from Coplien. There's certainly
no problem with it using counted pointers to implement copy on
write, but I think giving it reference semantics changes the
idiom, resulting in something more like the strategy pattern.
(I also can't see the point in having a special class for the
"reference"---reference semantics are largely handled by
pointers, smart or otherwise.)
Here's an example of what I was thinking of. In this case it
actually HAS value semantics but it doesn't have to.
#include <algorithm>
#include <string>
class LetterBase {
public:
virtual ~LetterBase() {}
virtual double foo(double x) const = 0;
virtual void tweak(double p) = 0;
virtual LetterBase* clone() const = 0;
};
class Envelope {
LetterBase* ptr;
public:
explicit Envelope(LetterBase* p=0) : ptr(p) {}
Envelope(Envelope const& e)
: ptr(e.ptr==0 ? 0 : e.ptr->clone()) {}
~Envelope() {delete ptr;}
void swap(Envelope& with) {std::swap(ptr,with.ptr);}
Envelope& operator=(Envelope e) {swap(e); return *this;}
double foo(double x) const {return ptr->foo(x);}
void tweak(double p) {ptr->tweak(p);}
};
inline void swap(Envelope& a, Envelope& b) {a.swap(b);}
/// creates an Envelope object -- possibly delegating
/// the creation of a LetterBase-derived object according
/// to the given string parameter.
Envelope factory(std::string const& blah);
int main()
{
Envelope e = factory("bar42");
double y1 = e.foo(23.1);
e.tweak(99.0);
double y2 = e.foo(23.1);
}
One of the important aspects in the original Coplien
presentation is that the "letters" derive from the "envelope".
I'm not sure it's an essential point, but it does avoid having
to reproduce the interface twice. Something like:
class Shape
{
public:
Shape( Shape const& other )
: myPtr( other.clone() )
{
}
// Typically, however, we'd have constructors which
// knew how to create their own implementation, so
// client code would never construct a derived.
Shape( Shape* impl )
: myPtr( impl )
{
}
virtual ~Shape()
{
delete myPtr ;
}
virtual void scale( double factor )
{
myPtr->scale( factor ) ;
}
// ...
protected:
Shape()
: myPtr( NULL )
{
}
private:
Shape* myPtr ;
} ;
The only real advantage in this, I think, is that you don't have
to duplicate the interface. You're guaranteed that the
interface seen by the client is identical to the one you derive
from.
This looks pretty much like the code I wrote a couple of weeks
ago. It combines the "compiler firewall" idiom with
polymorphism and value semantics. In my case it was quite
useful. The overhead is moderate and it doesn't affect the
performance of typical client code I have in mind.
Yes. I've used it from time to time. Most of the time,
polymorphism seems to apply to objects which have identity,
which means reference semantics, in which case, I'll just use a
classic hierarchy and pointers (smart or otherwise, depending on
the role of the object in the application). There are also a
fair number of cases where the identity doesn't matter, but the
objects have no mutable state, so I can use reference semantics
just as easily as value---such cases are usually best handled by
a smart pointer (unless you have garbage collection, in which
case a raw pointer works just as well). But every once in a
while, there is a need for true value type with polymorphic
behavior, in which case I use the envelope letter pattern.
Deriving from the envelope, as above, but probably because
that's the way I learned it, more than for any othe reason.
