By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,508 Members | 1,207 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,508 IT Pros & Developers. It's quick & easy.

Selectively Public Function

P: n/a
I have a high level class X.
I have a lower level utility class Y.

I want only class X to have access to method y in class Y. i.e. I want
class Z to have access to most methods in Y but not method y.

Without making y private and making class X a friend of Y, is there a
pattern to achieve desired results?

Technically, class Y should have no idea of class X so declaring class
X as a friend breaks the hierarchy.

Thanks,
-zip

Sep 27 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
zippy747 wrote:
I have a high level class X.
I have a lower level utility class Y.

I want only class X to have access to method y in class Y. i.e. I want
class Z to have access to most methods in Y but not method y.

Without making y private and making class X a friend of Y, is there a
pattern to achieve desired results?

Technically, class Y should have no idea of class X so declaring class
X as a friend breaks the hierarchy.


Something like this?

class Y {
friend class yBuddy; // whatever that is
void y();
public:
void yy();
void yyy();
};

class yBuddy { // ah, that's what it is...
static void y(Y& a_y) { a_y.y(); }
friend class X; // aha!
};

class X {
void bar(Y& a_y) {
a_y.yy();
a_y.y(); // error
yBuddy::y(a_y); // a "work-around"
}
};

class Z {
void bar(Y& a_y) {
a_y.yy();
a_y.y(); // error
yBuddy::y(a_y); // error
}
};

V
Sep 27 '05 #2

P: n/a
zippy747 wrote:
I have a high level class X.
I have a lower level utility class Y.

I want only class X to have access to method y in class Y. i.e. I want
class Z to have access to most methods in Y but not method y.

Without making y private and making class X a friend of Y, is there a
pattern to achieve desired results?
You want Y.y() to be inaccessible by client code. Making the method y()
private is the way to go. That *is* what private means.

Technically, class Y should have no idea of class X so declaring class
X as a friend breaks the hierarchy.


Technically, you want to make an exception for client class X. Since class Y
is where access rights are specified, Y *should* be told that class X is
different from all other clients. And that is what friend declarations do.
Now, why is there a problem? You have a clean way of achieving exactly the
effect you desire through standard means of the language that anybody
mainting the code in the future will understand. Yet you are searching for
a roundabout way of doing the very same thing. It appears to me that your
problem is purely philosophical and not technical.
Best

Kai-Uwe Bux
Sep 27 '05 #3

P: n/a
Are we still pals?

-zip

Sep 28 '05 #4

P: n/a
zippy747 wrote:
Are we still pals?


Sorry, I didn't mean to be rude. To make up for it, let me elaborate a
little bit on the suggestion of Victor Bazarov. To me it seems that the
idiom he suggested solves a slightly different problem: how do I make some
private members but not all of them available to a class. Consider:
class Y {

friend class yBuddy; // whatever that is
void y();

friend class yyBuddy; // whatever that is
void yy();

public:

void yyy();

};

class yBuddy { // ah, that's what it is...
static void y(Y& a_y) { a_y.y(); }
friend class X; // aha!
};

class yyBuddy { // ah, that's what it is...
static void yy(Y& a_y) { a_y.yy(); }
friend class Z; // aha!
};

class X {
void bar(Y& a_y) {
a_y.yyy();
yBuddy::y(a_y); // work-around
yyBuddy::yy(a_y); // error
}
};

class Z {
void bar(Y& a_y) {
a_y.yyy();
yBuddy::y(a_y); // error
yyBuddy::yy(a_y); // work-around
}
};
Now, X can call y() and Z can call yy() but X cannot call yy() and Z cannot
call y(). In case that is what you need, by all means go for it. However,
note that it becomes a little more tricky to maintain this code since now
you cannot tell which classes have access to the internals of Y just by
looking at the code of Y. The definitions of access rights gets somewhat
spread out.
Best

Kai-Uwe Bux
Sep 28 '05 #5

P: n/a
You weren't rude. I appreciate your responses.

In order to maintain hierarchy, I made another class at the Y hierarchy
level -- class Y'. Y' is a friend to class Y and can access its
private members.

Class X inherits from Class Y' and thus can use base class Y' to access
class Y private members. I maintain hierarchy and limit access to
class Y private members to classes that inherit from Y'.

-zip

Sep 29 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.