Re: OO vs procedural

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 04 May 2006 22:21:37 +0200, Ludovic Brenta wrote:

> "kevin  cline" <kevin.cline@gmail.com> writes:
>> In the second paper, they give this example:
>>
>> 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".

No, I don't think that was the point.

I agree with Kevin. IMO the designs the author presented are obviously not
equivalent. So the paper is quite misleading in that respect. More
detailed:

SP version goes:

procedure Handle (A: Alert) is
begin
   CH; -- Code common to all alerts
   Log (A); -- alerts are logged here
   case A.Device is
      when Flaps =>
         FH; -- Flaps specific handling
      when Rudder =>
         RH; -- Rudder specific handling
   end case;
end Handle;

As an OO equivalent he presents Handle declared as a primitive procedure.
This is *not* an equivalent design pattern. An equivalent one would be to
use a class-wide Handle dispatching to device-specific handling:

procedure Handle (A: Alert'Class) is -- Class-wide
begin
   CH; -- Code common to all alerts
   Log (A); -- alerts are logged here
   Do_Specific (A);-- Specific handling
end Handle;

procedure Do_Specific (A : Flaps_Alert); -- Primitive

procedure Do_Specific (A : Rudder_Alert);

Now, Log is perfectly enforced as in SP version. (*)

The fallacy is that the problem of "extensible subprograms" is not specific
to OO. It is to Ada design. Furthermore, structured programming does not
respond this problem either.

-----------
*  BTW, author is silent about what would happen if some idiot called Log
from FH path. Observe, that Ada's OO design provides an additional *safety*
here: no implicit redispatch allowed. So if Log were declared class-wide
(as it should), then Ada compiler wouldn't let our idiot to call it from
Do_Specific, without an explicit type conversion!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de