Re: GOF - Decorator and STL::Vector
<dkunzman1@cox.net> a ?crit dans le message de news:
1154015093.590330.272320@b28g2000cwb.googlegroups.com...
All -
Thanks for your comments. I'm more experecent as a java developer than
as a C++ developer so sometimes STL and Templates give me a big
headache!
Yet genrerics are part of Java 1.5, aren't they? Anyway, STL is better that
many container libraries I have seen (althouth not perfect)....
I ment 2005 sorry about that.
Also, I'm beginning to agree with you just becuase of the complications
of decorating a Template class like the vector or deque. But the
decorator pattern is really nice since it uses the same interface as
the decorated class so the client that uses the class doesn't need to
know about the change.
Yes, but this works great if you can inherit both the decorated object and
the decorator from a common base class. Otherwise, you need to write *all*
the functions you need in the decorated clas as stubs that call the
corresmponding methods in the decorator class (see below). Although not
really complicated, it makes a lot of boilerplate code that is painful to
write and will slow down your app for close to nothing.
In theory this seems like a really good idea
when the requirements are changing all of the time and or are not even
known. Such that at runtime you can add multiple decorators to a an
object. This is not a fast requirement but seems like a great feature
that will allow the software to be modified easily and still be hold
the design well.
For specific buisness classes, I would tend to agree, but for something as
general as an STL container, I do not believe it will buy you much.
I'm still curious, though it might be an academic question, can you
decorate one of the STL classes and does someone have an example or
could they create one?
Since std::deque does not have a base "interface" class, and is not meant to
be derived (since it doesn't have a virtual destructor), I would use
something closer to encapsulation than the decorator : This is not exactly
the GOF decorator pattern, but it is close enough
template <class T> class LimitedDequeue
{
private: //both private members should be intialized in constructor
or in ad-hoc functions.
std::deque<T>& m_decorated;
std::unsigned int m_max_size;
public:
void push_back (const T& val)
{
if (m_decorated.size() >=m_max_size)
m_decorated->po_front();
m_decorated.push_back(val);
}
/*rewrite all functions and typedefs from std::deque to match the
deque interace and have the
required semantic on the same model as push_back
*/
};
You'de probably better spend your time by writing a custom class that has a
std::deque as private member and define a custom interface, adapted to your
specific need. As Ulrich as pinted out, it is one of thoses cases where too
much academic object orientation might kill the usage simplicity of your
code...
Arnaud
MVP - VC