|you are breaking class level encapsulation (by using friend) in order to provide for library-level encapsulation (users of the library cannot instantiate an iterator)|
Sounds to me like you're splitting hairs. Though I guess it depends on how you define your terms.
One could argue that std::list<T>::iterator is part of the std::list<T> class (which it is, depending on how you define "part of") and therefore it does not violate class level encapsulation. It's just two different parts of the same class talking to each other.
I won't make that argument though, because I don't care enough about it.
From my viewpoint, encapsulation is about separating interface from implementation. STL container classes, with their use of friendship, do exactly that. Whether you define that separation on a class level or on a broader level is completely arbitrary and irrelevant.
The bottom line (again, from my viewpoint) is that:
- with friendship, std::list<T> and std::list<T>::iterator can be properly encapsulated from the user's standpoint
- without friendship, they can't be
Going from that, friendship does not hinder encapsulation in any sense of the word.
So if you want to draw the line and say that "encapsulation means it must be contained within a single class", then you're either left with compromising that with friendship, or violating it completely to expose internals to the end user.
But again drawing that line at a class boundary is arbitrary. It's just the most convenient place to draw the line in most
|which makes life harder for the maintainer, but easier for the user,|
That's kind of the point. In fact, you're more or less describing OOP as a whole with that statement.
Compare std::string (OOP) verses strcpy, etc functions (procedural).
- string is a lot harder to write and maintain
- string is a lot easier and safer to use
While maintaining string might be more difficult, maintaining programs that use string is easier.
When working on larger projects, maintaining individual classes might be more difficult, but maintaining the project as a whole is a lot easier.
|however, notice that FAQ actually advocates making each class a mutual friend of the other as the safest way to implement something?!?|
I'm less interested in defending the FAQ author than I am in defending the merits of friendship.
I don't really agree with his example, but I do agree with his overall message.