[fpc-devel] "Friend" classes?
Michael Van Canneyt
michael.vancanneyt at wisa.be
Fri Mar 18 10:30:20 CET 2005
On Wed, 16 Mar 2005, DrDiettrich wrote:
> Michael Van Canneyt wrote:
>
>>> type TFriendClass = class(TNotMyClass);
>>
>> This is a simple descendent.
>
> Yes and no. The only purpose of this declaration is to get access to the
> protected members of the class, not to extend the class in any way.
Yes. This is OK, no ?
>
>>> 3) What alternatives could be used, so that not all class members must
>>> be made public, when they shall be used only in specific related units?
>>
>> ? Please explain.
>
> "protected" members of a class are for internal use only, not for public
> use. IMO it's against the spirit of visibility levels, when the
> protected and even private members of a class become accessible from
> outside the class, throughout the whole unit in which a class is
> defined. But sometimes multiple classes are designed for cooperation,
> where one class needs access to not normally accessible methods or
> properties of another class. When now the required methods are made
> public, they become available for abuse by everybody. With the above
> trick instead it's possible to gain access to the internals of a class,
> without making everything public.
> Such a backdoor does not prevent
> abuse, but as the (C++) term "friend" class suggests, it exists only for
> the sake of cooperation, and at the responsibility of the implementor.
>
> That's why I would like to know how such cooperative functionality can
> be implemented, by perhaps less tricky means.
sorry, but I fail to see the problem ? The above makes all protected
members of a class visible. This is normal, that is why they are
protected. If you want to avoid that, make the members private. Then
they are visible only in the same unit, even for other classes (for
'cooperation'), but not outside the unit, even with a descendent.
Michael.
More information about the fpc-devel
mailing list