1. L11-S1TOP 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San José State University One Washington Square San José, CA 95192-0180 http://www.engr.sjsu.edu/~fayad

2. L11-S2TOP 2003 SJSU --- CmpE M.E. Fayad 2 Lesson 11: Type-Oriented Paradigm (TOP)

3. L11-S3TOP 2003 SJSU --- CmpE M.E. Fayad Lesson Objectives (1) Overview of Previous Lecture Be able to use the type-oriented paradigm to define objects, classes, behaviors, and achieve good object-oriented software engineering objectives Understand how types define interfaces Learn about type specification and how to specify behavior Understand how classes implement types 3

4. L11-S4TOP 2003 SJSU --- CmpE M.E. Fayad Lesson Objectives (2) 4 Understand types and classes in C++ Understand subtypes Understand the differences between hierarchies and inheritance Learn the maintenance, modifications, and enhancements of software systems in TOP Understand the goals and qualities of TOP Explore the differences of terminology for types and classes

5. L11-S5TOP 2003 SJSU --- CmpE M.E. Fayad 5 Type-Oriented Paradigm You aren’t my type.

6. L11-S6TOP 2003 SJSU --- CmpE M.E. Fayad  Types Define Interfaces  Type Specification  Classes Implement Types  Types and Classes in C++  Subtypes ‘ Hierarchies and Inheritance ’ Maintenance, Modifications, and Enhancements “ Goals and Qualities ” Observations and Conclusions 6 Type-Oriented Paradigm: An Outline

7. L11-S7TOP 2003 SJSU --- CmpE M.E. Fayad Topics –A Type Names An Interface –Elements of An Interface –The Interface Includes Behavior –Interfaces With and Without Behavior 7 Type-Oriented Paradigm  Types Define Interfaces

8. L11-S8TOP 2003 SJSU --- CmpE M.E. Fayad Complete set of services/requests Says nothing about the implementation Message send, sender, receiver, length Stack push, pop, top, length Integer +, -, /, *, ** ReadAbleFile open, close, read, seek, length WriteAbleFile open, close, write, seek, length ReadWriteFile open, close, read, write, seek, length 8 A Type Names an Interface

9. L11-S9TOP 2003 SJSU --- CmpE M.E. Fayad A type names an interface. An interface is a collection of operation/requests/services ReadWriteFile: open, close, read, write, seek, length An operation has a signature void open(String name, Mode mode) A signature consists of a Name and Parameter Types Name - open Parameter Types - String, Mode 9 Elements of an Interface

10. L11-S10TOP 2003 SJSU --- CmpE M.E. Fayad 10 More about Elements of an Interface Behavior defines what an operation does; behavior defines the semantics of an operation  The Interface includes Behavior  Intended purpose of the operation name and the parameter names ‚Requirements placed on the client of the interface  What the object promises to do when it is requested to perform the operation „What the object does in exceptional circumstances or when an error occurs  The Elements of Behavior

11. L11-S11TOP 2003 SJSU --- CmpE M.E. Fayad  The purpose of operation “draw” defined as part of the interface for Type Person is to remove a bucket full of water from a well ‚Type ReadAbleFile requires the object to be in the state “open” before the operation “read” can be requested  Type ReadAbleFile promises that the object will read “numBytes” bytes and store them in “buffer” „Type ReadAbleFile promises to throw an exception “ReadError” If the operation “read” is requested and the object is not in the “open” state 11 Elements of Behavior: Examples

12. L11-S12TOP 2003 SJSU --- CmpE M.E. Fayad 12 Interfaces Without Behavior Without well-defined behaviors, the following interfaces would be identical: Stack void push(int i); int pop(); Car void push(int i); int pop();

13. L11-S13TOP 2003 SJSU --- CmpE M.E. Fayad With well-defined behaviors, the following interfaces would be distinct: Stack void push(int i);//put ‘ i ‘ on the Stack int pop();//remove and return the top value on the Stack Car void push(int i);//push Car at ‘ i ‘ feet per minute int pop();//pop the Car’s tire; return # of OK tires 13 Interfaces With Behavior

14. L11-S14TOP 2003 SJSU --- CmpE M.E. Fayad A type is a name used to denote a particular interface An object is of Type “ReadAbleFile” if it supports all the operations defined by the interface “ReadAbleFile” An object may have more than one type One portion of an object’s interface may be defined by one type and other portions may be defined by other types Two objects with the same type need only have portions of their interfaces in common 14 A Type Names an Interface Client Code uses the Type Interface

15. L11-S15TOP 2003 SJSU --- CmpE M.E. Fayad 15 Type-Oriented Paradigm  Type Specification

