Brian Campbell

Welcome! I signed up for the AWS free tier and hope to explore some of its features using your book.

Thanks, everybody. That's basically the conclusion that we reached, but it took us a while to get there. :-)

What sealed the deal for the holdouts was a variation of Jeff's response: Imagine that we're only talking about non-negative integers. The range of illegal values in the supertype is {0,1,2,3,4,5}.

The range of illegal values for subtype A is {0,1,2,3,4,5,6}.

The range of illegal values for subtype B is {0,1,2,3,4}.

A smaller range of prohibited values represents a weakened precondition. But it was a fun discussion before things settled down. :-)

Thanks again!

Greetings,

Apologies in advance if this is the wrong forum, but it seems to be as good a candidate as any. I'm taking a Java-based software engineering course in graduate school, and the students have had quite an energetic offline discussion over one aspect of the Liskov substitution principle.

We all understand the main point: if S is a subtype of T, objects of subtype S may be substituted for objects of type T without altering any of the desirable properties of the program.

We are in fact using Liskov's Program Development in Java: Abstraction, Specification, and Object-Oriented Design as one of our textbooks, and as many of you know, she goes on to say in that book that a subtype can weaken but not strengthen the preconditions of the supertype, and can strengthen but not weaken the postconditions.

One slide generated quite a bit of discussion during one of the classes and via email afterwards (the professor has stepped back for the moment and let us duke it out).

Here's the question:

Class SuperType
//REQUIRES: x > 5

Class SubTypeA
//REQUIRES: x > 6

Class SubTypeB
// REQUIRES: x > 4

x>5 --> x>4?
x>5 --> x>6?

Which is the *weaker* precondition?

I can share quite a bit of discussion and conclusions here, but I would prefer to let some wise heads chime in first.

Thanks!

Campbell Ritchie wrote:Welcome to the Ranch, BC

Thanks!

I'm not completely sure if this is the question you're asking, but it might be worth pointing out that when you compare two objects using the == operator, you are testing whether the two values refer to the same object. As Campbell pointed out, the "default" equals() method in the Object class does the same thing.

On the other hand, String and most other Java core classes define the equals() method so that it compares the actual values of objects. If you want equals() to do this for your user-defined classes, you have to override the equals() method in Object. As Campbell mentioned, getting that override correct might not be a trivial task.