Re: LSP Was: Mixing OO and DB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 23 Feb 2008 13:24:18 -0400
Message-ID: <47c056c4$0$4051$9a566e8b_at_news.aliant.net>


Stefan Ram wrote:

> Robert Martin <unclebob_at_objectmentor.com> writes:
>

>>Maybe I'm missing something.  The principle has been around for a long 
>>time.  The old quote from the May, 1988 Sigplan Notices was:

>
>
> There, it is being attributed to a »forthcoming« work of Leavens:
>
> Gary T. Leavens, Verifying Object-Oriented Programs that
> use Subtypes. Massachusetts Institute of Technology,
> Laboratory for Computer Science, Technical Report TR-439,
> February 1989.
>
> Barabara Liskov in a later work has used simpler wording to
> explain the meaning of »subtype« (without quantifiers).
>
> I do not apreciate the original »LSP« that much, because it
> lacks explicit reference to specification (contract).
>
> I would prefer the following criterion (in my own wording):
>
> »B is a subtype of P, when it fulfill P's specification.«
>
> The Circle/Eclipse problem is related to the
> value/storage-mismatch. I am not aware of a source expressing
> this explicitly, so I would like to elaborate in my own
> wording:
>
> In the following paragraphs »type« will refer to a »primitive
> type« (a set of values), while above it referred to a
> »behavior type« (a type of objects).
>
> When B is a subset of P, then each element b of B /is a/ P
> (i.e., is also an element of P). But the inverse holds for
> storage: A storage cell P* for P values /is a/ storage cell
> for B values.
>
> B < P ==> P* < B*
>
> For example, B := {0,1}, P := {0,1,2,3}, b e B, p e P, then
> each b is a p, but each P-storage is a B-storage (notice the
> changed order).
>
> Each circle is an eclipse, but each storage for eclipses is
> a storage for circles, while a storage for circles is not
> a storage for eclipses.
>
> All the discussions about this only stem from lack of care to
> distinguish between values and storages. The LSP is not needed
> to resolve this. One only needs to make clear whether an
> object of a given type is specified to represent a value or a
> storage for a value (thing of »String« versus »StringBuffer«
> in Java).

One wonders at the awkward phraseology when "storage for a value" has such a simple synonym: variable. Received on Sat Feb 23 2008 - 18:24:18 CET

Original text of this message