Principles of Programming Languages Paradigms: …arusoaie.andrei/lectures/PLP/...Object-Oriented...
Transcript of Principles of Programming Languages Paradigms: …arusoaie.andrei/lectures/PLP/...Object-Oriented...
Principles of Programming LanguagesParadigms: Object Oriented Programming.
Andrei Arusoaie1
1Department of Computer Science
December 19, 2019
Outline
Paradigms
Object-Oriented Programming
Conclusion
Outline
Paradigms
Object-Oriented Programming
Conclusion
Outline
Paradigms
Object-Oriented Programming
Conclusion
Paradigms
I Imperative Programming:
I Object Oriented ProgrammingI Declarative programming
I Functional ProgrammingI Logic Programming
Paradigms
I Imperative Programming:I Object Oriented Programming
I Declarative programmingI Functional ProgrammingI Logic Programming
Paradigms
I Imperative Programming:I Object Oriented ProgrammingI Declarative programming
I Functional Programming
I Logic Programming
Paradigms
I Imperative Programming:I Object Oriented ProgrammingI Declarative programming
I Functional ProgrammingI Logic Programming
Object-Oriented Programming: Motivation-1
I Complex software
I NATO conference, 1968: software crisis1. User dissatisfaction with the final product2. cost overruns3. buggy software4. brittle software
Object-Oriented Programming: Motivation-1
I Complex softwareI NATO conference, 1968: software crisis
1. User dissatisfaction with the final product
2. cost overruns3. buggy software4. brittle software
Object-Oriented Programming: Motivation-1
I Complex softwareI NATO conference, 1968: software crisis
1. User dissatisfaction with the final product2. cost overruns
3. buggy software4. brittle software
Object-Oriented Programming: Motivation-1
I Complex softwareI NATO conference, 1968: software crisis
1. User dissatisfaction with the final product2. cost overruns3. buggy software
4. brittle software
Object-Oriented Programming: Motivation-1
I Complex softwareI NATO conference, 1968: software crisis
1. User dissatisfaction with the final product2. cost overruns3. buggy software4. brittle software
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .
I Constraints: time and space complexityI Memory management (garbage collection and address
spaces)I ConcurrencyI Event-driven interfaces
How to fix all these?
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .I Constraints: time and space complexity
I Memory management (garbage collection and addressspaces)
I ConcurrencyI Event-driven interfaces
How to fix all these?
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .I Constraints: time and space complexityI Memory management (garbage collection and address
spaces)
I ConcurrencyI Event-driven interfaces
How to fix all these?
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .I Constraints: time and space complexityI Memory management (garbage collection and address
spaces)I Concurrency
I Event-driven interfaces
How to fix all these?
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .I Constraints: time and space complexityI Memory management (garbage collection and address
spaces)I ConcurrencyI Event-driven interfaces
How to fix all these?
Motivation-2
Main issues in large software projects:I Names: functions, variables, . . .I Constraints: time and space complexityI Memory management (garbage collection and address
spaces)I ConcurrencyI Event-driven interfaces
How to fix all these?
How to fix all these?
I Extreme discipline
(hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems2. working in teams3. code modularity4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)
I Or a new paradigm that facilitates:1. solving very complex problems2. working in teams3. code modularity4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems2. working in teams3. code modularity4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems
2. working in teams3. code modularity4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems2. working in teams
3. code modularity4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems2. working in teams3. code modularity
4. easy development and code maintenance
How to fix all these?
I Extreme discipline (hard to get when working in teams)I Or a new paradigm that facilitates:
1. solving very complex problems2. working in teams3. code modularity4. easy development and code maintenance
Object-Oriented Programming
A bunch of concepts:
I Classes, objects, members (attributes + methods), accessmodifiers
I Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiers
I Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructors
I Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowing
I Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hidding
I AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI Abstraction
I InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI Inheritance
I PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI Polymorphism
I Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)
I Interfaces, abstract classes
Object-Oriented Programming
A bunch of concepts:I Classes, objects, members (attributes + methods), access
modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes
Classes vs. Objects
I Class =
a specification used to construct objectsI Classes establish the name of the class, the data method
members with types and signature, visibility andimplementation.
I Object = an instance of a class; it has a state where itsdata members (or attributes or properties) – described inthe corresponding class – have values
Classes vs. Objects
I Class = a specification used to construct objects
I Classes establish the name of the class, the data methodmembers with types and signature, visibility andimplementation.
I Object = an instance of a class; it has a state where itsdata members (or attributes or properties) – described inthe corresponding class – have values
Classes vs. Objects
I Class = a specification used to construct objectsI Classes establish the name of the class, the data method
members with types and signature, visibility andimplementation.
I Object = an instance of a class; it has a state where itsdata members (or attributes or properties) – described inthe corresponding class – have values
Classes vs. Objects
I Class = a specification used to construct objectsI Classes establish the name of the class, the data method
members with types and signature, visibility andimplementation.
I Object =
an instance of a class; it has a state where itsdata members (or attributes or properties) – described inthe corresponding class – have values
Classes vs. Objects
I Class = a specification used to construct objectsI Classes establish the name of the class, the data method
members with types and signature, visibility andimplementation.
I Object = an instance of a class; it has a state where itsdata members (or attributes or properties) – described inthe corresponding class – have values
Constructors and Destructors
I Constructor
: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor
: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the object
I Garbage Collector: automatic memory management(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector
: automatic memory management(efficient memory allocation, automatically frees thememory, enables memory reuse)
Constructors and Destructors
I Constructor: a special “method” which has the same nameas the class and no return type
I When an object is created the constructor is called:allocate the necessary memory, initialise members (do notforget inheritance)
I Typically (in many OO programming languages) we usethe new keyword to call the constructor
I Destructor: frees the memory occupied by the objectI Garbage Collector: automatic memory management
(efficient memory allocation, automatically frees thememory, enables memory reuse)
Encapsulation
I Encapsulation
: organise the data and operations (over thatdata) in a single unit
I Advantage: manipulate the objects in an uniform andconsistent way using methods
I Information hidding: separate the interface (i.e., the publicinformation in a class) from the implementation
I Access modifiers: used to restrict/grant access to object’sdata
Encapsulation
I Encapsulation: organise the data and operations (over thatdata) in a single unit
I Advantage: manipulate the objects in an uniform andconsistent way using methods
I Information hidding: separate the interface (i.e., the publicinformation in a class) from the implementation
I Access modifiers: used to restrict/grant access to object’sdata
Encapsulation
I Encapsulation: organise the data and operations (over thatdata) in a single unit
I Advantage: manipulate the objects in an uniform andconsistent way using methods
I Information hidding: separate the interface (i.e., the publicinformation in a class) from the implementation
I Access modifiers: used to restrict/grant access to object’sdata
Encapsulation
I Encapsulation: organise the data and operations (over thatdata) in a single unit
I Advantage: manipulate the objects in an uniform andconsistent way using methods
I Information hidding: separate the interface (i.e., the publicinformation in a class) from the implementation
I Access modifiers: used to restrict/grant access to object’sdata
Encapsulation
I Encapsulation: organise the data and operations (over thatdata) in a single unit
I Advantage: manipulate the objects in an uniform andconsistent way using methods
I Information hidding: separate the interface (i.e., the publicinformation in a class) from the implementation
I Access modifiers: used to restrict/grant access to object’sdata
Abstraction
I It comes in the same “package” with Encapsulation
I Example: driving a car doesn’t require knowing theinternals of the combustion engine
I Abstraction: preserve the information that is important in agiven context
I The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30
sec)1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engine
I Abstraction: preserve the information that is important in agiven context
I The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30
sec)1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engineI Abstraction: preserve the information that is important in a
given context
I The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30
sec)1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engineI Abstraction: preserve the information that is important in a
given contextI The human mind can operate easier with abstractions
I Experiment:197328643791468251973286437914682 (30sec)
1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engineI Abstraction: preserve the information that is important in a
given contextI The human mind can operate easier with abstractionsI Experiment:
197328643791468251973286437914682 (30sec)
1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engineI Abstraction: preserve the information that is important in a
given contextI The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30
sec)
1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Abstraction
I It comes in the same “package” with EncapsulationI Example: driving a car doesn’t require knowing the
internals of the combustion engineI Abstraction: preserve the information that is important in a
given contextI The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30
sec)1. How many can you remember?2. How many can you remember with unlimited amount of
time?
Inheritance
I Inheritance
: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”
I If class Child inherits from class Parent then Childuses the same implementation as Parent...
I ... with some exceptions:I Field hidding: Child can redefine data members (i.e, use
the same name) from ParentI Overriding: Child can override methods defined in
Parent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...
I ... with some exceptions:I Field hidding: Child can redefine data members (i.e, use
the same name) from ParentI Overriding: Child can override methods defined in
Parent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Inheritance
I Inheritance: reuse the code/features from a previouslydefined class
I Principle: DRY – “Do not repeat yourself”I If class Child inherits from class Parent then Child
uses the same implementation as Parent...I ... with some exceptions:
I Field hidding: Child can redefine data members (i.e, usethe same name) from Parent
I Overriding: Child can override methods defined inParent
I Single vs. multiple inheritance
Polymorphism
I It comes in many flavours:1. Overloading: multiple implementations of the same method
with different parameters2. Parametric – often used with generics: methods work with
parametric classes (e.g., sort for List<T>)3. Subtype: single interface to multiple representations of the
same type (the most common type of polymorphism)I Subtype polymorphism: uses inheritance
Polymorphism
I It comes in many flavours:
1. Overloading: multiple implementations of the same methodwith different parameters
2. Parametric – often used with generics: methods work withparametric classes (e.g., sort for List<T>)
3. Subtype: single interface to multiple representations of thesame type (the most common type of polymorphism)
I Subtype polymorphism: uses inheritance
Polymorphism
I It comes in many flavours:1. Overloading: multiple implementations of the same method
with different parameters
2. Parametric – often used with generics: methods work withparametric classes (e.g., sort for List<T>)
3. Subtype: single interface to multiple representations of thesame type (the most common type of polymorphism)
I Subtype polymorphism: uses inheritance
Polymorphism
I It comes in many flavours:1. Overloading: multiple implementations of the same method
with different parameters2. Parametric – often used with generics: methods work with
parametric classes (e.g., sort for List<T>)
3. Subtype: single interface to multiple representations of thesame type (the most common type of polymorphism)
I Subtype polymorphism: uses inheritance
Polymorphism
I It comes in many flavours:1. Overloading: multiple implementations of the same method
with different parameters2. Parametric – often used with generics: methods work with
parametric classes (e.g., sort for List<T>)3. Subtype: single interface to multiple representations of the
same type (the most common type of polymorphism)
I Subtype polymorphism: uses inheritance
Polymorphism
I It comes in many flavours:1. Overloading: multiple implementations of the same method
with different parameters2. Parametric – often used with generics: methods work with
parametric classes (e.g., sort for List<T>)3. Subtype: single interface to multiple representations of the
same type (the most common type of polymorphism)I Subtype polymorphism: uses inheritance
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child); // rejected by static type checkerChild p = (Child) bar(child); // dynamic check
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child); // rejected by static type checkerChild p = (Child) bar(child); // dynamic check
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child);
// rejected by static type checkerChild p = (Child) bar(child); // dynamic check
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child); // rejected by static type checker
Child p = (Child) bar(child); // dynamic check
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child); // rejected by static type checkerChild p = (Child) bar(child);
// dynamic check
Subtype polymorphism
I Suppose that Child inherits Parent, and consider afunction SomeType foo(Parent p) {...}
I In this case foo can be applied to an instance of anysubclass of Parent:
Child child = new Child();SomeType t = foo(child);
I Consider Parent bar(Parent p) { return p; }:Child child = new Child();Child p = bar(child); // rejected by static type checkerChild p = (Child) bar(child); // dynamic check
Dynamic dispatch
I Dynamic dispatch
: select the correct implementation of apolymorphic method at runtimeclass Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f() // f((Parent) child).f(); // f
Dynamic dispatch
I Dynamic dispatch: select the correct implementation of apolymorphic method at runtime
class Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f() // f((Parent) child).f(); // f
Dynamic dispatch
I Dynamic dispatch: select the correct implementation of apolymorphic method at runtimeclass Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f()
// f((Parent) child).f(); // f
Dynamic dispatch
I Dynamic dispatch: select the correct implementation of apolymorphic method at runtimeclass Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f() // f
((Parent) child).f(); // f
Dynamic dispatch
I Dynamic dispatch: select the correct implementation of apolymorphic method at runtimeclass Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f() // f((Parent) child).f();
// f
Dynamic dispatch
I Dynamic dispatch: select the correct implementation of apolymorphic method at runtimeclass Parent {... void f() {...} ...}class Child : Parent {... void f() {...} ...}...Child child = new Child();child.f() // f((Parent) child).f(); // f
Late binding
I Late binding
:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f() // b = 2;a = 0;
Late binding
I Late binding:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f()
// b = 2;a = 0;
Late binding
I Late binding:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f() // b =
2;a = 0;
Late binding
I Late binding:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f() // b = 2;
a = 0;
Late binding
I Late binding:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f() // b = 2;a =
0;
Late binding
I Late binding:class Parent {
int a = 0;void f() { g(); }void g() { a = 1; }
}class Child : Parent {
int b = 0;void g() { b = 2; }
}...Child child = new Child();child.f() // b = 2;a = 0;
Interfaces vs. Abstract classes
I Abstract class
: class without implementation for (at leastone) methods
I Interface: has methods without implementationI Traits:
1. Both can be inherited2. Abstract classes can contain implementation for functions3. Methods in interfaces must be implemented by the
implementing class
Interfaces vs. Abstract classes
I Abstract class: class without implementation for (at leastone) methods
I Interface: has methods without implementationI Traits:
1. Both can be inherited2. Abstract classes can contain implementation for functions3. Methods in interfaces must be implemented by the
implementing class
Interfaces vs. Abstract classes
I Abstract class: class without implementation for (at leastone) methods
I Interface
: has methods without implementationI Traits:
1. Both can be inherited2. Abstract classes can contain implementation for functions3. Methods in interfaces must be implemented by the
implementing class
Interfaces vs. Abstract classes
I Abstract class: class without implementation for (at leastone) methods
I Interface: has methods without implementationI Traits:
1. Both can be inherited
2. Abstract classes can contain implementation for functions3. Methods in interfaces must be implemented by the
implementing class
Interfaces vs. Abstract classes
I Abstract class: class without implementation for (at leastone) methods
I Interface: has methods without implementationI Traits:
1. Both can be inherited2. Abstract classes can contain implementation for functions
3. Methods in interfaces must be implemented by theimplementing class
Interfaces vs. Abstract classes
I Abstract class: class without implementation for (at leastone) methods
I Interface: has methods without implementationI Traits:
1. Both can be inherited2. Abstract classes can contain implementation for functions3. Methods in interfaces must be implemented by the
implementing class
Related concepts
I GenericsI PackagesI ModulesI Namespaces
Facts
I OOP scales; it is widely used in the industryI Not all languages that are advertised as OOP languages
support all the features above (e.g., C++ does not haveGC)
I Sometimes, misunderstanding of the OOP concepts maycomplicate your code
Resources
I Chapter 10 in Programming Languages: Principles andParadigms by Maurizio Gabbrielli and Simone Martini.URL: http://websrv.dthu.edu.vn/attachments/newsevents/content2415/Programming_Languages_-_Principles_and_Paradigms_thereds1106.pdf