Re: Ada OOP question

[Jeff Carter <jrcarter@acm.org>]

mark_lundquist@my-deja.com wrote:
> > I think that this practice should be discouraged. The problem is that
> > such a type creates an interface that is difficult to understand. What
> > is the difference between
> >
> > Op (Object, Param1, Param2);
> >
> > and
> >
> > Object.Public_Component := Some_Value;
> > Op (Object, Param1, Param2);
> >
> > ? They could be the same; Op could perform differently in the 2nd
> case,
> > but this be considered valid; or Op could be invalid as a result of
> the
> > assignment.
> 
> Sure... but this observation is just as valid if you replace the
> assignment to the public component with any operation.  Since
> encapsulation isn't relevant to your observation, the observation isn't
> a sound argument for encapsulation in general nor against mixing public
> and private components in particular.  (Don't get me wrong, I'm all for
> encapsulation, this just isn't the argument for it! :-)  Your argument
> below, viz. coupling to the implementation, is much more to the point...

I disagree. If I write the package with no public components, I can
easily detect invalid sequences of operations. I can often prevent
invalid sequences of operations. This is less easy when one of the
operations is direct assignment to components of the type.

> True enough, it's the "header file" heritage.  In C you often find a
> function's documentation comments in the .c file, while the .h file
> (ostensibly the "interface") is just "extern blah blah(blah, blah);" on
> everything, with no comments.

Too frequently there are no comments anywhere. The code is "self
documenting".

> I wonder if the reason people sometimes use public components instead
> of accessors/mutators (or getters/setters or whatever you want to call
> them) because they are trying to "optimize performance".  Certainly in
> C++ it's well known that member functions defined in the class
> definition are inlined, but maybe people don't know that you can inline
> subprograms in Ada (Rational's compiler does auto-inlining when
> optimization is turned on, and its algorithm is quite difficult for a
> human programmer to beat in terms of final executable speed and size).
> Don't know about inlining in Java...

"Performance" is often used as an excuse for bad design. "We have this
variable in the package spec for performance reasons."

"Really? Where are the performance requirements documented? Where are
the results of timing tests without the global variable documented?"

"Well, there aren't any. I just know it will be too slow otherwise."

Such claims are rarely true.

-- 
Jeff Carter
"I waggle my private parts at your aunties."
Monty Python & the Holy Grail