David Rubin wrote:
"Ali R." wrote:
"David Rubin" <bo***********@nomail.com> wrote in message
news:3F***************@nomail.com...
Is there ever a good reason to declare private non-virtual member
functions in a class definition?
[snip - top-posting fixed]
lets say that you have methods A and B which do something that are kinda
similar, methods could be virtual or may not besides the point. so you as a
good programmer will isolate the similarities and put in method C.
What I was really after was whether to declare a non-virtual private
method in the class interface or to declare a static function in the
implementation translation unit. I guess the major difference is that a
member function knows about the calling instance, and has access to
other private data. So, it depends on what the function does.
I don't like adding private member functions to a class. In
my experience private methods are usually either internal
implementation details, helper methods for the class, or
encapsulate some common code and I don't think this sort of
stuff belongs in the class header.
Personally I'd consider creating an auxillary class for
those private methods. It keeps the implementation details
out of the primary classes interface, so you can fiddle
about with it without causing client code to recompile, and
frequently the 'private methods' are actually useful outside
of the class anyway. In a large system you can often find
that a method you are about to write is already lurking
around as some private method in some obscure class.
In some cases though a private method makes sense, for
example if the method is making non-trivial usage of the
classes internal data, but I'd consider the auxillary class
first.
