blueblueblue2005 wrote:
here is a friend function of Class Array, which has two private data
member: int size, int *ptr
// Array's public member function to return size
int getSize() const { return size; }
friend istream &operator>>(istream &in, Array &a)
{
for(int i=0; i<a.size; i++)
// do something
return in;
}
here is my question: a is an object of Array, but in the for loop
condition, a access its private member size directly, instead of
calling getSzie(), like a.getSize(), does this violate the data
encapsulation principle? does anyone else(except me) think c++ is
stupid in some ways?
In order to demonstrate a design flaw in C++ (or in any other
programming language), one needs an example of how this flaw affects
(or prevents the implementation of) a sound programming design. In this
case, the argument would be that C++'s support for friend declarations
makes it impossible to implement the solid design of class Array.
But is the Array class well designed? The first question that anyone
would ask, is why Array makes operator>> a friend, if operator>> can be
implemented using only those methods of A that are public? Why grant
operator>> access to A's private data members when no such access is
needed? Applying the principal of encapsulated design, it is clear that
Array should not grant such access to operator>>. So the case being
made: that C++'s support for friend declarations is "stupid", fails
because the Array class used as an example has a design flaw that no
one should want to implement - in C++ or in any other programming
language.
It is also possible to work from the other direction. Let's assume that
there is no support for friend declarations in C++. Access to classes'
private methods and data members would only be allowed within the
implementation of the class itself.
Now would it be possible to create a solid design for a program where
external access to a class's private data would be needed? The answer
would be "yes" and such cases can be found in the standard library
itself. There are many instances, particular in I/O operations, where
external access to a class's internal buffers is part of a solid
design.
Without C++'s support for friend declarations, those buffers would have
to be declared public - but to do so would violate encapsulation.
Keeping them private would prevent the implementation of a well
designed set of I/O operators. The solution? Of course it's the friend
declaration.
Far from being a defect of the language, C++'s friend declarations
allow programmers to implement solid designs that could not be
implemented without selective access to private data, or that could be
implemented only in ways that would violate the principles of
encapsulation.
Greg