1. Polymorphism and Inheritance (CS-319 Supplementary Notes)

2. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation2/45 Class variables A class variable’s value is shared by all instances of a class. Also called a static variable If one instance sets the value of a class variable, then all the other instances see the same changed value. Class variables are useful for: —Default or ‘constant’ values (e.g. PI) —Lookup tables and similar structures Caution: do not over-use class variables

3. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation3/45 2.4 Methods, Operations and Polymorphism Method A procedural abstraction used to implement the behaviour of a class. Operation A higher-level procedural abstraction that specifies a type of behaviour Independent of any code which implements that behaviour —E.g., calculating area (in general)

4. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation4/45 Methods, Operations and Polymorphism Several different classes can have methods with the same name —They implement the same abstract operation in ways suitable to each class —E.g, calculating area in a rectangle is done differently from in a circle Method (n): A way of performing an operation.

5. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation5/45 Polymorphism A property of object oriented software by which an abstract operation may be performed in different ways in different classes. Requires that there be multiple methods of the same name The choice of which one to execute depends on the object that is in a variable Reduces the need for programmers to code many if-else or switch statements See Banking System Application: calculate Interest

6. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation6/45 Organizing Classes into Inheritance Hierarchies Motivation: Organizing into inheritance hierarchies is more efficient if several classes have common attributes, associations, and operations or if a class is too complex. Generaralization is a two-level hierarchy formed from one superclass with several immediate subclasses. — A triangle shows a generalization. Superclasses Contain features common to a set of subclasses Inheritance Hierarchy is a hierarchy with multiple levels of generalization. —Show the relationships among superclasses and subclasses

7. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation7/45 An Example Inheritance Hierarchy Superclasses Contain features common to a set of subclasses Inheritance (automatic) The implicit possession by all subclasses of features defined in its superclasses

8. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation8/45 The Isa Rule Organizing classes into class hierarchies is a key skill in OO design and programming. Always check generalizations to ensure they obey the isa rule “A checking account is an account” Should ‘Province’ be a subclass of ‘Country’? No, it violates the isa rule —“A province is a country” is invalid!

9. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation9/45 Other Key Points Not all classes where isa rule holds are good generalizations. You should also check: Class names should not be ambiguous. A subclass must retain its distinctiveness throughout its life. E.g., OverdrawnAccount All the inherited features must make sense in each subclass. Key point: Generalizations and Inheritance help to avoid duplication and improve reuse. But poorly designed generalizations can actually cause more problems than they solve.

10. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation10/45 A possible inheritance hierarchy of mathematical objects

11. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation11/45 Make Sure all Inherited Features Make Sense in Subclasses attributes Operations/methods Inherited features not shown explicitly! Textual Representation: Account SavingsAccount CheckingAccount MortgageAccount

12. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation12/45 2.6 Inheritance, Polymorphism and Variables

13. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation13/45 Some Operations in the Shape Example

14. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation14/45 Examples Definitions of rotate, translate, changeScale Definitions of Ellipse, RegularPolygon, ArbitraryPolygon Definitions of getCenter, getArea, getPerimeterLength, getBoundingRect Concrete methods for rotate abstract operation in Shape2D? Four abstract classes: Shape2D, EllipticalShape, Polygon, SimplePolygon Concrete methods for abstract operations defined in Shape2D ? SimplePolygon is an abstract class although all its methods are concrete? Polygon declares getVertices Concrete getBoundingRect calls abstract operation getVertices in Polygon

15. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation15/45 Abstract Classes and Methods An operation should be declared to exist at the highest class in the hierarchy where it makes sense The operation may be abstract (lacking implementation) at that level If so, the class also must be abstract —No instances can be created —The opposite of an abstract class is a concrete class If a superclass has an abstract operation then its subclasses at some level must have a concrete method for the operation —Leaf classes must have or inherit concrete methods for all operations —Leaf classes must be concrete Calling of an abstract operation by a concrete method is legal and a good design practice.

16. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation16/45 Overriding A method would be inherited, but a subclass contains a new version instead For restriction ( e.g.,preventing violation of certain constraints present in subclass ) —E.g. changeScale(x,y) would not work in Circle For extension ( e.g., adding extra capability ) —E.g. SavingsAccount might charge an extra fee following every debit For optimization ( e.g., making impl more efficient ) —E.g. The getPerimeterLength method in Circle is much simpler than the one in Ellipse

17. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation17/45 Dynamic binding (Late binding) Occurs when decision about which method to run can only be made at run time Needed when: —A variable is declared to have a superclass as its type, and —There is more than one possible polymorphic method that could be run among the type of the variable and its subclasses Dynamic binding is what gives polymorphism its power. — No conditional statements are needed. Examples Shape2D | RegularPolygon | Rectangle aShape; aShape.getBoundingRect();

18. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation18/45 How a decision is made about which method to run 1.If there is a concrete method for the operation in the current class, run that method. 2.Otherwise, check in the immediate superclass to see if there is a method there; if so, run it. 3.Repeat step 2, looking in successively higher superclasses until a concrete method is found and run. 4.If no method is found, then there is an error In Java and C++ the program would not have compiled

19. User-Centered Design

20. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation20/45 User Centred Design (UCD) Software development should focus on the needs of users

21. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation21/45

22. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation22/45 Scenarios A scenario is an instance of a use case It expresses a specific occurrence of the use case —a specific actor... —at a specific time... —with specific data.

23. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation23/45 Example of generalization, extension and inclusion

24. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation24/45 Extensions Used to make optional interactions explicit or to handle exceptional cases. By creating separate use case extensions, the description of the basic use case remains simple. A use case extension must list all the steps from the beginning of the use case to the end. —Including the handling of the unusual situation.

25. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation25/45 Generalizations Much like superclasses in a class diagram. A generalized use case represents several similar use cases. One or more specializations provides details of the similar use cases.

26. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation26/45 Inclusions Allow one to express commonality between several different use cases. Are included in other use cases —Even very different use cases can share sequence of actions. —Enable you to avoid repeating details in multiple use cases. Represent the performing of a lower-level task with a lower-level goal.

27. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation27/45 Example of generalization, extension and inclusion

28. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation28/45 Example description of a use case

29. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation29/45 Example (continued)

30. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation30/45 Example (continued)

31. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation31/45 Example (continued)

32. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation32/45 Example (continued)

33. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation33/45 The modeling processes: Choosing use cases on which to focus Often one use case (or a very small number) can be identified as central to the system —The entire system can be built around this particular use case There are other reasons for focusing on particular use cases: —Some use cases will represent a high risk because for some reason their implementation is problematic —Some use cases will have high political or commercial value

34. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation34/45 Basics of User Interface Design In today’s world, the user interface is often the most complex part of the system to design. It can take over half of all development effort and is the part that is most likely to cause users to perceive a lack of quality.

35. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation35/45 The process... 1 Domain analysis 2 Define the problem (first attempt) 3 Use case analysis —define the tasks that the UI must help the user perform 4 User interface prototyping (iterative) —Address the use cases —Dıscuss with and evaluate by users and ui designers —Refine the use cases and user interface Results of prototyping will enable you to finalize the requirements.

36. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation36/45 Usability vs. Utility The overall usefulness of a software system can be considered on two quality dimensions: Does the system provide the raw capabilities to allow the user to achieve their goal? This is utility. Does the system allow the user to learn and to use the raw capabilities easily? This is usability. Both utility and usability are essential They must be measured in the context of particular types of users (e.g., particular actors).

37. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation37/45 Aspects of usability

38. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation38/45 Different learning curves It is common to describe learnibility in terms of learning curves.

39. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation39/45 Some basic terminology of user interface design Dialog (Box): A specific window with which a user can interact, but which is not the main UI window. Control or Widget: Specific components of a user interface. e.g., menus, lists, input fields, and scroll bars. Affordance: The set of operations that the user can do at any given point in time. State: At any stage in the dialog, the system is displaying certain information in certain widgets, and has a certain affordance. Mode: A situation in which the UI restricts what the user can do. Modal dialog: A dialog in which the system is in a very restrictive mode. Feedback: The response from the system whenever the user does something, is called feedback. Encoding techniques. Ways of encoding information so as to communicate it to the user.

40. © Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation40/45 Some encoding techniques Text and fonts Icons Photographs Diagrams and abstract graphics Colours Grouping and bordering Spoken words Music Other sounds Animations and video Flashing