OOP v,. itooJobili

O O P v,. itooJobili JeffTey R. Carter PragmAda Software Engineering 1540 Coat Ridge Road Herndon, VA 22070-2728 72030.677Qcompuserve.corn Introduction A previous paper discussed the relationship between the object-orientedprogramming (OOP) feature known in Ada 95 as dispatching and Ada's expressed design goal of emphasizing ease of reading and understanding over ease of writing [1]. A comparison of Barnes' alert-system example [2] using Aria-95 dispatching and using Ada-83 composition showed that dispatching emphasized ease of writing over ease of reading, while composition emphasized ease of reading over ease of writing. This led to the conclusion that the goals of dispatching conflict with Ada's expressed design goals. Dispatching is half of OOP; the other half is inheritance, correctly called type extension in Ada 95. This paper examines the relationship between inheritance and Ada's expressed design goal of emphasizing ease of reading and understanding over ease of writing. Object-oriented design ( 0 0 0 ) , as introduced by Booch [3], emphasizes the software-engineering principles of locality, encapsulation, and information hiding. Aria B3 supports such OOD well; using OOD and Ada results in easy-to-mad programs that exhibit low coupling and high cohesion. OOD is independent of OOP: Fully objectoriented designs may be implemented using composition methods familiar to Ada-83 users without any need for OOP features (inheritance and dispatching). OOP features may likewise be used without OOD. A/err System Let's start with the alert system used in the discussion of dispatching. Consider the package that defines high-level alerts: with Medium_Alert Sys tern; with Calendar; package High_Aler~_Sys~em .is type High_Alert_Handle is new Medium_Alert with record Alarm_Time : Calendar. Time; end record; procedure Handle (AlerU end High_Aler t_Sys tern;

: in out High_Alern

System.Medium_Alert_Handle

Handle);

High_Alert_Handle is defined using inheritance. If inheritance supports Ada's expressed design goals, then this should be easy to read and understand, in which case it should be easy to answer such questions as: What are the visible components of the type? What are the visible operations on the type?

ACM Ada Letters, Mar/Apr 1997

Page 63

Volume XVII, Number 2

In fact, we cannot answer such questions without examining the type's parent type, Medium_Aler

t_Handle:

with Low_Alert_System; package Medium_Alert_System is type Medium_Alert_Handle is n e w L o w _ A l e r t _ S y s t e m . L o w _ A l e r t _ H a n d l e with record O f f i c e r : S t r i n g (I .. SO} := s t r i n g ' (i .. 80 = > ' ') ; end record; procedure Handle (Alert end Medium_Alert_System;

in out MediumAlert_Handle);

:

W e still can't answer our basic questions about High Alert_Handle. Continuing our search, we examine L o w _ A l e r t _ S y s tern: with Alert_System; with Calendar; package Low_Alert_System is type Low_Alert_Handle is n e w A l e r t _ S y s t e m . A l e r t _ H a n d l e with Time : Calendar. Time; M e s s a g e : S t r i n g (i .. 80) := S t r i n g ' (I .. 80 => ' '); end record; procedure Handle (Alert en~ Low_Alert_System;

record

: in o u t L o w _ A l e r t _ H a n d l e ) ;

Finally, we examine Alert_Systen~ package Alert_System type Alert_Handle procedure Handle end A l e r t S y s t e m ;

is is a b s t r a c t (Alert

:

tagged

null

record;

in o u t A l e r t _ H a n d l e )

is a b s t r a c t ;

Now we know that High_Alert_Handle has four visible components, Time, M e s Officer, and Alarm_Time; and a single visible operation, H a n d l e . However, we had to look at four packages to determine this. This is a clear violation of the software-engineering principle of locality, which holds that one should be able to obtain all the information about something in one place. Locality is important in achieving low coupling. While it is possible to violate the principle of locality without using inheritance, it is impossible to use inheritance effectively without violating locality. Inheritance is similar to Aria 83's derived-type mechanism, and A d a 95 implements type extension as a variation of type derivation. Unless the parent type is a predefined type, or defined in the same declarative region, derived types have the same failing as inheritance, which led many Ada users to limit the use of derived types to situations where the parent type meets these criteria. Such limitations could also be applied to inheritance. sage,

Bank-Account Example W e can see the same problem with a variation of Balfour's bank-account example [4]. To understand

A C M Ada Letters. M a r / A p t 1897

Page 64

Volume XVll, Number 2

with A c c o u n t _ H a n d l e r ; with Checking_Handler; pacHage Checking_With_Interest_Handler is t y p e I n t e r e s t _ V a l u e is d e l t a 0 . 0 0 0 0 1 d i g i t s type Checking_With_Interest_Account Checking_Handler.Checking_Account with record R a t e ; I n t e r e s t _ V a l u e := 0.0; e n d record; procedure

Open

(Account Amount Fee

Rate

8 range

0.0

.. 1.0;

is n e w

: in out C h e c k i n g _ W i t h _ I n t e r e s t _ A c c o u n t ; : in Account_Handler.Money_Value; : in Account_Handler.Money_Value; : in Interest_Value);

procedure Earn_Interest ( A c c o u n t : in out C h e c k i n g _ W i t h _ I n t e r e s t _ A c c o u n t ) ; end Checking_With Interest_Handler;

we have to look at with Account_Handler; p a c k a g e C h e c k i n g _ H a n d l e r is t y p e C h e c k i n g _ A c c o u n t is n e w A c c o u n t _ H a n d l e r . B a n k _ A c c o u n t Fee : Account_Handler.Money_Value := 0.0; e n d record; procedure

Open

(Account Amount Fee

procedure

Withdraw

with

record

: in o u t C h e c k i n g _ A c c o u n t ; : in Account_Handler.Money_Value; : in Account_Handler.Money_Value);

(Account

: in o u t C h e c k i n g _ A c c o u n t ; : in Account_Handler.Money_Value);

A m o u n t

end Checking_Handler;

and p a c k a g e A c c o u n t _ H a n d l e r is t y p e M o n e y _ V a l u e is d e l t a 0.01 d i g i t s - i 0 0 _ 0 0 0 _ 0 0 0 . 0 0 .. i00_000_000.00;

13 r a n g e

t y p e B a n k _ A c c o u n t is t a g g e d r e c o r d Open : Boolean := F a l s e ; B a l a n c e : M o n e y _ V a l u e := 0.0; end record; procedure

Open

(Account

procedure

Deposit

procedure

Withdraw

: in o u t B a n k _ A c c o u n t ;

(Account Amount

ACM Ada Letters. Mar/Apt 1997

: in M o n e y _ V a l u e ) ;

: in out B a n k _ A c c o u n t ; : in Money_Value) ;

(Account Amount

f u n c t i o n B a l a n c e (Account end Account_Handler ;

Amount

: in out B a n k _ A c c o u n t ; : in Money Value) ;

: Bank_Account)

Page 65

return Money_Value;

Volume XVll, Number 2

Only now do we know that C h e c k i n g _ W i t h _ I n t e r e s t _ A c c o u n t has four visible components, Open, Balance, Fee, and Rate; and seven visible operations, three named Open, and one each named D e p o s i t , W i t h d r a w , B a l a n c e , and E a r n _ Z n t e r e s t,

Conclusion OOD emphasizes the software-engineering principles of locality, encapsulation, and information hiding. Using OOD with composition results in easy-to-read.programs that exhibit low coupling and high cohesion, it is curious that OOP does not support OOD. Inheritance gains us something- We had to write less code using inheritance than we would have to write to implement these examples using composition, so using inheritance makes code easier to write. The price for this benefit is reduced readability. Using composition gains us something: The result is easy to read and understand. The price for this benefit is that we write more code. There are always tradeoffs in language design. Ada's expressed design goal, of emphasizing ease of reading and understanding over ease of writing, means such tradeoffs should be decided in favor of ease of reading against ease of writing, This was clearly not done in the case of inheritance. The goals of inheritance and dispatching, and so of OOP, conflict with Ada's expressed design goats. References 1. Carter, J., "Ada's 0esign Goals and Object-Oriented Programming," Ads Letters, 1995 Jan/Feb 2. Ads 95 Rationale, Intermetrics, Inc., 1995 3. Booch, G., Software Engineering with Ads, Benjamin/Cummings, 1983 4. Balfour, B., "Ada 9X: An Object Oriented View," Washington Ada Symposium tutorial, 1994

A C M Ads Letters, Mar/Apr 1997

Page 66

Volume XVll, Number 2