Object-Oriented Analysis and Design Lecture 8 State Space, Behavior, and Type Conformance

Goals We’re looking for desirable properties of classes and class hierarchies. Violations of these good properties certainly may compile, but… Think of these properties as being like “normal forms” in database theory.

A Class Should “…represent a uniform abstraction of the properties of the individual objects that belong to the class.” The keys are state space and behavior.

State Space of a Class The state space of a class C is the set of all permitted states of any object of class C. The dimensions of a state space are the coordinates needed to specify the state of an object. Example: Intersections at Forbes and Morewood Forbes and Craig Forbes and Morewood parking lot

Another Example A CD player; what are the legal transitions? Current Track Seconds Remaining … “Point” in state space

State Space The dimensions of a class may be the same as its attributes. But attributes may not be simple types (ints, etc.) so state may be much more complicated. Also, there may be many ways to specify dimensions, e.g., secondsRemaining & totalLength percentFinished & totalLength

State Space of a Subclass If S is a subclass of T, then the state space of S must be contained in the state space of T. S’s state space is “confined” by T’s. Ex: T = Book, attribute numPages S = ChildrensBook 0600 numPages

State Space of a Subclass IF S is a subclass of T, then S’s state space must include at least all the dimensions of T’s. S’s state space can “extend” from T’s numPages numIllustrations Book ChildrensBook

Behavior of Classes & Subclasses A class’s behavior is the set of allowed transitions within its state space. A subclass can have its behavior Confined (can’t add 150 pages to a ChildrensBook), and Extended (we can add illustrations).

Class Invariants A class invariant is a condition that must be satisfied by every object of the class. Ex: Triangle, w/ side lengths a, b, and c. a+b  c b+c  a c+a  b In the 3-D state space, not all points are legitimate. In good designs, invariants are inherited (e.g., isosceles triangles, right triangles, etc.). a b c

Pre and Post Conditions These are for methods. Think of a contract between a user and supplier: Precondition: must be true (of the object) when the method is invoked. If not, the method has no obligation to perform correctly. Postcondition: must be true (of the object) when the method finishes. If not, the method is broken.

Responsibilities The object sending the message is obliged to check the precondition. If it’s satisfied, the object being called must guarantee the postcondition will be true after execution If the sender can’t guarantee the precondition, there is no guarantee of the postcondition. Class invariant and operation precondition Operation executes Class invariant and operation postcondition

Example: Database Insertion Invariant: Unique primary key in table A and foreign key points to existing record in table B. Precondition on insert into table A: Primary key of new record is unique in A Foreign key of new record exists in B Postcondition: New record exists in table A

When Designing New Methods Know the class invariants. Document the method’s pre and postconditions. Decide what to do if precondtions aren’t met. Test all three parts.

What is the True Dimension? Consider the positioning of Rectangle class objects (that can stretch, rotate). The class could hold Four corner points, or Top-left, bottom-right, and orientation, or Center, height, width, orientation. What is the correct number of dimensions? What does this have to do with invariants?

Types Again, the goal is to characterize good classes and class hierarchies. The type of a class includes its purpose invariants attributes operations, and their pre and postconditions, and signatures

Type vs. Class A type is independent of the implementation. There may be several implementations (classes) for a given type.

In Together, We Could Say:

So Far, So Good… But what if we try this? subclass = subtype?? No!

Type Conformance If S is a true subtype of T, then S must conform to T. That is, an object of type S can be provided wherever an object of type T is expected. Now technically, in Java and C++ this will always be so, but finding the diagonal of an Elephant is nonsensical.

Ensuring Type Conformance The invariants of the subclass must be at least as strong (restrictive) as those of the superclass. Every method of the superclass has a corresponding method in the subclass (with the same name and signature). Every subclass method’s precondition is no stronger than that in the superclass. Every subclass method’s postcondition is at least as strong as that in the superclass.

A Classic Example Employee gradeLevel > 0 perfEval  [0, 5] bonusPct  [0, 10] calcBonus(perfEval, bonusPct)  [0, 10] Manager calcBonus(perfEval, bonusPct) overridden What are legitimate ranges for Manager’s gradeLevel? perfEval? bonusPct ? calcBonus()?

A Classic Example (cont.) Manager class invariant: gradeLevel > 10 is OK gradeLevel  [-1, 15] not OK calcBonus() precondition: perfEval  [0, 6] is OK perfEval  [1, 4] not OK calcBonus() output (postcondition): calcBonus()  [0,8] is OK calcBonus()  [-1, 13] not OK

Why? Once again, an object of subtype S must be usable anywhere an object of the supertype T is.

Closed Behavior A final principle: Any operation on an object from class C – including inherited operations – should obey C’s class invariants. Example: the intersection at Forbes and Morewood parking lot. Intersection invariant: “Walk” signal can’t be displayed when any traffic light is green. Maybe we want a “turn right” arrow when the “Walk” signal is displayed?

A Question A Rectangle class, with methods rotate(angle) and scaleHoriz(scaleFactor) Now add subclass Square. Any principles violated? What are the possible solutions?

Another Question What’s wrong here? How to fix it?