Re: [boost] Re: iterator ranges; eliminating private member functions

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-11-02 17:13:20

From: Kevin S. Van Horn <kevin.vanhorn_at_[hidden]>
> ...
> This isn't a "perversion", it's just logically extending the concept to its
> broadest possible application.  I'm not just hiding implementation details
> from users of a class; I'm also hiding implementation details from all
> functions in the class interface that don't need those details.
> 
> Let me give you an example of the need for this.  One library I'm familiar
> with has classes with over 100 member functions, because the designers wanted
> to provide a rich interface and were also steeped in the OO cultural bias
> towards member functions.  I don't know how anyone can say that a class can be
> consider well-encapsulated when there are 100+ functions that have access to
> its innards; any modification of the class implementation requires examining
> every single one of those 100+ functions!  One might say that, while these
> classes are properly modest outside of a certain social circle, they are
> quite promiscuous, displaying their private parts freely, within that rather
> broad social circle.

I hate wading into a religious war, so I'll just say I take a dim view of
almost all general arguments about the "correct" way to use C++ language
features in a design.  Without studying the library you mention, and
understanding the goals of its designers, I cannot judge whether the use of
100 member functions was appropriate, let alone an expression "OO cultural
bias".  And I'm not swayed by analogies to human behavior, since cultures
and individuals vary widely as to the relative appropriateness of modesty
and promiscuity.

But I would like to hear more about the design of iterator ranges ...