16. L11-S16TOP 2003 SJSU --- CmpE M.E. Fayad 16 Specifying Behavior Type Name Type “MessageRequest” Type Invariant properties shared by all objects of this type For each Operation void send(Address destination); //Purpose: //Parameters: //Requirements: //Promises: //Return Values: //Exceptions: //Intentional Vagueness Some Useful Special Symbols INITIAL, FINAL, RESULT, # IF, THEN, ELSE, WHEN,.... The Goal is Accurate Communication. The Goal is Accurate Communication.

17. L11-S17TOP 2003 SJSU --- CmpE M.E. Fayad 17 Type-Oriented Paradigm  Classes Implement Types Topics –A Class Implements a Type. –The Class Must Correctly Implement the Type. –Substitutability: Require No More and Promise No Less. –One Class Can Be Substituted for Another –A Type Can Have Multiple Classes –Clients Program to the Interface

18. L11-S18TOP 2003 SJSU --- CmpE M.E. Fayad 18 A Class Implements A Type A class defines: 1. Data layout2. Data structures 3. Source code4. Auxiliary methods 5. Algorithms Types and Classes In this context, a “class” means “the encapsulated implementation of a type. (in particular, a “class” is not being used to mean “C++ class”) Type Class Integer int, +, -, *, /,.... Stack Stack implementation using Array Container Linked List with Index

19. L11-S19TOP 2003 SJSU --- CmpE M.E. Fayad Assume “sample” is a method associated with a suitable class Correct int sample() //Promise: Returns an even integer between 0 and 100 { return 8; } Incorrect int sample() //Promise: Returns an even integer between 0 and 100 // with uniform distribution across this range { return 8; } 19 The Class Must Correctly Implement the Type.

20. L11-S20TOP 2003 SJSU --- CmpE M.E. Fayad 20 Substitutability * Require no more! Promise no less! * This is known as “controvariance.

21. L11-S21TOP 2003 SJSU --- CmpE M.E. Fayad Class cannot impose requirements on the client code beyond those defined by the Type. –Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed. Class must check for and respond in the way defined by the Type when requirements are not satisfied by the client code. –Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed and promises to throw an “IllegalRead” exception if the file is not “open”. 21 Require No More! (1)

22. L11-S22TOP 2003 SJSU --- CmpE M.E. Fayad Class can do whatever it wants when the specification is vague. –Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed (“Intentional Vagueness”). –Class ReadAbleFile can do anything it wants when the file is not “open” and the operation “read” is requested (read the file, throw an exception, print an error message, close the file, truncate the file,....) In this case, “Intentional Vagueness” informs the client of a requirement but gives the implementer flexibility in how to handle the situation. 22 Require No More! (2)

23. L11-S23TOP 2003 SJSU --- CmpE M.E. Fayad Class must fully perform the operation as defined by the type if the client code satisfies the requirements. Correct int sample() //Promise: Returns an even integer between 0 and 100. { return 8; } Incorrect int sample() //Promise: Returns an even integer between 0 and 100. { return 5; } 23 Promise No Less!

24. L11-S24TOP 2003 SJSU --- CmpE M.E. Fayad Type Stack Implemented by Class StackLL Replace Class StackLL with Class StackAR Type Message Implemented by Class MessageAppleTalk Replace Class MessageAppleTalk with Class MessageUDP Both classes must implement the same interface Client code unaffected by substitution 24 One Class Can Be Substituted for Another.

25. L11-S25TOP 2003 SJSU --- CmpE M.E. Fayad Type Stack Class StackLL implements a Stack. Class StackAR implements a Stack. Type Message Class MessageAppleTalk implements a Message. Class MessageUDP implements a Message Both classes must implement the same interface Client code unaffected by substitution 25 A Type Can Have Multiple Classes

26. L11-S26TOP 2003 SJSU --- CmpE M.E. Fayad The interface defines well-specified behavior. The interface (i.e., type) should be more stable than the implementation since it is based on the problem domain. When clients program to the interface: 1. Able to modify classes 2. Able to substitute classes 3. Able to change class hierarchy Aside If your interfaces are not stable, then you probably don’t have good abstractions or they are too closely tied to the implementation. 26 Clients Program to the Interface.

27. L11-S27TOP 2003 SJSU --- CmpE M.E. Fayad Today int sample() //Promise: Returns an even integer between 0 and 100. { return 8; } Client Code void clientCode() { int a[10]; cout << a[sample()]; } Client Code int sample() //Promise: Returns an even integer between 0 and 100. { return 88; } 27 Programming to the Implementation Considered Harmful

