Principles of Programming Languages Paradigms: OOP. · Object-Oriented Programming: Motivation-1 I...

Principles of Programming LanguagesParadigms: OOP.

Andrei Arusoaie1

1Department of Computer Science

December 17, 2018

Outline

Paradigms

Object-Oriented Programming

Conclusion

Paradigms

I Imperative Programming:

I Object Oriented ProgrammingI Functional ProgrammingI Logic Programming

Paradigms

I Imperative Programming:I Object Oriented Programming

I Functional ProgrammingI Logic Programming

Paradigms

I Imperative Programming:I Object Oriented ProgrammingI Functional Programming

I Logic Programming

Paradigms

I Imperative Programming:I Object Oriented ProgrammingI 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


I Complex softwareI NATO conference, 1968: software crisis

1. User dissatisfaction with the final product

2. cost overruns3. buggy software4. brittle software



1. User dissatisfaction with the final product2. cost overruns

3. buggy software4. brittle software



1. User dissatisfaction with the final product2. cost overruns3. buggy software

4. brittle software



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


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


Motivation-2


spaces)I Concurrency

I Event-driven interfaces


Motivation-2


spaces)I ConcurrencyI Event-driven interfaces



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


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


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



1. solving very complex problems2. working in teams

3. code modularity4. easy development and code maintenance



1. solving very complex problems2. working in teams3. code modularity

4. easy development and code maintenance


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


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



modifiersI Constructors, destructors

I Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowing

I Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hidding

I AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI Abstraction

I InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI Inheritance

I PolymorphismI Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI Polymorphism

I Dynamic method selection (or dynamic dispatch)I Interfaces, abstract classes



modifiersI Constructors, destructorsI Overloading, overriding, shadowingI Encapsulation, information hiddingI AbstractionI InheritanceI PolymorphismI Dynamic method selection (or dynamic dispatch)

I Interfaces, abstract classes



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.


Classes vs. Objects

I Class = a specification used to construct objectsI Classes establish the name of the class, the data method



Classes vs. Objects



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




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)


I Constructor: a special “method” which has the same nameas the class and no return type









I Destructor

: frees the memory occupied by the objectI Garbage Collector: automatic memory management






I Destructor: frees the memory occupied by the object

I Garbage Collector: automatic memory management(efficient memory allocation, automatically frees thememory, enables memory reuse)





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

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



time?

Abstraction


internals of the combustion engineI Abstraction: preserve the information that is important in a

given context



time?

Abstraction



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



given contextI The human mind can operate easier with abstractionsI Experiment:

197328643791468251973286437914682 (30sec)


time?

Abstraction



given contextI The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30

sec)


time?

Abstraction



given contextI The human mind can operate easier with abstractionsI Experiment:197328643791468251973286437914682 (30


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






Inheritance


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


Inheritance



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


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


with different parameters

2. Parametric – often used with generics: methods work withparametric classes (e.g., sort for List<T>)



Polymorphism



parametric classes (e.g., sort for List<T>)



Polymorphism




same type (the most common type of polymorphism)


Polymorphism




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





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





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





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





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 b = 0;void g() { b = 2; }

}...Child child = new Child();child.f()

// b = 2;a = 0;

Late binding




int b = 0;void g() { b = 2; }

}...Child child = new Child();child.f() // b =

2;a = 0;

Late binding




int b = 0;void g() { b = 2; }

}...Child child = new Child();child.f() // b = 2;

a = 0;

Late binding




int b = 0;void g() { b = 2; }

}...Child child = new Child();child.f() // b = 2;a =

0;

Late binding




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 have some implementations3. Methods in interfaces must be implemented by the

implementing class


I Abstract class: class without implementation for (at leastone) methods



implementing class



I Interface

: has methods without implementationI Traits:


implementing class




1. Both can be inherited

2. Abstract classes can have some implementations3. Methods in interfaces must be implemented by the

implementing class




1. Both can be inherited2. Abstract classes can have some implementations

3. Methods in interfaces must be implemented by theimplementing class





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: http://websrv.dthu.edu.vn/attachments/newsevents/content2415/Programming_Languages_-_Principles_and_Paradigms_thereds1106.pdf

I KOOL: https://github.com/kframework/k/tree/master/k-distribution/tutorial/2_languages/2_kool

http://websrv.dthu.edu.vn/attachments/newsevents/content2415/Programming_Languages_-_Principles_and_Paradigms_thereds1106.pdf




https://github.com/kframework/k/tree/master/k-distribution/tutorial/2_languages/2_kool



Principles of Programming Languages Paradigms: OOP. · Object-Oriented Programming: Motivation-1 I...

Documents

Transcript of Principles of Programming Languages Paradigms: OOP. · Object-Oriented Programming: Motivation-1 I...