comp.lang.ada
 help / color / mirror / Atom feed
From: Ehud Lamm <mslamm@mscc.huji.ac.il>
Subject: Re: Help with project
Date: 1999/04/20
Date: 1999-04-20T00:00:00+00:00	[thread overview]
Message-ID: <Pine.A41.3.96-heb-2.07.990420123944.122970A-100000@pluto.mscc.huji.ac.il> (raw)
In-Reply-To: uvhes9ydi.fsf@gsfc.nasa.gov

> rross@postoffice.ptd.net (bob) writes:
> 
> > I must declare a record for a customer in the generic spec , and
> > instantiate it in our source code, inside this record will be info
> > about
> > the customer(time in queue, etc),
> > now, below in the private area, I have
> >  PRIVATE
> >   TYPE line;
> >   TYPE line_access IS ACCESS line; 
> >   TYPE line IS RECORD 
> >         info: X;
> >         Next: line_access;      
> >   END RECORD;
> > 
> > TYPE Agent IS RECORD
> >       	Head:line_access;
> >           cur_cust:line_access;
> >           free_time:Integer;
> > 	   etc(things for the agent)     
> > END RECORD;
> > 
> > where X is the customer record which will instantiated
> > the problem is, i have subprograms in the source that wont compile
> > because
> > i cant access agent or any of its fields, unless i go through the
> > spec.

Right!

This is the point of splitting the code into a spec and a body. You
achieve language enforced data hiding. This is very useful, when you get
to know it well, but can be combersome at first.

I think you should keep these two concepts in mind: interface and
implimentation.

The interface of a package is all the information other wiil need, and you
are willing to share. 

The implimenation details are your private secrets.

When you start thinking about desiging a package, you should ask yourself
what the user of the packger (that will be your main program) will need to
do. Than you take this list, and from it decide what you have to include
in your interface. 

From this you can later deduce the implimetation details - or actually if
your interface is good, you will have a lot of freedom in deciding on the
implimenation details.

Note that going this route can still lead you to bad design. After
designing the interface you should check to see if it makes sense. Some
things that are good to check are: consistency (is there any "logical"
connection between all the routines you supply), completeness (can the
user really do what needs to be done with the package?), simplicity etc.

Try it.
It is not all that hard, after your first couple of packages. 

If you want to get a good feel into this, I suggest you do two things:
(1) look at example code.
    There are many links on my web page - in the misc. links section

(2) read some articles about design etc.
    I suggest you look at my web page's "suggested online reading". 
    I'd recommend Parnas for general feeling of what "data hiding" is, and
perhaps Garlan & Shaw on architecture to give you a better feel of the
high level issue.

Enjoy!

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybercities.com/e/ehud/ada





      reply	other threads:[~1999-04-20  0:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-18  0:00 Help with project bob
1999-04-19  0:00 ` Stephen Leake
1999-04-20  0:00   ` Ehud Lamm [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox