Transcript Advanced Object Oriented Systems

1
Advanced Object Oriented
Systems
(CM0318)
Lecture 4
(Last modified 13th February 2001)
2
What’s the point of OO?
We are trying to build (large) systems that are:
• relatively easy to implement
• reliable
• maintainable
• extensible
• of satisfactory performance
• ...
3
2 distinct philosophies
• The ‘hacker’ philosophy
– (let’s just tweak a few classes and hope it all
works!)
• The ‘methodologies’ philosophy
– (good software doesn’t just happen: it requires
discipline!)
4
Smalltalk philosophy (Ingalls)
–
–
–
–
System entirely comprehensible to individual
minimum set of unchangeable, v. general parts
uniform framework
Do programs look like they are doing what they
are doing?? (cf. Design by Contract)
– Everything-is-an-object
– An operating system is a collection of things
that don’t fit into a language. There shouldn’t
be one
5
Methodologists (Booch)
Functional Decomposition is limiting:
Cruise
Control
System
Get
Desired
Speed
Get
Current
Speed
.....
Put
Throttle
Value
6
OO Decomposition
Wheel
Driver
Brake
Curr. speed
Throttle
Engine
Accelerator
7
OO Development steps (Booch)
• Identify the objects and their attributes
• Identify operations undergone by &
required of each object
• Establish visibility of each object in relation
to others
• Establish interface of each object
• Implement each object
8
Some issues
• How to approach the problem (life-cycle)
• How to document & think about the domain
and the design
• How to implement the software designed
• Tools to support the programmer, designer,
etc.
• To what extent does the chosen
programming language support these
concepts?
9
Our approach
• Extend our knowledge of OO languages,
discussing a few specific design principles
• Then learn how a programming
environment supports rapid prototyping in
Smalltalk (using SQUEAK)
• Then survey the principles of
methodologies, design notations etc.
10
But first ...
• An important design principle that most
programming languages don’t fully enforce:
type safety.
11
Type safety and Co/Contravariance
Class 1
Class 2
foo(arg1:type1, ...,
argn:typen): type0
foo(arg1:type1’, ...,
argn:typen’): type0’
12
Requirements for type safety
• For foo in Class2 to be able to take all
arguments of foo in Class1, type1’ … typen’
must all be the same as, or superclasses of,
type1 … typen
• For the return argument of foo in Class2 to
be useable, its class type0’ must be either the
same class, or a subclass of, type0
13
Put another way ...
• Covariance: a relation between an
operation overridden in a subclass and the
original operation in which the type of each
argument remains unchanged or becomes
specialised
• Contravariance: a relation between an
operation overridden in a subclass and the
original operation in which the type of each
argument either remains unchanged or
becomes generalised
14
For type safety ...
• There must be contra-variance of
parameters of an operation
• There must be co-variance of the return
parameters of an operation
15
Generally OO languages don’t
support this
• Consider the attached Java programs (Test0 &
Test1). Results are
E:\Lect99-00\ADVOOA\Lect 4>java Test0
Test0 version for Test0 parameter
Test1 version
Test1 version
Test1 version
Test0 version for Test0 parameter
Test0 version for Test1 parameter
Test0 version for Test0 parameter
Test1 version
Test1 version
Exception in thread "main" java.lang.ClassCastException: Test0
at Test0.main(Test0.java:20)
16
Explanation
• Can have multiple signatures for a single
method in Java. This is method overloading.
• In contrast to method overriding (where
choice of methods with same signature is
determined dynamically at run-time, on the
class of the object receiving a message),
method overloading is done statically.
17
Method overloading rules
• Only methods defined in the declared
class/interface of a variable and its
superclasses/superinterfaces are considered
• Only methods with same no. of parameters
as the calling message are considered
• Informally, one method declaration is more
specific than another if any invocation
handled by the first method could be passed
on to the other one. The most specific
method is chosen.
18
Method overloading (ctd.)
• Let m be a name and suppose there are 2
declarations of methods named m, each
having n parameters. Then ...
19
Method overloading (ctd.)
• Suppose one declaration appears within a class or
interface T and that the types of the parameters are
T1, . . . , Tn; suppose the other declaration appears
within a class or interface U and the types of the
parameters are U1, . . . , Un. Method m declared in
T is more specific than method m declared in U if
and only if both:
– T can be converted to U by method invocation
conversion (i.e. a “T” can be validly used where a “U”
has been declared, because U is, e.g., a superclass of T).
– Tj can be converted to Uj by method invocation
conversion, for all j from 1 to n.
20
Method overloading (ctd.)
• A method is said to be maximally specific for a
method invocation if it is applicable and
accessible and there is no other applicable and
accessible method that is more specific.
• If there is only one maximally specific method
for a given method invocation, it is called the
most specific method
• If a most specific method cannot be found, there
is ambiguity and the compiler reports an error.
(There are a few esoteric exceptions to this last
rule)
21
Type casting
• Note that you can compile code that casts to
a more specialised type (needed, e.g., to
process objects retrieved from collections as
anything other than Objects)
• But whether this is admissible is determined
at run-time.
22
Lessons
• In a way you can have co-/contra- variance
in Java, by using multiple signatures.
• In fact, co-variance of all parameters
(including return parameters) is a Good
Thing (because, e.g., in an MVC-style
framework, more specialised ‘views’ should
work with more specialised ‘controllers’)
• But beware: it’s your responsibility to make
sure that your code doesn’t have nasty runtime type violations!
23
Lessons (ctd.)
• Method overloading for different numbers
of parameters is fairly harmless (e.g.
consider the various constructors for
Vector)
• Method overloading where there are two
distinct method signatures for the same
number of parameters has to be done
sparingly, and with great care
• Perhaps Java’s type system isn’t so good
after all!
24
Some background reading
• To understand the topics in this lecture, and to
prepare for the survey of OO languages in the next
couple of lectures, you may wish to skim the first 3
chapters of Bouzeghoub et al
• The Java language specification, in all its glory, is
available at:
http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html