shaun roe wrote:
Hello,
I am working in a framework with certain restrictions; in particular I
have a 'data' class with getter and setter methods, and a some 'filling'
classes which know how to insert the data to the data class (they match
various sources such as a text file or a database, and then fill the
data).
The filling methods use the 'setter' methods of the data class, but then
I want to present the data class to the outside world (i.e. other
classes in the program) such that the setter methods cannot be used by
anyone else.
The sledgehammer approach would be to declare the 'setter' methods
private or protected and declare each of the fillers as a friend.
However, I am free to introduce some inheritance structures... if I make
a base class for the fillers and declare *it* to be a friend, will the
derived classes also be friends?
Is this reasonable?
You can't "inherit" friends. Friends are friends of what they were
declared to be friends of, and nothing more.
However, if you declare your "setter" methods to be protected and
virtual, then it doesn't really matter that you can't inherit friends.
The friend "filler" doesn't need to know that it's actually operating
on a descendant of the class it thinks it's working with: it's working
with it's friend, and the fact that it's really a virtual method
defined by a descendant doesn't enter into play.
If you don't plan on overriding the method, you don't even need to
declare it virtual. It will be the base class's method that gets
called, as long is it doesn't get hidden by another member function
with the same name.
A design that involves having to add a new "friends" declaration
somewhere each time you want to extend functionality with a new type of
setter is almost certainly the wrong way to go about it. Better might
be to declare one "filler" class to be a friend, make the appropriate
methods protected, and derive from that class. Again, it doesn't matter
that the derivatives aren't friends, so long as you're only ever using
the base class's member function anyway.
As to whether this is reasonable, I couldn't begin to comment on that
without knowing what your particular problem or situation is. What I
will tell you is, code for the future. Leave as much flexibility for
change open to yourself, while at the same time guarding as much as
possible/practical against poor usage.
