Re: Liskov Substitution Principle and Abstract Factories

From: smilemac (smilemac_at_msn.com)
Date: 01/18/05 

Date: Wed, 19 Jan 2005 01:13:27 +0800

> The problem though is that:
>
> 1. out-parameters are needed too often to be ignored. Consider Integer::++
> which is an inout-method, and Positive is still substitutable there
> (differently to Integer::--).

I don't think so. You just need re-declare the operator ++ in Positive
definition and redirect the call to the base class, Integer. It's just a
very low cost.

>
> 2. in-parameters also violate LSP in subtyping by generalization. Consider
> Complex and Real. Complex is not an in-subtype of Real (it is an
> out-subtype, though.) Also so beloved type extension violates LSP.

For a generic Complex and generic Real, your are right. Complex is not a
subtype of real. In fact, type in computer science never equals to the
similar concept in math. It depends on your detailed contracts residing in
your concrete implementations.

> But in a real program you will need it to reuse out- and inout-methods of
> Integer. Like increment Integer::++. There is a large set of integer
> theorems with the exists-quantor which are still valid for positive
> numbers. All programs which rely on these theorems will not violate
> substitutability. This is the actual problem. To decide whether something
> is substitutable it is not enough to know the parameter profile and the
> relationships between the sets of values. One have to know the semantics
of
> the program.
>
That's the point. The root is that class is not exactly type in most
languages. So I high valuated LSP because to some extend it can help us
check if what we do is exactly what we want, i.e., the semantics
consistency.

Yours,
smilemac