Re: OO vs procedural

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

"kevin  cline" <kevin.cline@gmail.com> writes:
> In the second paper, they give this example:
>
> type Alert is abstract tagged record
>   ...
> end record;
> procedure Handle(A: Alert);
>
> type Flaps_Alert is new Alert with record
>  ...
> end record;
>
> procedure Handle(A: Alert) is
> begin
>   -- Code common to all alerts
>   Log(A);
> end Handle;
>
> procedure Handle(A: Flaps_Alert) is
> begin
>   Alert(A).Handle; -- do common processing
>   ... -- flaps specific processing
> end Handle;
>
> The authors then point out a describe a potential pitfall of this code
> -- that a derived type implementation may fail to call the base
> implementation.  This is true.  The authors fail to point out that this
> possibility could have been prevented by correct base class design.
> 
> I also fail to understand why this error is hard to test, but perhaps I
> do not understand S3 testing methods.  I would have expected that a
> failure of a derived type X_Alert to call the base type Handle method
> would have been caught by a unit test of X_Alert, when it was observed
> that after calling X_Alert.Handle, no logging occured.
>
> I would also expect that the error would be easily detected through any
> formal verification process, since the erroneous Handle method would
> not meet the 'Logging occured' postcondition.

Of course, what you say is true - good unit testing or good peer
review will catch the error, and the formal verification process will
document how the error was found, corrected, and verified to be
corrected.  But, by that argument, "any good programmer with a good
process can write perfect software in any language, even assembly
language".

The point is to help the compiler catch the error automatically,
before the first unit test is written and before any peer review takes
place.  Compile-time checks are why we (in avionics) use Ada in the
first place.  In other industries, people also like the run-time
checks, which help later, i.e. during testing.

-- 
Ludovic Brenta.