18.10.2014 Views

Object-oriented Software in Ada 95

Object-oriented Software in Ada 95

Object-oriented Software in Ada 95

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Packages as classes 79<br />

The body of the package conta<strong>in</strong>s the def<strong>in</strong>ition of the procedures and functions def<strong>in</strong>ed <strong>in</strong> the specification<br />

part of the package. In access<strong>in</strong>g the Balance_Of conta<strong>in</strong>ed <strong>in</strong> an <strong>in</strong>stance of Account the . notation is used.<br />

For example, <strong>in</strong> the function balance the result returned is obta<strong>in</strong>ed us<strong>in</strong>g the statement ‘return<br />

The.Balance_Of;’. The . notation is used to access a component of an <strong>in</strong>stance of a record type. In this case,<br />

the <strong>in</strong>stance of the record type is the object The and the component of the object is Balance_Of.<br />

6.3.9 Term<strong>in</strong>ology<br />

The follow<strong>in</strong>g term<strong>in</strong>ology is used to describe the components of a class.<br />

Term<strong>in</strong>ology<br />

Instance<br />

attribute<br />

Instance method<br />

or just method<br />

Note:<br />

Example:<br />

<strong>in</strong> class Account<br />

Balance_Of<br />

Deposit<br />

Explanation<br />

A data component of an object. In <strong>Ada</strong> this<br />

will be a member of the type that is used to<br />

declare the object.<br />

A procedure or function used to access the<br />

<strong>in</strong>stance attributes <strong>in</strong> an object.<br />

The term<strong>in</strong>ology comes from the language Smalltalk.<br />

6.4 The package as seen by a user<br />

A user will normally only have access to the specification part of a package. This provides a specification of the<br />

messages that can be sent to an object but does not show how the methods <strong>in</strong>voked by the messages have been<br />

implemented. The implementation part will not normally be available, the implementor normally provid<strong>in</strong>g only a<br />

compiled version of the package.<br />

Unfortunately the details of the private type will normally be visible, though they cannot be accessed.<br />

Note:<br />

The details of the private type can be made <strong>in</strong>visible to a user, but this <strong>in</strong>volves some complexity. One<br />

approach to this is shown <strong>in</strong> Section 15.5.<br />

6.5 The package as seen by an implementor<br />

When build<strong>in</strong>g a package the implementor should ensure:<br />

• That a user of the package can make effective use of its facilities.<br />

• That the only visible components are:<br />

(a) The messages that can be sent to an object.<br />

(b) The private type declaration that is used to elaborate an object.<br />

The visibility hierarchy for the package Class_Account is shown <strong>in</strong> Figure 6.5.<br />

Visibility<br />

Component is:<br />

Visible to a client<br />

of the package.<br />

Invisible to a client<br />

of the package<br />

-<br />

Deposit<br />

Withdraw<br />

Balance<br />

Balance_Of<br />

Implementation of<br />

procedures and functions<br />

In the public part of the<br />

package specification.<br />

-<br />

In the private part of the<br />

package specification.<br />

-<br />

In the body of the<br />

package.<br />

Figure 6.5 Visibility of methods and <strong>in</strong>stance attributes of the package Class_Account.<br />

© M A Smith - May not be reproduced without permission

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!