> In the preface to one of Kent Beck's books he writes about a
> conversation that he had with a participant of one of his
> seminars on OO design and programming.  Paraphrased and
> abbreviated it boiled down to the statement by the participant
> that "... objects are just a fancy name for a procedure call ...".
> Kent, who is a recognized authority in the smalltalk world,
> then goes on to write that he had to think about that
> statement for a time but eventually came to the conclusion
> that OO programming and design was different.

He was correct; OO design is much more than procedure calls.

> I won't go so far as to relegate the trendy concept of OO to the
> dustbin, but there is a lot of history that is conveniently
> glossed over by the proponents of OO everything. There is
> absolutely nothing new about OO, save the terminology.
> Specialization has been an essential part of all large projects
> from the beginning of time.

The last statement is certainly accurate, but what does it have to do with
OO? The validity of the one before that ("absolutely nothing new...") is
questionable: there was "absolutely nothing new" about the device that flew
at Kitty Hawk either, except that no one had ever put all the parts together
into a working entity before. Are we then to dismiss air travel as a "trendy
concept" with little intrinsic significance?

> To build a skyscraper one does not start by laying bricks and
> figuring out where to go on a day by day basis.  What one
> does have is a construction plan, a structural plan, an
> architectural plan, a wiring plan, an HVAC plan, a lighting
> plan, etc.  Are these not conceptual objects?

Nope. A plan/design/architecture is not an object in any OO sense of the
word. It will probably include objects, specifying their locations,
attributes, and behaviors, but a plan is no more an object than a blueprint
is an office building.

> Is not one
> mostly independent of the other, save where they must inter-
> connect? Does the HVAC plan need to know of the wiring on
> the 70th floor, or just about the wiring that runs the plants?
> Does lighting have to know about the unions in the steel
> structure, or just where in the structure the conduits must
> run?  Are these not interfaces by any other name?

Not so far. An interface describes the mutually-agreed contract between
classes regarding what information and operations they make available to
each other. The fact that two entities operate separately from each other
does not create an interface. Quite the opposite, in fact: an interface (in
the programming sense) appears whenever objects are *not* independent, but
must interact with each other; the interface is the description of that
interaction.

> The OO concept of binary re-use and code sharing were all
> well established parts of the HP3000 world long before dll and
> com+ was even thought about.   I remember when the
> philosophy of HP programming, in any language, was the
> separation of data from code.  The one was private and could
> change and expand/contract dynamically; the other was static
> and could be shared simultaneously by many users on the
> same machine.

I've seen these concepts (binary reuse, code sharing, separation of code
from data) mentioned several times in this thread, almost all in a context
of either "OO claims to have invented this stuff" or "they are all that OO
really is". They are clearly not new with OO, and are hardly identical with
OO. The defining, mandatory elements of the object model are:
   Abstraction
   Encapsulation
   Modularity
   Hierarchy
Minor elements are typing, concurrency, and persistence. Most of these
existed before OO; some of them (hierarchical class structures linked by
inheritance, for example) were sufficiently difficult as to effectively be
unavailable.

> The OO idea of black-box development and implementation is
> nothing new either.  HP intrinsics and the SL are perfect
> examples of black-box programming.  Who needs to know
> HOW a 'dbput' or an 'fopen' works, so long as each new
> implementation always takes the same arguments,
> accomplishes the same task, and returns the same values.

Again true but unclear as to relevance. Encapsulation is an attribute of OO
programming, but I'm not aware of anyone claiming that it did not exist
before OO came along.

> Yet I have noted that, despite their relevance, discussion of
> Re-locatable Binary OBJECTS (note the name) in prior
> programming art is conspicuous by its absence in any writing
> about OO that I have read, and I have read a lot.

More exposition on this topic would make it more clear. What are these
"relocatable binary objects", and why do you expect them to be mentioned in
OO discussions? (the answer to the first may make the answer to the second
obvious) A block of relocatable object code is not likely to be an object,
though it may well be part of an implementation of one.

> COBOL stays around not because of the inherent worthiness
> of COBOL.  COBOL remains because of the quality of the
> designs that are implemented in COBOL.  Designs that have
> stood the test of twenty years of use and refinement while the
> world of computing has changed beyond all recognition.

I think there's a typo in the second sentence; COBOL clearly owes much of
its longevity to the *quantity* of implementations, but I doubt that you're
claiming that COBOL is somehow responsible for quality design. Good design
can be done in any language; so can terrible design.

> .... writes of the
> necessity to keep programs and procedures small and
> disposable. By doing so the design/programming team never
> has such an investment in a piece of work that they would
> rather salvage what they have than scrap it all and start anew.
>
> Is this not in essence OO design, put much more simply and
> in a form that nearly anyone can understand?

As previously noted, no. Modularity and encapsulation are elements of the
object model, but they are not the whole story.

> Here we have in
> concrete terms the exact purpose of OO design.  To break
> things down into the bits that do one thing well, and that can
> be freely discarded, replaced, and reworked; without impacting
> any other portion of a system.
>
> The only thing that has to be rigorously controlled for this to
> work are the interfaces between the bits, the calls and returns,
> and the results accomplished by each bit. Well guess what
> OO Design/Programming is mainly about? Interfaces, and the
> need to keep them inviolate.

It's a little confusing when you state that the purpose of OO is "To break
things down into the bits that do one thing well" (i.e. encapsulation) and
then, two sentences later, claim that OO is mainly about interfaces. Which
is it?

> OO design is mostly about
> systematically identifying and describing those interfaces.

Another gross oversimplification. OO design is about identifying the
abstractions of the problem, identifying the classes and objects at a given
level of abstraction, identifying the behaviors and semantics of the classes
and objects, determining the relationships between those classes and
objects, identifying the boundaries between classes, *and* specifying the
interaction attributes and methods (i.e. interfaces) at those boundaries.

> What goes on inside an object, just as for a COBOL
> procedure or an SL intrinsic, is of no concern to the calling
> process. This is hardly a revolution in thought or practice for
> the profession of Computer Science.

Again the implications that 1) OO proponents claim that encapsulation didn't
exist before OO came along, and 2) OO *is* encapsulation. Both are
incorrect.

Is everything embodied in OO brand new? Of course not. Is OO the One True
Way? Of course not. Is OO an invaluable technique for analyzing, and
producing quality, maintainable solutions to, a broad spectrum of problems?
An ever-increasing number of professionals all over the world seem to think
that it is.