Transcript COMP313A Programming Languages Object Oriented Progamming Languages (1)

COMP313A Programming
Languages
Object Oriented
Progamming Languages (1)
1
Lecture Outline
•
•
•
•
Overview
Polymorphism
Inheritance and the Type System
Polymorphism and Strong Typing
2
Overview of Object Oriented
Programming paradigm
• Pure object oriented programming
languages
– unit of modularity is an Abstract Data Type
(ADT) implementation, especially the class
– Can define new classes of objects by modifying
existing classes
– Java, Smalltalk, Eiffel, Dylan, C#
3
Overview
• Non pure object oriented programming
languages
– provide support for object oriented
programming
– not exclusively object-oriented
– C++, Ada 95, CLOS
4
Overview
• Pure terminology
– objects are instances of classes
– object has instance variables and methods
• local variables declared as part of the object
• operations which are used to modify the object
– message passing
• smalltalk s push 5
– polymorphic – can’t tell which method to invoke
until run-time
– Eiffel, C++, Java restrict polymorphism
• static type checking
5
public Class Complex
{ public Complex()
{ re = 0; im = 0; }
public Complex (double realpart, double imagpart)
{ re = realpart; im = imagpart }
public double realpart()
{ return re; }
public double imaginarypart()
{ return im; }
public Complex add ( Complex c )
{ return new Complex(re + c.realpart(),
im + c.imaginarypart());
public Complex multiply (Complex c)
{ return new
Complex(re * c.realpart() – im * c.imaginary part(),
re * c.imaginarypart() + im * c.realpart());
6
Complex z, w;
…
z = new Complex (1, 2);
w = new Complex (-1, 1);
z = z.add(w);
z = z.add(w).multiply(z);
7
Inheritance
• The subtype principal
– a “derived” class inherits all the operations
and instance variables of its base class
• derived class, sub class etc
• base class, super class, parent class etc
• Single inheritance versus Multiple
inheritance
8
furniture
chair
lounge chair
table
sofa
dining table
desk
• Relationship amongst the components
• Use of inheritance
• Sublasses versus subparts
9
closed figure
polygon
triangle
rectangle
ellipse
circle
square
• Relationship amongst the components
• Use of inheritance
• Sublasses versus subparts
10
Overview
• Two main goals of object-oriented
language paradigm are:
– restricting access to the internal
(implementation) details of data types and
their operations
– modifiability for reuse
11
The Notion of Software Reuse and
Independence
• A corollary of Data Abstraction
• Given a particular Abstract Data Type
– Extension of data and /or operations
(specialisation - subclasses)
– Redefinition of one or more of the operations
– Abstraction, or the collection of similar
operations from two different components into
a new component (multiple inheritance)
– Extension of the type that operations apply to
(polymorphism)
12
public class Queue
{ // constructors and instance variables go here
public void enqueue (int x) {…}
public void dequeue() {…}
public int front () {…}
public boolean empty() {…}
}
public class Deque extends Queue
{// constructors and instance variables go here
public void addFront ( int x {… }
public void deleteRear() {… }
}
13
Queue q;
Deque d;
d = new Deque();
q = d;
q.dequeue() and d.queue()
q.deleteRear()
OK
q = d; //a compile time error in Java
q = (Deque) d; // downcast
14
class stack{
public:
void push(int, item){elements[top++] = item;};
int pop () {return elements[--top];};
private:
int elements[100];
int top =0;
};
class counting_stack: public stack {
public:
int size(); // return number of elements on stack
stack s1, s2; // automatic variables
stack* sp = new stack;
sp->pop()
15
stack* sp = new stack;
counting_stack* csp = new counting_stack;
sp = csp; // okay
csp = sp; // statically can’t tell
Why shouldn’t csp be allowed to point to an sp object?
C++ strong type system
16
Polymorphism
• polymorphic variables could refer to objects of
different classes
– what is the problem for a type checker
• How do we allow dynamic binding and still ensure
type safety
• strong type system limits polymorphism
– restricted to objects of a class or its derived classes
– e.g. variables of type stack may refer to a variable of
type counting_stack
• Strict object-oriented languages (Smalltalk,
Eiffel, Java
– all objects accessed through references which may be
polymorphic
• C++ - pointers, reference variables and byreference parameters are polymorphic
17
If we do not use pointers we do not
get inclusion polymorphism. But…
stack s;
counting_stack cs;
s = cs; //okay coerce cs to a stack
cs = s; //not okay
18
COMP313A Programming
Languages
Object Oriented
Progamming Languages (2)
19
Lecture Outline
• The Class Hierarchy and Data Abstraction
• Polymorphism
• Polymorphism and Strong Typing
20
furniture
chair
lounge chair
table
sofa
dining table
desk
21
public class Queue
{ // constructors and instance variables go here
public void enqueue (int x) {…}
public void dequeue() {…}
public int front () {…}
public boolean empty() {…}
}
public class Deque extends Queue
{// constructors and instance variables go here
public void addFront ( int x {… }
public void deleteRear() {… }
}
Is Queue more abstract than Deque or vice versa
22
class stack{
public:
void push(int, item){elements[top++] = item;};
int pop () {return elements[--top];};
private:
int elements[100];
int top =0;
};
class counting_stack: public stack {
public:
int size(); // return number of elements on stack
stack s1, s2; // automatic variables
stack* sp = new stack;
sp->pop()
23
stack* sp = new stack;
counting_stack* csp = new counting_stack;
sp = csp; // okay
csp = sp; // statically can’t tell
Why shouldn’t csp be allowed to point to an sp object?
C++ strong type system
24
Polymorphism
• polymorphic variables could refer to objects of
different classes
– what is the problem for a type checker
• How do we allow dynamic binding and still ensure
type safety
• strong type system limits polymorphism
– restricted to objects of a class or its derived classes
– e.g. variables of type stack may refer to a variable of
type counting_stack
• Strict object-oriented languages (Smalltalk,
Eiffel, Java
– all objects accessed through references which may be
polymorphic
• C++ - pointers, reference variables and byreference parameters are polymorphic
25
If we do not use pointers we do not
get inclusion polymorphism. But…
stack s;
counting_stack cs;
s = cs; //okay coerce cs to a stack
cs = s; //not okay
26
The Type System
• The subtype principle
type day
= (Sunday, Monday, Tuesday, Wednesday,
Thursday, Friday, Saturday);
weekday = (Monday..Friday);
• a week day is also a day
– is-a relationship
• similarly class and sub-class
– counting_stack is-a stack
• but….
27
The Type System
• need to state the conditions under which the isa
relationship holds for subclasses of classes
because…
• subclasses can hide the variables and functions
or modify them in an incompatible way
• need to know when they are equivalent with the
parent’s definition
28
COMP313A Programming
Languages
Object Oriented
Progamming Languages (3)
29
Lecture Outline
• Polymorphism and Strong Typing
30
Polymorphism
• polymorphic variables could refer to objects of
different classes
– what is the problem for a type checker
• How do we allow dynamic binding and still ensure
type safety
• strong type system limits polymorphism
– restricted to objects of a class or its derived classes
– e.g. variables of type stack may refer to a variable of
type counting_stack
• Strict object-oriented languages (Smalltalk,
Eiffel, Java
– all objects accessed through references which may be
polymorphic
• C++ - pointers, reference variables and byreference parameters are polymorphic
31
If we do not use pointers we do not
get inclusion polymorphism. But…
stack s;
counting_stack cs;
s = cs; //okay coerce cs to a stack
cs = s; //not okay
32
The Type System
• The subtype principle
type day
= (Sunday, Monday, Tuesday, Wednesday,
Thursday, Friday, Saturday);
weekday = (Monday..Friday);
• a week day is also a day
– is-a relationship
• similarly class and sub-class
– counting_stack is-a stack
• but….
33
The Type System
• need to state the conditions under which the isa
relationship holds for subclasses of classes
because…
• subclasses can hide the variables and functions
or modify them in an incompatible way
• need to know when they are equivalent with the
parent’s definition
34
Dynamic Binding of Calls to Member
Functions
• a derived class can override a member
function of the parent class
stack* sp = new stack;
counting_stack* csp = new counting_stack;
sp->push(…); //stack::push
csp->push(…); //counting_stack::push
sp = csp; //okay
sp -> push(…) //which push?
dynamic or static binding
35
Type System
• behavioural equivalence
• base::f(x) maybe replaced with
derived::f(x) without risking any type
errors
• identical signatures
36
Polymorphism – Strong Typing
• Strong typing means that
How can we have dynamic binding and a
strong type system
stack* sp = new stack;
counting_stack* csp = new counting_stack;
sp = csp; //allowed
csp = sp; //not allowed
37
Polymorphism – Strong Typing
the general case:
class base {…};
class derived: public base {…};
…
base* b;
derived* d;
b = d; //allowed
d = b; //not allowed
The question of substitutability - ensuring is-a
Can we substitute d for b always?
Is this kind of polymorphism compatible with strong typing?
38
Polymorphism – Strong Typing
•
Substitutability
– impose some restrictions on the use of
inheritance
1. Type extension
– the derived class can only extend the type of base
class
– can’t modify or hide any member variables or
functions
– Ada 95
– problem is it rules out dynamic binding (dynamic
dispatch) completely
39
Polymorphism – Strong Typing
2. Overriding of member functions
class polygon{
public:
polygon (..){…} //constructor
virtual float perimeter () {…};
};
class square : public polygon {
public:
square (..) {…} //constructor
…
float perimeter() {…}; //overrides the definition of
//perimeter in polygon
40
Polymorphism – Strong Typing
• under what conditions is it possible for a use of a
square object to substitute the use of a polygon
object,
i.e. p-> perimeter() will be valid whether *p is a
polygon or a square object
C++ the signature of the overriding function must
be identical to that of the overridden function
- exactly the same parameter requirements
no type violations
What happens at runtime?
41
Polymorphism – Strong Typing
• Is it possible to relax this last restriction even
further but still ensuring type safety?
• The input parameters of the overriding function
must be supertypes of the corresponding
parameters of the overriden function
contravariance rule
• The result parameter of the overriding function
must be a subtype of the result parameter of the
overriden function covariance rule
42
//not C++ input parameters
class base {
public:
void virtual fnc (s1 par) {..}
// S1 is the type of the formal
// parameter
}
class derived: public base {
public:
void fnc (s2 par) {…}
// C++ requires that s1 is identical to
// S2
}
base* b
derived* d
s1 v1;
s2 v2;
if (..) b = d;
b-> fnc(v1);
//okay if b is base but what if it is
//derived
43
//not C++ result parameter
class base {
public:
t1 virtual fnc (s1 par) {…}; // s1 is the type of formal parameter
// t1 is the type of result parameter
};
class derived: public base {
public:
t2 fnc (s2 par) {…};
// C++ requires that s1 is identical to
// s2 and t1 is identical to t2
};
base* b;
derived* d;
s1 v1;
s2 v2;
t1 v0;
if (…) b = d;
v0 = b->fnc(v1);
// okay if b is base but what if it is derived
44
Polymorphism – Strong Typing
• Who uses it?
• Emerald uses both contravariance and
covariance
• C++, Java, Object Pascal and Modula-3
use neither
– use exact identity
• Eiffel and Ada require covariance of both
input and result parameters
45
Issues in Inheritance Hierarchies
• Ada, Java and Smalltalk have a single
inheritance model
• Java has separate interfaces and supports the
idea of inheriting from multiple interfaces
• C++ and Eiffel have multiple inheritance
class circus_elephant: public elephant, circus_performer
• What if both elephant and circus_performer have
a member function ‘trunk_wag’
• Diamond inheritance
46
root
child2
child1
grandchild
47
Implementation and interface
inheritance
• object oriented programming new software
components may be constructed from existing
software components
• inheritance complicates the issue of
encapsulation
• interface inheritance  derived class can only
access the parent class through the public
interface
• implementation inheritance  derived class can
access the private internal representation of the
parent class
48
Protected Members
class stack{
public:
void push(int, i){elements[top++] = I;};
int pop () {return elements[--top];};
private:
int elements[100];
int top =0;
};
class counting_stack: public stack {
public:
int size(); //return number of elements on stack
stack s1, s2;
stack* sp = new stack;
sp->pop()
49
Protected Members
• implementation inheritance versus interface
inheritance
class stack{
public:
void push(int, i){elements[top++] = I;};
int pop () {return elements[--top];};
protected
int top = 0;
private:
int elements[100];
};
class counting_stack: public stack {
public:
int size(){return top;}; //return number of elements on stack
• protected entities are visible within the class and
any derived classes
50
Protected Members
class C {
public:
// accessible to everyone
protected:
// accessible to members and friends and
// to members and friends of derived classes only
private:
//accessible to members and friends only
};
51
Friends
class Matrix;
class Vector {
float v[4];
friend Vector operator* (const Matrix&, const Vector&);
};
class Matrix {
Vector v[4];
friend Vector operator* (const Matrix&, const Vector&);
}
52
Vector operator* (const Matrix& m, const Vector& v)
{
Vector r;
for (int i = 0; i < 4; i++) {
r.v[i] = 0;
for (int j = 0; j ,4; j++)
r.v[i] += m.v[i].v[j] * v.v[j];
}
return r;
}
53