polymorphism and inheritance
Post on 03-Jan-2016
52 Views
Preview:
DESCRIPTION
TRANSCRIPT
Polymorphism and Inheritance
(CS-319 Supplementary Notes)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 2/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 3/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)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 4/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 5/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 6/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 7/45
An Example Inheritance Hierarchy
Account
MortgageAccountSavingsAccount ChequingAccount
Superclasses• Contain features common to a set of subclasses
Inheritance (automatic)• The implicit possession by all subclasses of features
defined in its superclasses
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 8/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!
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 9/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 10/45
A possible inheritance hierarchy of mathematical objects
Rectangle
QuadrilateralCircle
Ellipse Polygon PlaneLine
Shape3DShape2D
MatrixShape Point
MathematicalObject
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 11/45
Make Sure all Inherited Features Make Sense in Subclasses
Account
balanceopenedcreditOrOverdraftLimit
creditdebitcalculateInterest
MortgageAccount
collateralPropertycollateralValue
setCollateralValue
ChequingAccount
highestChequeNumber
withdrawUsingChequecalculateServiceCharge
SavingsAccount
attributes
Operations/methods
Inherited features not shown explicitly!
Textual Representation:
AccountSavingsAccountCheckingAccountMortgageAccount
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 12/45
2.6 Inheritance, Polymorphism and Variables
RegularPolygon
numPointsradius
changeNumPointschangeScalegetAreagetPerimeterLengthgetVertices
Rectangle
heightwidth
setHeightsetWidth
changeScale
getAreagetPerimeterLengthgetVerticesgetBoundingRect
ArbitraryPolygon
points
addPointremovePointrotatechangeScalegetAreagetPerimeterLengthgetVertices
SimplePolygon
orientation
rotate
Shape2D
rotate
translate
changeScalegetAreagetPerimeterLength
getCenter
getBoundingRect
Ellipse
getSemiMajorAxisgetSemiMinorAxis
rotate
getAreagetPerimeterLength
getOrientationgetBoundingRect
Circle
rotate
getAreagetPerimeterLengthgetBoundingRect
Polygon
getVerticesgetBoundingRect
EllipticalShape
semiMajorAxis
semiMinorAxis
changeScale
changeScale
getRadius
getFocus1getFocus2
orientation
getOrientation
center
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 13/45
Some Operations in the Shape Example
Original objects(showing bounding rectangle)
Rotated objects(showing bounding rectangle)
Translated objects(showing original)
Scaled objects(50%)
Scaled objects(150%)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 14/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 15/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 16/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 17/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.
ExamplesShape2D | RegularPolygon | Rectangle aShape; aShape.getBoundingRect();
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 18/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
User-Centered Design
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 20/45
User Centred Design (UCD)
Software development should focus on the needs of users
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 21/45
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 22/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 23/45
Example of generalization, extension and inclusion
Open file by typing name
Open file by browsing
Open file
System Administrator
Browse for file
Ordinary User
Attempt to open file that does not exist
«extend» «include»
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 24/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 25/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 26/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 27/45
Example of generalization, extension and inclusion
Open file by typing name
Open file by browsing
Open file
System Administrator
Browse for file
Ordinary User
Attempt to open file that does not exist
«extend» «include»
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 28/45
Example description of a use case
Use case: Open file Related use cases: Generalization of: • Open file by typing name • Open file by browsing Steps:
Actor actions System responses 1. Choose ‘Open…’ command 2. File open dialog appears 3. Specify filename 4. Confirm selection 5. Dialog disappears
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 29/45
Use case: Open file by typing name Related use cases: Specialization of: Open file Steps:
Actor actions System responses 1. Choose ‘Open…’ command 2. File open dialog appears 3a. Select text field 3b. Type file name 4. Click ‘Open’ 5. Dialog disappears
Example (continued)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 30/45
Use case: Open file by browsing Related use cases: Specialization of: Open file Includes: Browse for file Steps:
Actor actions System responses 1. Choose ‘Open…’ command 2. File open dialog appears 3. Browse for file 4. Confirm selection 5. Dialog disappears
Example (continued)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 31/45
Use case: Attempt to open file that does not exist Related use cases: Extension of: Open file by typing name
Actor actions System responses 1. Choose ‘Open…’ command 2. File open dialog appears 3a. Select text field 3b. Type file name 4. Click ‘Open’ 5. System indicates that file
does not exist 6. Correct the file name 7. Click ‘Open’ 8 Dialog disappears
Example (continued)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 32/45
Use case: Browse for file (inclusion)
Steps:Actor actions System responses1. If the desired file is not displayed,
select a directory
2. Contents of directory is
displayed3. Repeat step 1 until the desired file isdisplayed4. Select a file
Example (continued)
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 33/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
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 34/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 35/45
The process ...
1 Domain analysis2 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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 36/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).
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 37/45
Aspects of usability
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 38/45
Different learning curves
It is common to describe learnibility in terms of learning curves.
0
20
40
60
80
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days of learning
Complexsystem,hard tolearn
Simplesystem,easy tolearn
Simplesystem,hard tolearn
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 39/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.
© Lethbridge/Laganière 2001 Chapter 2: Review of Object Orientation 40/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
top related