Aspects of object orientation Jan Niklas Rsch Institute for - - PowerPoint PPT Presentation

▶
aspects of object orientation
SMART_READER_LITE
LIVE PREVIEW

Aspects of object orientation Jan Niklas Rsch Institute for - - PowerPoint PPT Presentation

Jul 03, 2023 399 likes •684 views

Aspects of object orientation Jan Niklas Rsch Institute for Software Engineering and Programming Languages 01. February 2016 J.N. Rsch 01. February 2016 1/27 Table of contents Introduction Variance Instantiation, Subtyping and

slide-1
SLIDE 1

Aspects of object orientation

Jan Niklas Rösch

Institute for Software Engineering and Programming Languages

  • 01. February 2016

J.N. Rösch

  • 01. February 2016

1/27

slide-2
SLIDE 2

Table of contents

Introduction Variance Instantiation, Subtyping and Subclassing Type systems Conclusion

J.N. Rösch

  • 01. February 2016

2/27

slide-3
SLIDE 3

Introduction

◮ Many different aspects that make up a language ◮ Defining relationship between objects

◮ Fundamental facet of OOP

◮ These aspects contribute to an overall behaviour of the language

J.N. Rösch

  • 01. February 2016

3/27

slide-4
SLIDE 4

Variance - Overview

◮ Describes behaviour of complex structures

◮ Lists ◮ Arrays ◮ Functions ◮ ...

◮ Covariance and Contravariance ◮ Invariance and Bivariance

J.N. Rösch

  • 01. February 2016

4/27

slide-5
SLIDE 5

Variance - Definitions Complex Structure

IA

Subtyping

A ≤ B , IA ≤ IB

J.N. Rösch

  • 01. February 2016

5/27

slide-6
SLIDE 6

Variance - Covariance Covariance

A ≤ B → IA ≤ IB

◮ Ordering of types is preserved ◮ Most common approach

Covariant Array

String [ ] s t r = new String [ 1 ] ; Object [ ]

  • bj = s t r ;

J.N. Rösch

  • 01. February 2016

6/27

slide-7
SLIDE 7

Variance - Broken Array Covariance Runtime Error

String [ ] s t r = new String [ 1 ] ; Object [ ]

  • bj = s t r ;
  • bj [ 0 ] = 2;

◮ safe to read but not safe to write ◮ not caught at compile time

J.N. Rösch

  • 01. February 2016

7/27

slide-8
SLIDE 8

Variance - Contravariance Contravariance

A ≤ B → IB ≤ IA

◮ Ordering of types is reversed ◮ Unintuitive but comes with some benefits

J.N. Rösch

  • 01. February 2016

8/27

slide-9
SLIDE 9

Variance - Contravariance Contravariant comparator

void CompareCats ( IComparer<Cat> comparer ) { var cat1 = new Cat ( " Mittens " ) ; var cat2 = new Cat ( " Oliver " ) ; i f ( comparer . Compare( cat1 , cat2 ) > 0) Console . WriteLine ( " Mittens wins ! " ) ; } IComparator <Animal> compAnimals = new AnimalComparator ( ) ; CompareCats ( compAnimals ) ;

◮ Using a base class instead of a more derived one

J.N. Rösch

  • 01. February 2016

9/27

slide-10
SLIDE 10

Variance - Invariance Invariance

A ≤ B → IA ≤ IB ∧ IB ≤ IA

◮ Prohibits variant behaviour of complex structures ◮ Regardless of underlying type hierarchy ◮ Used to prevent type errors

J.N. Rösch

  • 01. February 2016

10/27

slide-11
SLIDE 11

Variance - Invariance Invariant list

void MammalReadWrite ( I L i s t <Mammal> mammals ) { Mammal mammal = mammals [ 0 ] ; mammals [ 0 ] = new Tiger ( ) ; }

◮ Covariance: List of giraffes

◮ Put a tiger in it

◮ Contravariance: List of animals

◮ Animals do not need to be mammals J.N. Rösch

  • 01. February 2016

11/27

slide-12
SLIDE 12

Variance - Bivariance Bivariance

IA ≤ IB , IB ≤ IA

◮ Either impossible or not allowed ◮ Only listed for the sake of completeness

J.N. Rösch

  • 01. February 2016

12/27

slide-13
SLIDE 13

Instantiation, Subtyping and Subclassing

◮ Instantiation

◮ Creation of a new object

◮ Subtyping

◮ Describes relationship of objects ◮ Objects share a common interface ◮ ’Is-a’ relationship → Liskov substitution principle

◮ Subclassing

◮ Does not alter type hierarchy ◮ Reuse of code

◮ Class-based vs Prototype-based

J.N. Rösch

  • 01. February 2016