28. L11-S28TOP 2003 SJSU --- CmpE M.E. Fayad Developer’s modification is substitutable (complies with specification) Clients are at fault because they relied on the implementation instead of the interface. Aside Developers would be at fault if they failed to specify the interface. 28 Programming to the Implementation Considered Harmful

29. L11-S29TOP 2003 SJSU --- CmpE M.E. Fayad Types Encapsulate the Design Classes Encapsulate the Implementation 29 Class Implement Types: Summary

30. L11-S30TOP 2003 SJSU --- CmpE M.E. Fayad 30 Type-Oriented Paradigm  Types & Classes in C++ Topics –Two Concepts, One Language Facility –Guidelines

31. L11-S31TOP 2003 SJSU --- CmpE M.E. Fayad C++ classes are used for defining types and classes //Type Stack class Stack { /*.....*/ }; //Class StackLL -- an implementation of a Stack. class StackLL : public Stack { /*.... */ }; //Class StackAR-- implementation of a Stack. class StackAR : public Stack { /*.... */ }; You must use C++ classes in a disciplined fashion to properly separate these two concepts. This approach leads to a design which is more 1. Understandable/comprehensible 2. Flexible/extensible 3. Reusable 31 Two Concepts & One Language Facility

32. L11-S32TOP 2003 SJSU --- CmpE M.E. Fayad Define a type for every important concept in the problem domain Support client by modeling their problem domain Flexibility must be provided by developer Pass function parameters by type Flexibility must be received by client Request services using the interface defined by the type Flexibility must be received by client Avoid representation in types Do not impose implementation upon derived C++ classes “Client” refers to any user of an interface; a developer next door; a developer at a corporate partner; an end-user developer at a customer site. 32 Guidelines

33. L11-S33TOP 2003 SJSU --- CmpE M.E. Fayad 33 Type-Oriented Paradigm  Subtypes Topics –Subtypes Can Be Substituted for a Type –Guidelines for Subtyping –Repairing Improper Subtype Relationships –Programming to the Implementation Considered Harmful

