From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,9982360189bfe852 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-29 07:58:17 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!sn-xit-01!supernews.com!newsfeed.stanford.edu!xfer10.netnews.com!netnews.com!wn1feed!worldnet.att.net!135.173.83.72!wnfilter2!worldnet-localpost!bgtnsc07-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3A759385.6BDA29D8@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: OO and modules ( was Which book for ADA beginner ?) References: <3A71400E.32057C6B@becker.k.pl> <3a72224b_2@news3.prserv.net> <3a74c829_2@news3.prserv.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 29 Jan 2001 15:58:17 GMT NNTP-Posting-Host: 12.74.129.166 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc07-news.ops.worldnet.att.net 980783897 12.74.129.166 (Mon, 29 Jan 2001 15:58:17 GMT) NNTP-Posting-Date: Mon, 29 Jan 2001 15:58:17 GMT Organization: AT&T Worldnet Xref: supernews.google.com comp.lang.ada:4656 Date: 2001-01-29T15:58:17+00:00 List-Id: 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