How to hide helper classes in *.h files?

[mailforpr]

Suppose you have a couple of helper classes that are used by 2 client
classes only. How can I hide these helper classes from other
programmers? Do you think this solution is a good idea?:

class Hidden_functionality
{
protected:
// These helper classes provide some functionality that is
// only used by the client classes
class Helper1 {};
class Helper2 {};
class Helper3 {};


Hidden_functionality() {}
Hidden_functionality(const Hidden_functionality&) {}
~Hidden_functionality() {}
};

class Client1: private Hidden_functionality
{
/* make use of helper classes */
};

class Client2: private Hidden_functionality
{
/* make use of helper classes */
};


Now other programmers who include the *.h file won't be able to use the
helper classes that are meant to be internally used by the client
classes.

Is there a better solution to this?

 

[peter koch]

(e-mail address removed) skrev:

Suppose you have a couple of helper classes that are used by 2 client
classes only. How can I hide these helper classes from other
programmers? Do you think this solution is a good idea?:

First, I do not understand why you want to hide anything.

class Hidden_functionality
{
protected:

If I wanted it to be useful only for Class1 and Class2, I'd make Class1
and Class2 friends and let everything in Hidden_functionality be
private.

// These helper classes provide some functionality that is
// only used by the client classes
class Helper1 {};
class Helper2 {};
class Helper3 {};


Hidden_functionality() {}
Hidden_functionality(const Hidden_functionality&) {}
~Hidden_functionality() {}
};

What is strange to me is that Hidden_functionality is all classes.
There is no data here. If Hidden_functionality only has (static)
member-functions, I'd just use free functions, declaring them in the
..cpp file only.

class Client1: private Hidden_functionality

As Hidden_functionality is currently declared, there is absolutely no
reason to inherit Client1 or Client2 from Hidden_functionality. And
even if Hidden_functionality had data members, I still see no reason
for inheritance unless there is a using directive somewhere, and even
then it would normally be smarter to forward.

{
/* make use of helper classes */
};

class Client2: private Hidden_functionality
{
/* make use of helper classes */
};


Now other programmers who include the *.h file won't be able to use the
helper classes that are meant to be internally used by the client
classes.

They actually could, by creating a new class inheriting from
Hidden_functionality.

Is there a better solution to this?

Yes. But for now, I'm not sure what (and why!) you are trying to
accomplish.

 

[Dheeraj]

You have to use the concept of friend class in C++.

Make every thing public in helper classes and then define those two
classes as friends of helper classes.

Dheeraj

 

[Dheeraj]

Sorry, I mean make every thing private in helper classes.

Dheeraj

 

[Ondra Holub]

(e-mail address removed) napsal:

Suppose you have a couple of helper classes that are used by 2 client
classes only. How can I hide these helper classes from other
programmers? Do you think this solution is a good idea?:

class Hidden_functionality
{
protected:
// These helper classes provide some functionality that is
// only used by the client classes
class Helper1 {};
class Helper2 {};
class Helper3 {};


Hidden_functionality() {}
Hidden_functionality(const Hidden_functionality&) {}
~Hidden_functionality() {}
};

class Client1: private Hidden_functionality
{
/* make use of helper classes */
};

class Client2: private Hidden_functionality
{
/* make use of helper classes */
};


Now other programmers who include the *.h file won't be able to use the
helper classes that are meant to be internally used by the client
classes.

Is there a better solution to this?

In principle you can write every class this way:
class PublicClass
{
public:
// Some public stuff would be here

private:
class Internal;

Internal* internal_;
};

class Internal may be defined in cpp (cc) file so user cannot do with
it anything. In some cases pointer to instance of Internal may be
replced with reference, but the princip remains same.

 

[mailforpr]

@dheeraj

In my case, if used the friend keyword in each helper class, there
would be just too many of them.

@Ondra Holub

In principle you can write every class this way:
class PublicClass
{
public:
// Some public stuff would be here

private:
class Internal;

Internal* internal_;
};

class Internal may be defined in cpp (cc) file so user cannot do with
it anything. In some cases pointer to instance of Internal may be
replced with reference, but the princip remains same.

That's a good idea. But what if there are other public classes (my
client classes) that need to access the functionality of class
Internal? That's why I came up with a general base class holding the
functionality (the helper classes).

I could make a combination of the friend feature and Ondra Holub's
PublicClass:

class Hidden_functionality // Holub's PublicClass
{
private: // changed to private
// These helper classes provide some functionality that is
// only used by the client classes
class Helper1;// {}; implemented in some cpp file
class Helper2;// {};
class Helper3;// {};

Hidden_functionality() {}
Hidden_functionality(const Hidden_functionality&) {}
~Hidden_functionality() {}

friend class Client1;
friend class Client2;
};

class Client1 /*: private Hidden_functionality */
{
/* make use of helper classes */

};

class Client2 /*: private Hidden_functionality */
{
/* make use of helper classes */

};

(e-mail address removed) skrev:

They actually could, by creating a new class inheriting from
Hidden_functionality.

Not anymore
No one can access the helper classes but Client1 and Client2.
By the way, peter koch, the "helper" classes are actually the real
implementations of the client classes. It's a handle/body pattern.

 

[Default User]

@Dheeraj

In my case, if used the friend keyword in each helper class, there
would be just too many of them.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.com/c++-faq-lite/how-to-post.html>