is visitor the best solution?

ManicQin <ManicQin@gmail.com> writes:
> My main problem is that passing a pointer to the log class to the
> policies looks like a hack.. you know what I mean? But the more I
> think about it the more it looks like the problem only resideds in
> my brain .

I agree that it's a hack. Archiving is an additional capability
to be added to the basic logging functionality. The logger itself
should just do logging.

>> class Logger
>> {
>> private:
>> long bytesWritten_;
>>
>> public:
>> Logger() : bytesWritten_(0) { }
>> virtual ~Logger() { }
>>
>> virtual long bytesWritten() const { return bytesWritten; }
>>
>> virtual void log(string message)
>> {
>> // logging behavior
>> }
>>
>> }
>>
>> class ArchivedLogger : public Logger
>> {
>> private:
>> Logger* logger_;
>>
>> public:
>> ArchivedLogger(const Logger* logger) : logger_(logger) { }
>> virtual ~ArchiveStrategy() { }
>>
>> virtual bool log(string message) = 0;
>>
>> }
>
> I missed something in your code,
> *) the log pure vrtual function is at the deriver?!?
> *) than who calls the archive function?

The client creates the logger they want with something like:

logger = new PhaseOfMoonArchiver(new ConcreteLogger());

then uses it like any other logger. The PhaseOfMoonArchiver wraps the
logger functionality and performs the archiving whenever necessary.

> This method arises a problem when I want to use few policies on the
> same logger... converting it into a compositor that holds the
> logger looks wierd a bit clumsy. And I always prefer writing an
> "idiot proof" code this method has too many pitfalls.

I think you'll find that building composites like this will be at
least as intuitive as passing policies into a logger class. Each
class will have a single responsibility, easy to understand and test
in isolation.

By the way, this is exactly the type of "small" problem that can
result in a tangle, untestable implementation unless you build it test
first. Writing the tests will also allow you to try different
interfaces and let the code lead you to the way it wants to be
written.

>> There's probably an elegant way to do this with templates, but
>> I've been rotting my brain with Java all day and need to go kick a
>> puppy.
>
> Whenever I give my boss a solution with templates he runs amok...
> C with classes Is the sh** YHE!!!!!!!!

That's a reason to come up with a template solution right there.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Patrick May wrote:
> ManicQin <ManicQin@gmail.com> writes:
> > My main problem is that passing a pointer to the log class to the
> > policies looks like a hack.. you know what I mean? But the more I
> > think about it the more it looks like the problem only resideds in
> > my brain .
>
> I agree that it's a hack. Archiving is an additional capability
> to be added to the basic logging functionality. The logger itself
> should just do logging.
>
> >> class Logger
> >> {
> >> private:
> >> long bytesWritten_;
> >>
> >> public:
> >> Logger() : bytesWritten_(0) { }
> >> virtual ~Logger() { }
> >>
> >> virtual long bytesWritten() const { return bytesWritten; }
> >>
> >> virtual void log(string message)
> >> {
> >> // logging behavior
> >> }
> >>
> >> }
> >>
> >> class ArchivedLogger : public Logger
> >> {
> >> private:
> >> Logger* logger_;
> >>
> >> public:
> >> ArchivedLogger(const Logger* logger) : logger_(logger) { }
> >> virtual ~ArchiveStrategy() { }
> >>
> >> virtual bool log(string message) = 0;
> >>
> >> }
> >
> > I missed something in your code,
> > *) the log pure vrtual function is at the deriver?!?
> > *) than who calls the archive function?
>
> The client creates the logger they want with something like:
>
> logger = new PhaseOfMoonArchiver(new ConcreteLogger());
>
> then uses it like any other logger. The PhaseOfMoonArchiver wraps the
> logger functionality and performs the archiving whenever necessary.
>
> > This method arises a problem when I want to use few policies on the
> > same logger... converting it into a compositor that holds the
> > logger looks wierd a bit clumsy. And I always prefer writing an
> > "idiot proof" code this method has too many pitfalls.
>
> I think you'll find that building composites like this will be at
> least as intuitive as passing policies into a logger class. Each
> class will have a single responsibility, easy to understand and test
> in isolation.
>
> By the way, this is exactly the type of "small" problem that can
> result in a tangle, untestable implementation unless you build it test
> first. Writing the tests will also allow you to try different
> interfaces and let the code lead you to the way it wants to be
> written.
>

At first I continued with my despicable way... until I hit a wall and
realised the benefits of your method.... Thanks

ManicQin <ManicQin@gmail.com> writes:
> At first I continued with my despicable way... until I hit a wall
> and realised the benefits of your method.... Thanks

*laugh* Dude, it's all just code. Nothing despicable -- just
engineering tradeoffs.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)