Liskov substitution principle

02-25-08, 02:57 AM

George

Hello everyone,

I am learning Liskov substitution principle,

http://en.wikipedia.org/wiki/Liskov_...tion_principle

But the description is not common senses. Now I understand this principle to
be, if we have some methods in base class, then we also need to implement the
methods in derived class. My understanding correct? Anything else missing?

thanks in advance,
George

02-25-08, 04:48 AM

Alf P. Steinbach

* George:
>
> I am learning Liskov substitution principle,
>
> [..]
>
> But the description is not common senses. Now I understand this principle to
> be, if we have some methods in base class, then we also need to implement the
> methods in derived class. My understanding correct? Anything else missing?

What Liskov substitution is about requires physical object compatibility
such as having the relevant member functions, but it is not about that.

It is about what member functions do, or not.

For example,

struct Base
{
virtual double squareRoot( double x ) const { return ...; }
};

struct Derived: Base
{
virtual double squareRoot( double x ) const { return 666; }
};

presumably breaks the LSP.

Whether it actually breaks the LSP depends on the contract for
Base::squareRoot.

C++ only has rudimentary support for catching LSP violations via the
type system. But the LSP serves as a guideline with enforcement by the
programmer. If the programmer is any good.

Cheers, & hth.,

- Alf

02-25-08, 06:21 AM

George

Hi Alf,

In your sample, how the rule is broken? I read your sample a couple of
times, but still confused. Your Base and Derived class have the same method
with the same signature? Do you mean the squareRoot method in derived class
does not do what actually the function name indicates -- not calculating
square root, but return some constant value?

> What Liskov substitution is about requires physical object compatibility
> ch as having the relevant member functions, but it is not about that.

regards,
George

02-25-08, 06:42 AM

Alf P. Steinbach

<quote of myself>
Whether it actually breaks the LSP depends on the contract for
Base::squareRoot.
</quote of myself>

* George:
[..]

02-25-08, 07:32 AM

George

Thanks Alf,

> <quote of myself>
> Whether it actually breaks the LSP depends on the contract for
> Base::squareRoot.
> </quote of myself>

I think you mean if the contact is having the same signature, the LSP is not
broken. But if the contract is calculating the actual square value, not a
fake one, then the contract is broken?

regards,
George

02-25-08, 07:59 AM

Alf P. Steinbach

* George:
>
>> <quote of myself>
>> Whether it actually breaks the LSP depends on the contract for
>> Base::squareRoot.
>> </quote of myself>
>
> I think you mean if the contact is having the same signature, the LSP is not
> broken. But if the contract is calculating the actual square value, not a
> fake one, then the contract is broken?

Informally, yes, if the contract is broken then the LSP is broken.

However, a contract can in practice never be to calculate the actual
square value, because that would make the function non-returning for
most argument values, where the actual square root can not be
represented by the result type.

In a sound design contracts need to be realistic and enforceable. A
contract that relies on "common sense" is worth something close to zero.

- Alf

02-25-08, 08:18 AM

George

Thanks Alf,

> However, a contract can in practice never be to calculate the actual
> square value, because that would make the function non-returning for
> most argument values, where the actual square root can not be
> represented by the result type.

For example, negative values as input?

regards,
George

02-25-08, 08:59 AM

Alf P. Steinbach

* George:
>
>> However, a contract can in practice never be to calculate the actual
>> square [root] value, because that would make the function non-returning for
>> most argument values, where the actual square root can not be
>> represented by the result type.
>
> For example, negative values as input?

No, that goes to the general domain of the function (which is part of
the contract, but not relevant in this context).

I confess I feel a little like the Pythagoreans now...

<url: http://scienceworld.wolfram.com/biography/Hippasus.html>

Grumble,

- Alf

02-25-08, 09:34 AM

George

Hi Alf,

I studied the math description and some related links. It is about
Pythagoras's constant cannot be expressed as a ratio of integers, not about
how to calculate square root.

To make it clear what you said below,

> >> However, a contract can in practice never be to calculate the actual
> >> square [root] value, because that would make the function non-returning for
> >> most argument values, where the actual square root can not be
> >> represented by the result type.

Why if the contract is calcualte the actual square [root] value, then "that
would make the function non-returning for most argument values" and "the
actual square root can not be represented by the result type."?

(I think of a samples of input of negative values, but you think it is not
correct.)

regards,
George

#10

02-25-08, 09:42 AM

Alf P. Steinbach

