Re: GOF - Decorator and STL::Vector
- From: "dkunzman1@xxxxxxx" <dkunzman1@xxxxxxx>
- Date: 27 Jul 2006 08:44:53 -0700
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!
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. 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.
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?
Doug
Ulrich Eckhardt wrote:
dkunzman1@xxxxxxx wrote:
Well, I just finished taking a Design Patterns class at Johns Hopkins
and would like to apply what I have learned.
Beware of the "when you have a hammer, every problem looks like a nail"
antipattern!
Besides that, I'm using the command pattern on a long running
application and the undo stack does not get cleared (ever possibly) so
I would like to limit the size of the stack to something reasonable
like 500 undo operations. I'm using a vector to hold the undo stack
and I don't beleive you can limit its size.
A vector is a bad idea, because you will be erasing elements from the front
when you limit the size. Doing so requires a copy of all other elements
though, so it is not very efficient. Two other containers are better
choices, list and deque, for your job deque will probably be the right
choice, you don't need the added flexibility of being able to insert and
remove in the middle.
Now, I'd suggest you just think about the interface the undo stack should
have first i.e. what operations it needs to support like pushing undo
operations, popping them back and checking whether it is empty. In addition
to perhaps clearing it and configuring its maximal size. Then, you can
implement this interface with whatever container you want.
I'm using Visual Studio 5.0 on Windows 2000/sp 4.0.
Ahem, are you sure? Even Visual Studio 6, which is still rather popular, is
not supported by MS anymore because it is almost ten years old. VS5 is too
far out to learn C++ IMHO.
I thought the decorator would be a good way to modify the vector since
as requirements change I could add more decorators, possible at
runtime, with limited effect on the application.
Don't overcomplicate things. Maybe you need it, maybe you don't, I can't
tell as I don't know your design, but in general prefer simple solutions.
Making things too abstract and giving lots of possibilities and points of
customisation is a bad idea for an application writer (as opposed to a
library writer), don't fall into that trap.
Uli
.
- Follow-Ups:
- Re: GOF - Decorator and STL::Vector
- From: Arnaud Debaene
- Re: GOF - Decorator and STL::Vector
- References:
- GOF - Decorator and STL::Vector
- From: dkunzman1@xxxxxxx
- Re: GOF - Decorator and STL::Vector
- From: Arnaud Debaene
- Re: GOF - Decorator and STL::Vector
- From: dkunzman1@xxxxxxx
- Re: GOF - Decorator and STL::Vector
- From: Ulrich Eckhardt
- GOF - Decorator and STL::Vector
- Prev by Date: Re: GOF - Decorator and STL::Vector
- Next by Date: Bug in std::lower_bound (VS2005/Debug)?
- Previous by thread: Re: GOF - Decorator and STL::Vector
- Next by thread: Re: GOF - Decorator and STL::Vector
- Index(es):