# richard@dynamisys.co.uk / 2006-09-16 16:50:36 +0100:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Roman Neuhauser # dgsteffen@numerica.us / 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