13/27

slide-14
SLIDE 14

Class-based Programming - Instantiation

◮ Classes as blueprints

◮ Can not change at runtime ◮ Easier to optimize compiler tasks

◮ Implicit/Explicit constructors

◮ Creates new instance of a class ◮ Allocates memory ◮ Initialize all fields J.N. Rösch

  • 01. February 2016

14/27

slide-15
SLIDE 15

Class-based Programming - Instantiation Class-based instantiation

class NumBox{ private int number ; public numBox( int num) { this . number = num; } public int getNum ( ) { return this . number ; } } NumBox num3 = new NumBox( 3 ) ; p r i n t (num3. getNum ( ) ) ;

J.N. Rösch

  • 01. February 2016

15/27

slide-16
SLIDE 16

Class-based Programming - Subtyping

◮ Type hierarchy has to be explicitly declared

Class-based subtyping

class NumBox { . . . } class PNatBox extends NumBox { . . . }

◮ No subclassing without subtyping ◮ Example: Square vs Rectangle

J.N. Rösch

  • 01. February 2016

16/27

slide-17
SLIDE 17

Prototype-based Programming - Instantiation

◮ No classes ◮ Constructor functions

◮ Explicitly declared

Constructor

function ExampleObject ( ) { . . . }

◮ Ex-nihilo

◮ Using object literals

Ex-nihilo

var cat = { name : " Tardar_Sauce " , f o l l o w e r : 8403156 }

J.N. Rösch

  • 01. February 2016

17/27

slide-18
SLIDE 18

Prototype-based Programming - Subtyping

◮ Cloning

◮ Objects inherit from objects ◮ Copy fields into clone ◮ Add more specialized fields

◮ Ex-nihilo

◮ Root object

Cloning

function ParentClass ( ) { . . . } function ChildClass ( ) { . . . } ChildClass . prototype = new ParentClass ( ) ;

J.N. Rösch

  • 01. February 2016

18/27

slide-19
SLIDE 19

Prototype-based Programming - Pure Prototyping

◮ Prototypes and objects can be changed at runtime ◮ Links between prototype and clones

◮ Change in prototype will update clones

◮ Pure prototyping

◮ No delegation but much more memory is used ◮ Different versions of same type J.N. Rösch

  • 01. February 2016

19/27

slide-20
SLIDE 20

Type systems - Overview

◮ Ensure type safety ◮ Define equality and compatibility of types ◮ Can vary widely depending on the language ◮ Not exclusive to OOP ◮ Structural typing ◮ Nominal / nominative typing

J.N. Rösch

  • 01. February 2016

20/27

slide-21
SLIDE 21

Type systems - Structural Typing

◮ Elements with the same structure are compatible

◮ Attributes with their names ◮ Functions with their names and parameter/return types

◮ The name of the type does not matter ◮ Nor does the place of declaration

J.N. Rösch

  • 01. February 2016

21/27

slide-22
SLIDE 22

Type systems - Structural Typing

◮ Automatism of type compatibility ◮ Very flexible and convenient

◮ Type hierarchy does not need to be declared beforehand ◮ Programmer does not need to maintain the common interfaces himself

Implicit common interface

type A = { type B = { foo ( ) ; foo ( ) ; bar ( ) ; baz ( ) ; } }

J.N. Rösch

  • 01. February 2016

22/27

slide-23
SLIDE 23

Type systems - Structural Typing Problem with compatible types

record DistanceInInches { double d i s t ; } ; record DistanceInCentimeters { double d i s t ; } ;

◮ Equivalent in structure ◮ Different in meaning

J.N. Rösch

  • 01. February 2016

23/27

slide-24
SLIDE 24

Type systems - Nominal Typing

◮ Subset of structural typing ◮ Much more type-safe ◮ No accidental inheritance ◮ Subtyping has to be explicitly declared

J.N. Rösch

  • 01. February 2016

24/27

slide-25
SLIDE 25

Type systems - Nominal Typing Nominal subtyping

class Animal { void feed ( ) { . . . } } class Cat extends Animal { i n t age = 5; }

◮ Without ’extends’ these classes would be completely distinct from each

  • ther

J.N. Rösch

  • 01. February 2016

25/27

slide-26
SLIDE 26

Conclusion

◮ Defining relationship between objects

◮ Based on many pieces ◮ All come together to make up the specific language

◮ Flexibility vs Safety

◮ Finding the right mix can be difficult ◮ Trade-offs are hard to make

◮ In the end it comes down to personal preference

J.N. Rösch

  • 01. February 2016

26/27

slide-27
SLIDE 27

Thank you for your attention! QUESTIONS ?

J.N. Rösch

  • 01. February 2016

27/27