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,959bd5b133447bcd X-Google-Attributes: gid103376,public From: Ehud Lamm Subject: Re: Help with project Date: 1999/04/20 Message-ID: #1/1 X-Deja-AN: 468661009 References: <371c09bd.16531847@news.ptd.net> Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: The hebrew University of Jerusalem Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-04-20T00:00:00+00:00 List-Id: > 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