Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 229 times |
Download: | 0 times |
1
COMP313A Programming Languages
Object Oriented Progamming Languages (1)
2
Lecture Outline
• Overview• Polymorphism• Inheritance and the Type System• Polymorphism and Strong Typing
3
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#
4
Overview
• Non pure object oriented programming languages – provide support for object oriented
programming– not exclusively object-oriented– C++, Ada 95, CLOS
5
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
6
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());
7
Complex z, w;
…z = new Complex (1, 2);w = new Complex (-1, 1);
z = z.add(w);z = z.add(w).multiply(z);
8
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
9
• Relationship amongst the components• Use of inheritance• Sublasses versus subparts
furniture
chair table
lounge chair sofa dining table desk
10
• Relationship amongst the components• Use of inheritance• Sublasses versus subparts
closed figure
polygon ellipse
triangle rectangle circle
square
11
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
12
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)
13
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() {… }
}
14
Queue q;Deque d;
d = new Deque();
q = d;
q.dequeue() and d.queue() OKq.deleteRear()
q = d; //a compile time error in Java
q = (Deque) d; // downcast
15
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()
16
stack* sp = new stack;counting_stack* csp = new counting_stack;
sp = csp; // okay
csp = sp; // statically can’t tell
C++ strong type system
Why shouldn’t csp be allowed to point to an sp object?
17
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 by-
reference parameters are polymorphic
18
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
19
COMP313A Programming Languages
Object Oriented Progamming Languages (2)
20
Lecture Outline
• The Class Hierarchy and Data Abstraction
• Polymorphism• Polymorphism and Strong Typing
21
furniture
chair table
lounge chair sofa dining table desk
22
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
23
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()
24
stack* sp = new stack;counting_stack* csp = new counting_stack;
sp = csp; // okay
csp = sp; // statically can’t tell
C++ strong type system
Why shouldn’t csp be allowed to point to an sp object?
25
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 by-
reference parameters are polymorphic
26
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
27
The Type System
• The subtype principle
• a week day is also a day – is-a relationship
• similarly class and sub-class– counting_stack is-a stack
• but….
type day = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); weekday = (Monday..Friday);
28
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
29
COMP313A Programming Languages
Object Oriented Progamming Languages (3)
30
Lecture Outline
• Polymorphism and Strong Typing
31
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 by-
reference parameters are polymorphic
32
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
33
The Type System
• The subtype principle
• a week day is also a day – is-a relationship
• similarly class and sub-class– counting_stack is-a stack
• but….
type day = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); weekday = (Monday..Friday);
34
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
35
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::pushcsp->push(…); //counting_stack::push
sp = csp; //okay
sp -> push(…) //which push?
dynamic or static binding
36
Type System
• behavioural equivalence
• base::f(x) maybe replaced with derived::f(x) without risking any type errors
• identical signatures
37
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
38
Polymorphism – Strong Typing
the general case:
class base {…};class derived: public base {…};
…
base* b;derived* d;
b = d; //allowedd = b; //not allowed
The question of substitutability - ensuring is-aCan we substitute d for b always?Is this kind of polymorphism compatible with strong typing?
39
• 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
Polymorphism – Strong Typing
40
2. Overriding of member functions
Polymorphism – Strong Typing
class polygon{ public: polygon (..){…} //constructor virtual float perimeter () {…};};class square : public polygon { public: square (..) {…} //constructor … float perimeter() {…}; //overrides the definition of //perimeter in polygon
41
• 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?
Polymorphism – Strong Typing
42
• 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
Polymorphism – Strong Typing
43
//not C++ input parametersclass 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* bderived* ds1 v1;s2 v2;
if (..) b = d;
b-> fnc(v1); //okay if b is base but what if it is //derived
44
//not C++ result parameterclass 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
45
• 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
Polymorphism – Strong Typing
46
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
• What if both elephant and circus_performer have a member function ‘trunk_wag’
• Diamond inheritance
class circus_elephant: public elephant, circus_performer
47
root
child1 child2
grandchild
48
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
49
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()
50
Protected Members• implementation inheritance versus interface
inheritance
• protected entities are visible within the class and any derived classes
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
51
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};
52
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&);}
53
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;}