Boost logo

Boost Users :

From: Roman Neuhauser (neuhauser_at_[hidden])
Date: 2006-09-16 14:16:55


# richard_at_[hidden] / 2006-09-16 16:50:36 +0100:
> -----Original Message-----
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Roman Neuhauser
> # dgsteffen_at_[hidden] / 2006-09-15 10:49:46 -0600:
> > Sohail Somani writes:
> > > #define private public
> > > #define protected public
> > > # include "MyClass.hpp"
> > > #undef private
> > > #undef protected
> > >
> > > This is permissable in unit tests, I would think.
> >
> > Yes, this is one of the alternate approaches I've been considering.
> > We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is
> > out there somewhere... :-)
>
> Extract bodies of those private methods to functors. Call those
> functors in/instead of your private methods, passing as arguments
> private data members that were accessed directly in the old methods.
>
> Isn't this just a more extreme version of extracting the private
> methods to another class where they would be public?

    Dunno, I don't think those things are comparable. One is a matter
    of improving the design (with better testability as a side effect).
    The other doesn't influence the design at all.

    What's so dangerous about algorithms that reside in large private
    methods? Do those algorithms themselves need to be hidden, or is it
    access to particular data that needs to be tightly controlled?

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net