Re: OO and modules ( was Which book for ADA beginner ?)

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Hans-Olof Danielsson wrote:
> 
> Andrzej Lewandowski wrote:
> 
> >......
> > object orientation and modules are in principle orthoogonal concepts, and
> > that BOTH and SEPARATE are required to build well structured OO programs.
> 
> That�s interesting. Does that mean that adding, modifying or deleting an
> OO-object from a software system doesn�t effect the architecture of it as
> the architecture deals with components ( modules ) and their relationship?

I do not see how you can draw your conclusion from the above statement.
Encapsulation includes the definition of classes, but also includes the
definition of what some languages call "name space". This is the ability
to differentiate between two classes with the same name in the same 
program.

> 
> > C++, Eiffel, Smalltalk ond others are using classes for both purposes: OO
> and
> > encapsulation (say, modularization).

C++ has added a new feature called name spaces to allow the 
use and identification of multiple classes with the same name in a
single program. This feature was added because the original concept
of all encapsulation occurring only in the class was found to be
too limiting, particularly when trying to use pre-defined libraries.

> 
> > Ada95 and Oberon are two (well, maybe not
> > the ONLY two...) languages that separate these two notions.
> >......
> 
> and are therefore more expressive at the architectual level compared to the
> first group languages?

Actually, yes.

The ability to define groupings of class definitions does allow
greater expressive freedom than languages lacking such ability.

> And to which group does Java with its interface and package constructs
> belong, the first or the second and why?
> 

Java tries very hard to be like Eiffel and Smalltalk. However, Java
added its own versions of name spaces in JDK 1.1. Packages were added,
as well as top level nested classes. Both features exist solely to
provide the expressiveness of name spaces. 

I would assert that the developers of Java became aware of the need
for name spaces. They added two competing mechanisms to allow
the developer to implement name spaces. In the case of packages,
they also redefined the meaning of their access modifiers to allow
visibility which, IMHO weakens their encapsulation model.

Java interfaces are not related to inheritance. They are related to
polymorphism, which should never be confused with inheritance.
Polymorphism in Java is extended by interface implementation because
every class that implements an interface can be relied upon to
implement a method with the specific signature published in the
interface definition.  Syntactically, an interface definition is
just that, a definition of method signatures, with the occasional
addition of some constants.

Do not confuse Java interfaces with abstract classes. Java also
has abstract classes. Abstract classes become the basis for an
inheritance hierarchy, just as in Ada. Interfaces are never the
basis for an inheritance hierarchy. Java syntax makes this 
distinction very clear. Inheritance is achieved using the
"extends" keyword. Interfaces are implemented using the
"implements" keyword.

Jim Rogers
Colorado Springs, Colorado USA