Re: Entity and Identity

From: Nilone <>
Date: Mon, 27 Jul 2009 03:32:22 -0700 (PDT)
Message-ID: <>

On Jul 27, 12:01 pm, David BL <> wrote:
> On Jul 27, 4:02 pm, Nilone <> wrote:
> > I'm concerned about your statement about LSP and subtyping state
> > machines.  I just don't see how (or why) you would subtype a state
> > machine.  I'll allow subtyping an interface and implementing a new
> > state machine for it.
> That's actually what I meant.  A "type" of state machine is what you
> are calling an "interface".   E.g. a SeekableInputStream is a subtype
> of a InputStream.  It follows that a reference (to a state machine) of
> type SeekableInputStream can be upcast to a reference of type
> InputStream.
> I think of types as completely divorced from implementation (for both
> data types and state machine types).
> > LSP requires any property provable about objects of the base type to
> > be provable of objects of the derived type.  Subtyping a state machine
> > would have little value, since you wouldn't be able to change any
> > behaviour - "any property provable about the base type" would include
> > its exact behaviour.
> I agree that subclassing a concrete class doesn't make much sense.  It
> is important to distinguish between:
> a) state machine "type", which refers to interface definition (of
> method signatures as well as contracted behaviours); and
> b)  state machine "implementation".
> Class hierarchies confuse this distinction by defining both at the
> same time.  That being said I'm not too surprised that it's common
> practise.  Separating type and implementation can make for a lot of
> repetition.  In a language like C++ it also tends to defeat inlining.

Limiting inheritance to just interface inheritance, even from concrete classes, would solve that nicely. Received on Mon Jul 27 2009 - 12:32:22 CEST

Original text of this message