Creating Private methods

[RichardF]

Hi,

My lecturer just told me off for using private methods in my class (c++)

I always thought that if you just wanted a function inside your class that is only called internally from a public method (ie the client developer should not call it) then it can be private.

Anyones opinions ?

Rich.

"Programmers are tools for converting caffeine into code - BSRF"

 

[uolj]

That is very odd. Where does your lecturer expect you to put internal helper functions?

Does he or she want you to put all the code into the public method? That wouldn't be very smart, since you wouldn't be able to separate logically distinct sections of code into different functions. You would also not be able to reuse code that is required for multiple functions.

Does he or she want you to make all the helper methods public? That wouldn't be very smart, because the entire idea of having the private keyword is to use it to encapsulate the inner workings of the class. By making available helper functions that have nothing to do with the class interface, you obscure that interface to users of the class and you have no control of what operations they are allowed to use.

Does he or she want you to make all helper methods protected? I think it is generally considered bad design to make these methods protected unless they are specifically useful to a derived class. That is assuming this class is meant for use with inheritance.

Are you sure you understood what he or she meant? In my opinion, that idea in the way you presented it is very strange. Is it possible that the lecturer was making a greater point about something else and has no problems with private class methods?

 

[chipperMDW]

What were their reasons?

If that's the whole story, then sounds to me like this instructor is a C++ newbie him/herself, and just knows the part about how data is normally private and member functions are normally public.

There's no reason either of those general rules should be applied as an absolute. Obviously (to you and me) there are reasons to make a member function private. Your description is exactly correct; if no client code will ever call a certain member function, it had better be private. In that case, a programmer should be told off for not making that function private.

Ask your instructor if he/she knows what the "Principle of Least Access" is. Look it up yourself first, of course, so you can have a sarcastic reply prepared when he/she doesn't know. It basically says that any given person/program/object/piece of code/whatever should have access to what it needs and only that.

 

[RichardF]

Hi,

Thanks for your replies.

Actually it stemmed from my question - can you have private inheritance ?

(This is a console project so I have a Screen class which has methods such as drawbox, background, foreground colours etc. I wanted to use private inheritance into my Menu class because I wanted to restrict the developer from calling Menu.DrawBox which is clearly something a menu should not do.)

and he said why would you want to do that ?

and i said so you can inherit public methods privately.

and then he said why would I want private methods ? There is no text book that shows this ? This is not done by convention.

and so I said, surely you can have private methods that public methods could call. for example you want ValidatePassword private, in case someone derives and overrides the method.

anyway, I think his opinion was that all private methods should be protected, and (he later confirmed)that you could have private methods which are called by public methods if the public methods are inherited.

getting back to the original question, he said that cannot do private inheritance and instead you should aggregation instead.

now, i've found out that you can do private inheritance, but it would be more maintainable to use aggregation - which is what i did.

Regards,
Rich.



"Programmers are tools for converting caffeine into code - BSRF"

 

[globos]

Like you said, in C++, private, or protected inheritance are "implementation" inheritance. C++ public inheritance has the classical meaning of "is-a" relationship, also know as "interface" inheritance.
Conceptually I found private inheritance very useful. I use it as the "service" taxonomy inheritance. For example utility class such as basic math routines like abs, sin, cos, pow, etc. can be defined in a service class MathUtilities, for example :

class MathUtilities
{
public:
  MathUtilities () :
    Pi (3.14159...), //initialize constants
    ...
  {
  }

...

//constants
public:
  const double Pi;
  ...
//services
public:
  double cos (double x);
  double sin (double x);
  //etc.
};

When a class needs some math facilities in can inherits the MathUtilities class, which should be only used through private/protected inheritance, no aggregation, or whatalike :

class MyClass : private MathUtilities
{
...
public:
  void foo ()
  {
     float value = cos (Pi / 2.0);
     ...
  }
};

This way you applications can be fully object-oriented, no use to <float.h> or <math.h>, etc.
Also, private inheritance is not considered by C++ compilers as inheritance, it is translated as single relationship to MathUtilities in our example.
&quot;Service&quot; taxonomy inheritance is a valid inheritance, it is described and justified by B.Meyer in his famous book &quot;Object-Oriented Software Construction&quot;.

--
Globos

 

[chipperMDW]

> There is no text book that shows this ?

Yeah, that's true. Not many textbooks even acknowledge that this is possible; those that do just skim over it. That's not really a reason to claim it has no legitimate use, though.


However, on this point he's right: normally, you should prefer aggregation to private inheritance.

The exception is when you need to override a virtual function from the base/contained class. In that case, you'd have to go with private inheritance.

 

[stefanwagner]

RichardF:

One small detail: I don't think, that dealing with passwords is a good issue to describe the benefits of private methods, because it's mixing different aspects of security, - User aspects and programmer aspects.

SimpleConnect: submitPassword (String dummyUnused)
SolidConnect::SimpleConnect
    SolidConnect:submitPassword (String md5Password)
PGPConnect::SimpleConnect
    PGPConnect:submitPassword (String pgpPassword)

Describing those private methods as helperMethods is the right way.

private: crypt (String password);
// 
public: submitPassword (String crypted);

Every public method is part of the Interface, and might be used by clients of your class, so you have to support it foreever (once public, forever public).
You may make a method public later, if it is meaningful.