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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9eccdbc9cfa1c9b9 X-Google-Attributes: gid103376,public From: mmann@ibm.net (Gerd Moellmann) Subject: OO Idiom: Interfaces for derived classes Date: 1996/03/21 Message-ID: #1/1 X-Deja-AN: 143616757 distribution: world sender: mmann@ibm.net organization: None x-nntpdaemon: changi 0.9 for OS/2 newsgroups: comp.lang.ada Date: 1996-03-21T00:00:00+00:00 List-Id: Dear Ada users, I am currently investigating Ada for OO programming, and I would like to ask you for your comments wrt a question of programming style After studying the ARM and "Ada as a second language" (Normal H. Cohen, 1996), I came to the conclusion that Ada as a language does not directly address/ has no apparently obvious approach wrt whether it is desirable to separate interfaces for clients of classes vs. derived classes, and if so, how to implement the separation. IMO, this question is of great interest in the construction of reusable, stable components in OO systems (I made this experienced in several large projects done in C++.) I strongly disagree with the idea of implementing derived classes in child packages of the package containing the base class. This allows derived class implementations to access all private data and functions of a base class (even up the base class chain). Changing a base class' private implementation therefore possibly breaks a potentially large number of derived classes. From my experience in C++ projects this implementation is a BAD idea that should be avoided wherever possible. Derived classes should instead use interface functions of their base class to implement their services. Information hiding principles should apply between base and derived classes as well as between a class and its clients. If we agree on this principle, there would be three possible implementations of such a derived class interface: i) in the package where the base class type is defined ii) in a nested package thereof iii) in a child package thereof Choice i) would make the derived class interface part of the public interface advertised to all clients of a class. This is, IMHO, also a BAD idea wrt information hiding. It would advertise services in the public interface of a class that clients really are not allowed to request. Choice ii) has the same problem. Services in a nested package would require us to provide functions called by them in the outer package which would then again become part of the public interface. These were the reasons I got to the following coding idiom: o For every tagged type "base" in a package "base_package", the public interface of "base" is declared in "base_package" as normally for ADTs. o Functions and procedures needed for derived class implementation are declared in the private section of "base_class" when they must be primitive. o A child package "base_class.derived" contains, in its public interface, functions/procedures that together form the interface of "base" for derived classes. These functions may access private functions/ data of "base" because "base_package.derived" is considered to be part of class "base". o A derived class "derived" is implemented in a package "derived_package" that is not a child package of "base_package" to prevent "derived" from relying on the private implementation of "base". o "derived" uses the public interface of "base" together with the services in "base_package.derived" for its implementation. What are your thoughts about it? Do you think it is as important as I do? Are there perhaps other ways of doing it? -- Gerd Moellmann, Altenbergstr. 6, D-40235 Duesseldorf, Germany Software Development & Consulting Internet: mmann@ibm.net / CIS: 100025,3303 / Phone: +49 211 666 881