An applications design should not be too exotic, but if there's a greater good in using another design approach, I would document carefully and go for it.
The C++ friend feature definitely has its uses. Best Regards, Jim Smith --- On Mon, 5/25/09, Thomas Hruska <[email protected]> wrote: From: Thomas Hruska <[email protected]> Subject: Re: [c-prog] Re: c++ protected members To: [email protected] Date: Monday, May 25, 2009, 9:13 PM Jim Smith wrote: > You could also just make one member function a friend, but including the > friend feature is not a good idea. Using 'friend' can significantly decrease development time - but only if it is used properly. That is true for any language construct (e.g. 'goto'). Example of what I consider appropriate 'friend' usage: class A { public: class B; friend class B; private: ... }; class A::B { private: ... }; Where B needs to access the protected/private data of A. Here it makes sense as B is clearly a logical sub-category of A to support A. Could you put all of B into A? Probably. But it would also "pollute" the purity of A. I'm sure there is also some pure OO method as well that doesn't use 'friend', but if something gets the job done AND results in easily maintained code (and possibly fewer lines of it) that the entire team understands but just happens to be non-OO, which is better? -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleS oft.com/MyTaskFo cus/ [Non-text portions of this message have been removed]