* George:
> Hi Alf,
>> I studied the math description and some related links. It is about
> Pythagoras's constant cannot be expressed as a ratio of integers, not about
> how to calculate square root.
>
> To make it clear what you said below,
>> Why if the contract is calcualte the actual square [root] value, then "that
> would make the function non-returning for most argument values" and "the
> actual square root can not be represented by the result type."?
>
> (I think of a samples of input of negative values, but you think it is not
> correct.)

Write a little piece of code that checks whether the function returns
the "actual square root".

#11

02-25-08, 10:17 AM

George

Hi Alf,

I am confused about the following comments.

> Write a little piece of code that checks whether the function returns
> the "actual square root".

I did some search. The magic Quake implementation for square root
calculation and the normal ones,

http://blog.donews.com/snailact/arch...01/806370.aspx

http://www.codecodex.com/wiki/index....er_square_root

for my quoted your above comments, do you mean something like type
conversion makes result in-accurate? Like convert from double to return type
long?

regards,
George

#12

02-25-08, 11:12 AM

Alf P. Steinbach

* George:
> Hi Alf,
>> I am confused about the following comments.
>> I did some search. The magic Quake implementation for square root
> calculation and the normal ones,
>
> [..]
>
> [..]
>
> for my quoted your above comments, do you mean something like type
> conversion makes result in-accurate? Like convert from double to return type
> long?

I meant what I wrote, "write a little piece of code that checks whether
the function returns the "actual square root"".

It's only way I can think of to make you understand, by actually trying
to do it.

Here's a start:

struct Base
{
virtual double sqrt( double x ) const { /* something*/ }
};

struct Derived: Base
{
virtual double sqrt( double x ) const { return 666; }
};

bool verifiesOK( Base const& o )
{
/* something, checking that sqrt delivers "right" results */
}

int main
{
say( verifiesOK( Derived() )? "OK" : "Uh, LSP is b0rK3n" );
}

To understand this you will have to really make an attempt at
implementing the verifiesOK() function.

Then post your code.

Cheers, & hth.,

- Alf

#13

02-25-08, 11:37 AM

Alex Blekhman

"George" wrote:
>
> I am learning Liskov substitution principle,
>
> [..]
>
> But the description is not common senses. Now I understand this
> principle to
> be, if we have some methods in base class, then we also need to
> implement the
> methods in derived class. My understanding correct? Anything
> else missing?

No. All it says that derived class should behave exactly as its
base class. So, if you substitute all instances of base class in
your program with instances of derived class, then program should
still work as if nothing happend. If a program behaves differently
when using derived class instead of base class, then LSP is
broken.

Alex

#14

02-25-08, 11:53 AM

Alf P. Steinbach

* Alex Blekhman:
> "George" wrote:
>
> No. All it says that derived class should behave exactly as its
> base class. So, if you substitute all instances of base class in
> your program with instances of derived class, then program should
> still work as if nothing happend. If a program behaves differently
> when using derived class instead of base class, then LSP is
> broken.

I don't think you mean that.

The purpose of deriving a new class is most often to modify behavior.

Any program using the derived class will then most likely exhibit
slightly different behavior, without the LSP being broken in any way.

Cheers,

- Alf

#15

02-25-08, 12:50 PM

George

Hi Alf,

I think you mean base and derive have different semantics of what returns
for square root calculation, which is hard for people to write a unified
verification function (your example, verifiesOK)?

It means base and derive do not follow the same contract to implement square
root function, which breaks LSP pattern?

regards,
George

"Alf P. Steinbach" wrote:
[..]

Similar Threads
OO Concept: Liskov Substitution Principle Hi, Just read an article talking about the LSP in term of OO design: [..] The article said Rectangle class should not be a superclass of Square class. Okay, so how you...
Ada Interfaces and the Liskov Substitution Principle Hi all, to me, it seems as if Ada 2005 is bluntly violating the Liskov Substitution Prinicple. E.g., define ---Start--- package Parents is type Parent is Interface; --...
Undecidability of Liskov Substitution Principle Esdger Dijkstra allegedly said "Object-oriented programming is an exceptionally bad idea which could only have originated in California." :-) I found this paper a while ago,...
Liskov Substitution Principle Is this design well-formed? It contradicts the LSP and Design by contract anyhow. LSP tells us that "In class hierarchies, it should be possible to treat a specialized object...
I have proven Mrs. Liskov to be wrong! (Liskov Substitution Principle) NOW I got your attention... ;) Sorry couldn't resist, but I AM serious, follow up and I'll try to convince you too... Regarding this post: I had some posts earlier in this...