Here is a neat little way I found to make one class access the privates of another class, without using friend or direct inheritance. Take a look at this code:
class A {
public:
class Observer {
protected:
int GetPrivate(A & a) {return a.ValueA;};
};
private:
int ValueA;
};
class B: public A::Observer {
public:
void Foo (A & a) {
cout<<GetPrivate(A);
}
};
Class B cannot access the privates of class A directly, but it inherits a subclass of A that can access the privates of A given as a parameter. Since I have just tried this “pattern” recently, I am not sure what is the direct benefit of this.
I believe a benefit can be in the sense of making a programmer’s life easier. Programming languages play several parts. They provide us powerful functionality, but they also suppose to give us ease of use. You can program anything on assembly, but it would be really difficult to write a big game in assembly.
If you do not expose privates via a getter, you give the programmer one less method to think about when he need to use the class’s instance for something.
Can you think how you would use this “pattern”? Do you think there is no use for it?
Tell me what you think.
Pro:
- friend declaration makes all members available to friend class, your pattern allows to publish only a part of the member data
- member access declaration via friend is done in class owning the members (changes are intrusive), your pattern allows client class to choose access itself
Contra:
- less readable
- may not work (that way) with some compilers (VS6?, I’m not sure here)
Finally I can’t remember any situation in which I had a need for such a specific member publication. IMHO friend declarations should be made where the affected members are declared. This guarantees that the access policy is declared at one position (central access control). Friend declarations should be used with care, not at all if possible.
I will keep this pattern in mind. Maybe there are some situations where it is useful. ‘If you only have a hammer every problem looks like a nail’.
Hi hermitC,
I have been thinking about this for a bit. And I come to think of a good example to explain this.
What is “needed”? Do you need ‘private:’?
You know it is possible to write a complete program without using ‘private’ at all! You can make everything public. private only shout a compilation error when you try to access it outside of the class.
‘private’ is useful, eventhough it doesn’t change the game’s logic.
@ofer: You are right, private is just an artificial ’stop sign’ in the code.
An even better way to think of it is as a traffic light: public=green, protected=orange, private=red. It makes the compiler tell you (or other programmers using your code) what is accessible and what not.
When you are driving on a lonely road (small one-man project) there is no need for traffic lights. But chaos will rise when you enter a big city without any traffic controls.
The friend declaration is a kind of backstage pass, handed out only by the concert management. It’s an exception, a privilege for a few. The pattern discussed here is a backstage pass for everyone but reduced to small areas of the backstage. The only hurdle to overcome is the extra code to derive from the Observer class for each wanted member.
Conclusion: The pattern could be useful for libraries I write and hand out to other programmers. For my one-man project it’s just an overkill.
hermitC, I don’t think the traffic light is a good example. Because private are useful for the lone programmer as well.
This pattern can be useful for a lone programer as well, of course it doesn’t mean you have to use it. It depend on a lot of things. For instance, I wouldn’t give the same attention to different parts of code. Some times I prefer the “quick and dirty” solutions, sometimes I prefer the “overkill”.
@ofer: Good point, didn’t consider that traffic lights are useless when cruising alone
Hmmm… “Cruising alone” doesn’t look like a good reason to break encapsulation, really. IMHO: if you ever find yourself needing to break encapsulation, this is an indicator of a design that could be improved.
Other than that – interesting approach.
Hello Marcin,
I understand what you are saying, but I think sometimes you want classes to be closely dependent of each other.
The best way to decouple classes is data driven, but sometimes it’s not worth or doesn’t make sense to use that.