34. L11-S34TOP 2003 SJSU --- CmpE M.E. Fayad Subtype is substitutable when it Supports the entire interface defined by the type (behavior as well as signatures Requires no more Promises no less May extend the interface by adding new operations Type/subtype hierarchy equivalent to the Inheritance tree Clients can be able to choose the interface they need 34 Subtypes Can be Substitutable for a Type

35. L11-S35TOP 2003 SJSU --- CmpE M.E. Fayad Define why a subtype is needed? Which clients need to use types/subtypes in a substitutable fashion? Define a subtype for each extended concept An extended concept is still a concept Subtypes normally extend the interface of an existing type Define a subtype for each significant modification to a type Removing requirements on client (weakening pre-conditions) Adding promises (strengthening pre-conditions) 35 Guidelines for Subtyping

36. L11-S36TOP 2003 SJSU --- CmpE M.E. Fayad No “good” solution Change specification of type Change specification of subtype Add/delete/rearrange operations Admit that there is no type/subtype relationship Modify type hierarchy 36 Repairing Improper Subtype Relationships Subtypes implemented by their own classes.

37. L11-S37TOP 2003 SJSU --- CmpE M.E. Fayad This is even more true when using object-oriented technology When you use dynamic binding You may get any one of several implementations New implementations can be added anytime The only thing all the implementations share in common is the well- specfied interface Clients are at fault because they relied on the implementation instead of the interface. Aside Developers would be at fault if they failed to specify the interface. 37 Programming to the Implementation Considered Harmful

38. L11-S38TOP 2003 SJSU --- CmpE M.E. Fayad 38 Type-Oriented Paradigm ‘Hierarchies & Inheritance Topics –Type Hierarchy –Class Hierarchy –Subtyping versus Inheritance –Summary

39. L11-S39TOP 2003 SJSU --- CmpE M.E. Fayad Interface Inheritance Substitutable Interfaces Subtyping 39 Type Hierarchy

40. L11-S40TOP 2003 SJSU --- CmpE M.E. Fayad Implementation Inheritance Inherits Bits and Code Design Artifact 40 Class Hierarchy

41. L11-S41TOP 2003 SJSU --- CmpE M.E. Fayad Two Concepts, One Language Facility Separate Hierarchies Different Number of Hierarchies 41 Subtyping Versus Inheritance

42. L11-S42TOP 2003 SJSU --- CmpE M.E. Fayad Client Programs Use the Type Hierarchy Type Hierarchy Encapsulates Design 42 Summary

43. L11-S43TOP 2003 SJSU --- CmpE M.E. Fayad 43 Type-Oriented Paradigm ’Maintenance, Modifications, and Enhancements Topics –Modifying Classes in a Substitutable Manner –Modifying a Class - Small Change –Modifying the Type - Big Change –Summary - Three Roles for Substitutability

44. L11-S44TOP 2003 SJSU --- CmpE M.E. Fayad 44 Typical Maintenance Paradigm We must throw away everything and start over!!! “Spaghetti”

45. L11-S45TOP 2003 SJSU --- CmpE M.E. Fayad Modifications include changing a class or substituting one class for another The modifications still implement the same interface as defined by the specification. //Purpose: //Parameters: //Requirements: //Promises: //Return values: //Exceptions: //Intentional vagueness: 45 Modifying Classes in a Substitutable Manner Require no more, Promise no less

46. L11-S46TOP 2003 SJSU --- CmpE M.E. Fayad Modifications must conform to type interface Modifying a class should not break client code. 46 Modifying a Class -- Small change (1) If modifying the class breaks client code, either the class is not a valid implementation of the type or you need to modify the type. Thus can have significant costs.

47. L11-S47TOP 2003 SJSU --- CmpE M.E. Fayad Substitutable Modifications 1. Implements all operations 2. No affects on client code 3. May affect classes 47 Modifying the Type -- Small Change (2)

48. L11-S48TOP 2003 SJSU --- CmpE M.E. Fayad Non-substitutable modifications Requires more and/or promises less Affects clients affects classes Becomes increasingly more expensive that later it occurs in the product life-cycle May be inexpensive for developer But it is extremely expensive when you consider the number of clients that are affected Reuse client code Due to: Poor domain analysis Improper understanding of client needs Refinement Late generalization 48 Modifying the Type -- Big Change

49. L11-S49TOP 2003 SJSU --- CmpE M.E. Fayad Between Type and Class Between Type and Revised Type Between Type and Subtype 49 Summary: Three Roles for Substitutability

50. L11-S50TOP 2003 SJSU --- CmpE M.E. Fayad 50 Type-Oriented Paradigm “Goals & Qualities Topics –Goals –Qualities –Extensibility –Composition

51. L11-S51TOP 2003 SJSU --- CmpE M.E. Fayad Better Quality Faster Development Lower Development Costs Lower Product Life-Cycle Costs Faster Modification and Enhancement 51 Goals

52. L11-S52TOP 2003 SJSU --- CmpE M.E. Fayad Good Abstractions Proper Encapsulation Understandable & Comprehensible Implementation is Flexible Extensible Reusable 52 Qualities

53. L11-S53TOP 2003 SJSU --- CmpE M.E. Fayad 53 Type-Oriented Paradigm ”Observations and Conclusions

54. L11-S54TOP 2003 SJSU --- CmpE M.E. Fayad Types are for Analysis Classes are for Design Types More Valuable Than Classes 54 Conclusions

55. L11-S55TOP 2003 SJSU --- CmpE M.E. Fayad 1. Define: types and substitutability 2. Explain the following facts: a. A type names an interface. b. A class implement a type. c. One class can be substituted for another. 3. What are the elements of an interface? Provide examples 4. What are the elements of behavior? 5. How to specify behavior? 6. Mark (T) for true or (F) for false ( ) 1. A set of all signatures defined by an object’s operations is called the interface to the object. ( ) 2. A type is a name used to denote a particular interface. ( ) 3. An object can be substituted for another if it has the same type or it is a subtype of the other object. ( ) 4. Class inheritance allows classes to be defined simply as extensions of other classes. 55 Discussion Questions (1)

56. L11-S56TOP 2003 SJSU --- CmpE M.E. Fayad 1. Define: type hierarchy, class hierarchy and subtypes 2. What are the guidelines for typing and subtyping? 3. When can subtype be substituted? 4. Explain: a. Subtypes implemented by their own classes. b. Modifying a class is a small change but modifying a type is a big change. 5. Mark (T) for true or (F) for false ( ) 1. Class inheritance allows classes to be defined simply as extensions of other classes. ( ) 2. When inheritance is used carefully, all classes derived from an abstract c lass will share the interface defined by the abstract class. ( )3. There are three ways to reuse functionality in OO systems: class inheritance, object composition, and information hiding. 56 Discussion Questions (2)

57. L11-S57TOP 2003 SJSU --- CmpE M.E. Fayad Define: –Guidelines –Heuristics What do you think of these heuristics –A designer should distribute system intelligence uniformly among the top level classes in the system. –A designer should have 4.6 top level classes per 1,000 lines of code. –Eliminate classes that are outside the system 57 Questions for the Next Lecture