Re: Liskov Substitution Principle and Abstract Factories

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 02/08/05

  • Next message: Martin Sandin: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation" 
    Date: Tue, 8 Feb 2005 16:09:35 +0100

    On Tue, 8 Feb 2005 10:23:30 -0000, Mark Nicholls wrote:

    > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
    > news:1s7sc014i5s8v.37hfg2o79wdw$.dlg@40tude.net...
    >> On Mon, 7 Feb 2005 15:46:01 -0000, Mark Nicholls wrote:
    >>
    >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
    >>
    >> Not so. I just ask you to present an intuitively feasible model.
    >
    > *** in, *** out....(sorry that's the model).....

    That's a feasible model to me! (:-))

    >> In
    >> particular this means that if you wish to talk about correctness of a
    >> program as a random event, then you have to convince me that there are
    >> indeed some random outcomes of which this event is constructed.
    >
    > OK, but this goes to the heart of our problem, I consider an event where we
    > can observe partial information (i.e. and the other parameters are hidden
    > and 'random))...then the deterministic outcome of this will be statistically
    > modellable (?) in a similar way to dice and dogs(!).

    I don't know how it should work. Consider the value of Pi in decimal
    representation modeled this way. What is the probability that the figure 8
    will appear in the first decimal position?

    >> So far I
    >> don't see them either in the program source or in the definition of
    >> correctness.
    >
    > a definition of correctness is hard.

    No, it is easy, because it need not to be constructive. For any program x
    there is Is_Valid (x) defined. End of story.

    >...we could only give 'tests' to teams
    > and observe conformance to test.

    And what is the correctness of a test?

    >> Your argumentation was concentrated on the processes of
    >> perception and construction of programs by humans. I don't object that
    >> these processes might be random. I claim that it is just no matter.
    >
    > If I ask my 4 year old daughter to construct a program....she will not be
    > able to do it.
    > If I ask a 14 year old hacker to construct a large system....he will
    > probably give me some nightmare.
    > There are plenty of 35 year old programmers I wouldn't let loose anywhere
    > near a large system.
    >
    > So I must have a model in my head.
    >
    > That is the model I appeal to.

    Ask your daughter to add 2 to 2 and then model "+" as random. Modeling your
    daughter has nothing to do with modeling integer numbers.

    >>>>> OK, I want to be careful though....as you've pointed out inheritance can be
    >>>>> misconstrued as 'is a'.....and it's easy to automatically imply a mapping of
    >>>>> methods that may not actually work....as you have illustrated.
    >>>>
    >>>> Yes, but I have no problem with that, LSP does, not me. I buy
    >>>> substitutability violations to have an ability to write generic programs
    >>>> working for both R and C.
    >>>
    >>> You do eh.....OK....'working' then becomes interesting.
    >>
    >> Exactly. Note also that this re-shapes the problem of substitutability.
    >> Instead of talking about C as R, we should talk about R as R'Class and C as
    >> R'Class. This equalizes R and C, and explains why analysis and design are
    >> so important. In fact we should first design R'Class, while R is rather
    >> just an implementation.
    >
    > I buy this from the context of OOA/D.....this is how I work (and others).
    >
    > With a (psuedo) mathematicians hat on, it worries me.

    Why. Mathematicians are talking about fields, rings etc. R'Class is
    something like that.

    >>>> Anyway both mechanisms use types to resolve sqrt
    >>>> target. With three different [specific] sqrts and only two types how do you
    >>>> select the right one?
    >>>
    >>> you'll have to give me a specific concrete example.
    >>
    >> Let all three sqrts are visible in the same context:
    >>
    >> [real]sqrt : R->R
    >> [real]sqrt : C->C
    >> [complex]sqrt : C->C
    >>
    >> The last two have exactly the same profile. How would the compiler select
    >> the right one. Which is the right one?
    >
    > by name!
    >
    > they are different.
    >
    > how do you select '+' as apposed to '-'.....they are different.....so don't
    > give them a confusing label.

    Then you have to say why for "sqrt" there have to be different names in
    all(?) descendants of R, though for "+" there could be only one. Who or
    what determines this?

    >>>> Yep. The specification of realsqrt kills any reasonable extension of R in
    >>>> C.
    >>>
    >>> ?
    >>
    >> Otherwise, you would be able to override it.
    >
    > well you can, as long as you preserve behaviour....but I cannot see a way of
    > doing this...given any sensible defintion of sqrt.
    >
    > but then sqrt does have a particulary specific definition....I suspect you
    > could override sqrt if you override *, +,- etc.

    Overriding of sqrt etc just provides a part of the implementation of the
    polymorphic sqrt defined on the class. To do so, the contract of that
    polymorphic class-sqrt should allow its fulfilling in R, C and all other
    derived types. Or, if you want to consider it rather bottom up, then the
    contracts of R::sqrt and C::sqrt have to be compatible, so that you would
    be able to extract this common part and declare it the class-sqrt. The way
    R::sqrt is usually defined, excludes any reasonable class-sqrt. That is the
    problem.

    >>> if you want complexsqrt....you have to use it explicitly....you have shown
    >>> that 'sqrt' means different things in different contexts, to use the same
    >>> label is dangerous and invalidates any guarentees.
    >>
    >> OK, that means no substitutability again.
    >
    > there is not for complexsqrt.....and R......but you have shown them not to
    > be equivalent....if we talk about realAdd and complexAdd the situation is
    > different.

    Do you want to duplicate all methods? If yes then, why "+" have to be
    duplicated and P not? Duplicate everything! This will remove
    substitutability and all its problems!

    >>>> The problem is to fix all specification to allow all reasonable
    >>>> extensions in all derived type. This is clearly impossible. So one should
    >>>> live with substitution violations.
    >>>
    >>> or above.....if it don't work, add new behaviour rather than overriding and
    >>> hoping for the best when you *know* there are scenarios that wont
    >>> work.....the cost?.....maybe you loose subtyped polymorphism....you could
    >>> probably keep some under some strict conditions.
    >>
    >> But you cannot add new behavior. It is fixed in R'Class! You have to remove
    >> some old behavior to make place.
    >
    > you trying to preserve the mapping from C into R'Class.......I am saying
    > there is a 'subset' of C....(i.e. without method complexsqrt) that is still
    > mappable to R'class.....the 'extension' isn't.

    The subset of C + operations on it (with or without sqrt) = a type. Call it
    C'. You want to have in C' only the methods obtained from R. This type
    would be an exact equivalent of R, a completely useless one!

    >>>>>>> your also doing object substitution, and my brain is not up to it....it
    >>>>>>> looks too hard.
    >>>>>>
    >>>>>> Surely you have to define value mapping before you inherit operations.
    >>>>>
    >>>>> yes, but they all get mapped...I don't need to worry about
    >>>>>
    >>>>> C sqrt(R)
    >>>>> or
    >>>>> R sqrt(C)
    >>>>
    >>>> You have to. If somebody writes:
    >>>>
    >>>> Real Y;
    >>>> Complex X;
    >>>>
    >>>> Y := sqrt (X);
    >>>> X := sqrt (Y);
    >>>>
    >>>> There are many approaches to how to interpret the above...
    >>>
    >>> I cannot interpret them because it is not clear to me what sqrt means.....I
    >>> have two basic versions...with 4 possible representations of each..
    >>>
    >>> i.e. realsqrt or complexsqrt on { RxR,CxR,RxC,CxC }
    >>>
    >>> bu for P defined in R....I do not need to worry about the non
    >>> diagonals...they cannot exist in P.
    >>
    >> Yes of course, if we are indeed talking about P defined in out-R. But this
    >> is trivial and uninteresting if there is an injection R to C.
    >
    > uninteresting.....
    >
    > you want to move on to 'interesting' i.e. object substitution.
    >
    >> 1. out-R means that P has no input parameters, output parameters are
    >> contravariant. You cannot re-use such P with complex input parameters. Only
    >> with those convertible to R. This is the first substitution problem.
    >
    > can you write it.....like
    >
    > P(out R)

    procedure P (X : out R); -- This is Ada

    > "You cannot re-use such P with complex input parameters" ?
    >
    > there are none?!?

    Should you have any, it would be not substitutable.

    >> Formally: C cannot be an in-subtype of R.
    >>
    >> 2. I was talking about a much more interesting case for re-use. When P is
    >> defined on R'Class. For such P all type operations have to be conform,
    >> otherwise you will break the objects passed in and get garbage out.
    >
    > so what do you do with sqrt?

    I would return to the base type and change the contract of sqrt to make it
    more reasonable. For example:

    1. function sqrt (X : Real) return Real;
       -- Covariant result + multiple dispatch

    2. function sqrt (X : Real) return Real'Class;
       -- Class-wide result, no multiple dispatch required

    Let's consider (2). If you have a program which works only with Real and
    uses sqrt, then somewhere in it there could be:

    Real X, Y;
    ...
    Y := sqrt (X);

    Now, if X is negative, then the traditional "realsqrt" would raise an
    exception. In our case sqrt will not fail, but it will return R'Class with
    the type tag = Complex'Tag. But this value (Complex'Tag, y) can be
    converted to Real only if y has no imaginary part. Otherwise the conversion
    would raise an exception. As you see the effect is exactly the same, though
    the mechanics is completely different.

    The variant (1) should work too. It will dispatch to the sqrt with the
    profile Real : sqrt -> Real. That will raise an exception.

    So (1) and (2) will work with Real-programs as expected. Yet I will be able
    to write generic programs in terms of Real'Class.

    >> And again, for P of R'Class I'll buy any substitutability problem. Because
    >> generic/polymorphic programming is an advance in order of magnitude. It is
    >> like a jet engine vs. horse. Horses don't explode, I know, nevertheless.
    >>
    >>>> If you have a time machine. Templates, relational type systems are in the
    >>>> past. Of course, you can find an ecological niche and sit there some time,
    >>>> but sooner or later life will smoke you out of there...
    >>>
    >>> If your in a dead end, it is sometimes better to turn around.
    >>
    >> Look up!
    >
    > someone dropping a piano on your head!

    Is it so important to turn around then? I mean, from under which side of
    the piano your legs will protrude... (:-))

    >>> If your stuck in a hole, stop digging.
    >>
    >> ... or else you'll get on the other side of the globe. I like the idea of
    >> heading for Australia. The weather is miserable! (:-))
    >
    > ooo, it's a long way, and I don't think it's worth it, I can have a BBQ in
    > my garden in the summer.

    ...in that trench, you have dug through? (:-))

    >>> I have noticed over the years OO has retreated back to a more stuctured or
    >>> object based approach....maybe that was all that was needed, maybe more. I
    >>> have a many problems with object orientation, for a start I think it should
    >>> read objectS orientation i.e. I start with sets of things (even if those
    >>> things are sets or even empty sets), rather than values and add sets as
    >>> another set of axioms....the axioms for values are not required and put the
    >>> cart before the horse.
    >>>
    >>> In the real world it would seem to be a huge hindrance to always talk about
    >>> the object (singular)....we are stuck in implementation detail which is
    >>> difficult to abstract into logic......jump into the RDB world and
    >>> boooomm.......I can actually apply logic to sets of things....it is so much
    >>> more expressive and powerful....I can apply logic to logic to logic, while
    >>> the OO are still wrestling with the basics of x.IsValid = true.
    >>
    >> It is a delusion. RDB is a very trivial flat type model.
    >
    > what simplicity.....lovely.

    "God made the integers; all else is the work of Man."

    - Kronecker

    >> Your "logic" will
    >> stop working as soon as you'll have such simple thing as an incomparable
    >> type.
    >
    > fuse the models.
    >
    >> BTW, nothing prevents you from implementing relations in an OO
    >> language.
    >
    > ooo I know....I'm doing so.
    >
    >> The problem is that this would be by no means feasible for a
    >> great majority of applications, RDBMS inclusive, I bet that nobody would
    >> write an SQL server in SQL. After all the more primitive model you take,
    >> less problems you have. Take Boolean logic, and enjoy relay systems of 30s.
    >> But I'd better stick to modern times!
    >
    > I accept, but I think 'programming' has missed a trick....and one 'trick'
    > has been capture in RDB's......I worry (and you just need to read the
    > threads here) that OO has become large, confused and clumsy....that makes me
    > think something is wrong or missing.

    OO is not a theory, it is a hype. The theory is ADT. Then as I said before,
    the problem is that programming and science somehow took different routes.
    Scientific research does not respond real-life problems of software design.
    I have an impression that it is concentrated on though interesting but
    unfortunately irrelevant artificial constructs. On our side, we,
    programmers are much arrogant and even more ignorant. The era of great
    programmers-scientists is gone, and you know, somebody have to expel that
    traders from the temple! (:-))

    > RDB's in comparison seem simple (triviality for mathematicians is often
    > equitable with simplicity and beauty....it is not an insult, but a
    > compliment), yet strangely powerful, and self consistent.

    Everything is Turing-complete...

    > OO in comparison
    > is more complex, more expressive (yes), but somehow clumsy at times. Stick
    > them together.

    It is impossible. RDB's types is a tiny subset of ADT. The problems start
    to mount when we leave this subset to face the new bright world... 

    -- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
  • Next message: Martin Sandin: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation"