Object-Oriented Analysis and Design

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

2. 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.

3. 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.

4. 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

5. Another Example • A CD player; what are the legal transitions? 10 9 8 7 6 5 4 3 2 1 “Point” in state space Current Track 0 1 2 3 4 5 6 … Seconds Remaining

6. 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

7. 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 numPages 0 600

8. 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. ChildrensBook numIllustrations Book numPages 0 600

9. 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).

10. 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.). c b a

11. 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.

12. 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

13. 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

14. 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.

15. 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?

16. 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

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

18. In Together, We Could Say:

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

20. 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.

21. 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.

22. 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()?

23. 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

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

25. 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?

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

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