Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!uakari.primate.wisc.edu!uflorida!beach.cis.ufl.edu!rmy
From: rmy@beach.cis.ufl.edu (Rasthiyaadu Yakaa)
Newsgroups: comp.lang.c++
Subject: C++, Object Design Methodologies and Software Engineering
Message-ID: <24872@uflorida.cis.ufl.EDU>
Date: 13 Oct 90 05:12:43 GMT
Sender: news@uflorida.cis.ufl.EDU
Reply-To: rmy@beach.cis.ufl.edu ()
Organization: UF CIS Department
Lines: 55


There is an issue in oo programming and software engieering
that has been bothering us for a few weeks, and i would like
to hear from knowledgeable/experienced persons on the net who
may have encountered a similar problem ..


On a database project, the work was divided up based on
functionality, e.g. data dictionary, query processor, object
management, among various individuals. Of course, a top down
design was done (blah, blah ..)

Now, each component is to be implemented in an oo manner.
Following, guidelines for object based design (Grady Booch etc)
the necessary system objects and classes were identified and
implemented. Each component obviously was broken down into 
various smaller components and so on.  Following reasonable
software engineering practices.

HOWEVER, we keep finding that when looking at a module or
component from a point of view of its functionality, and in its
entirety, we desire an interface for the entire component or 
sub component as a whole. Consider a software module or component
which comprises of several objects and classes. Clearly, each class
has an interface, which may be used by other classes in the same
module or by external components. When taken collectively, all 
classes in a module have a tremendous amount of interfaces
(messages) but only a small sub set of these need to be visible 
outside the module to other modules (sort of like an IC where 
one only sees the external interfaces and the internal interfaces 
between internal components are hidden - hope this is a
reasonable analogy). This makes it easier to conform to specs.
It is also easier to understand, convenient, and allows
changing internal interfaces. This it would seem is an issue
common to fairly large software projects ..

The question is: would it be wrong to define a class that simply
represents an interface to a layer or module. It would represent
collectively a set of interfaces corresponding to a software
module. e.g. a dictionary-handler class which represents the 
outside interface to a DBMS dictionary or catalog (which are
implemented as classes and objects). If this is OK,
what is the connection between such an interface class and 
system (dictionary) objects and classes.  If this is not OK, 
what are we doing wrong ?


Thanks in advance for all responses

e-mail is appreciated since i may miss articles in this 
newsgroup ..

yaseen

(rmy@beach.cis.ufl.edu OR rmy@trout.cis.ufl.edu)