Classification [7] O OSE E + classes + inheritance Object Orientation object−based class−based object−oriented Operating-System Engineering Operating-System Engineering — Object Orientation 2 Object-Oriented Design [2] Object-Based • implies the capability of data abstraction { methods provide access to attributes method { attributes represent instance variables Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and attribute • methods define the object’s external interface object physical as well as static and dynamic models of the systems under design. { similar to an abstract data type (ADT) • objects are unique instances, having only in common the need for memory Operating-System Engineering — Object Orientation 1 Operating-System Engineering — Object Orientation 3 Class-Based Object Orientation = Objects + Classes + Inheritance • objects are instances of classes • an object-oriented programming language must provide linguistic support { a class defines a set of common properties methods { properties are attributes of a class { it must enable the programmers to describe common properties of objects { classes may be compared to types ∗ such a language is referred to as an object-based programming language { it is called object-oriented only if class hierarchies can be built by inheritance ∗ • a meta-description specifies the interface instances so that the objects can be instances of classes that have been inherited { it allows the modeling of an object as a polymorphous entity { describing a uniform management class { indicating further data abstractions • object orientation is unattainable using imperative programming languages1 • depending on the programming language employed, a class may be an ADT 1Notwithstanding, from time to time there are comments stating the development of object-oriented systems using e.g. the C programming language. This is in contradiction to the classical definition of object orientation [7]. Operating-System Engineering — Object Orientation 4 Operating-System Engineering — Object Orientation 6 Object-Oriented Synonyms of the \Theory of Heredity" • implies the composition of abstract data types on the basis of inheritance base class ............ derived class { new classes are constructed by the reuse of (an) existing class(es) superclass ............ subclass { properties of the existing class(es) are inherited to the new class parent class ............ child class { a new class adds properties and/or redefines inherited properties inheriting class ............ inherited class • objects instantiated from classes composed in that way are polymorphous common class ............ specialized class { according to the class hierarchy, a single object relates to several classes { the object will be type compatible to more than one class “upper class” ............ “lower class” • inheritance allows for the specialization of the inherited class(es) Operating-System Engineering — Object Orientation 5 Operating-System Engineering — Object Orientation 7 Distinctness of Heredity Multiple Inheritance • a class is derivable from many base classes • inheritance appears in various shapes and is of different consequences: { many sets of attributes to inherit Foo Bar { single inheritance .....................................................9 { method redefinition/overloading is crucial { multiple inheritance ..................................................10 { classes can be inherited several times Foobar Fop ∗ multiple inclusion ..................................................11 ∗ sharing ............................................................12 • the class hierarchy may be deep and wide single inheritance path Foobarfop { a concept for implementation unification • any of these kinds serves the construction of a class hierarchy • brings about better reusability at the expense of an efficient implementation { class reuse is still limited to the very base class, but there are many of which Operating-System Engineering — Object Orientation 8 Operating-System Engineering — Object Orientation 10 Single Inheritance Multiple Inheritance Multiple Inclusion • a class is derivable from only one base class fragments { only a single set of attributes to inherit Foo base class Fop Fop Foobar object Fop Foo Fop Bar { method redefinition/overloading is simple fop foo Bar derived class base class Foo Bar • fop the class hierarchy is narrow but may be deep bar { a derived class may serve as a base class Foobar derived class Foobar foobar • brings about fairly efficient implementations at the expense of reusability • the attributes of classes inherited several times are included several times { class reuse implies composition, method redefinition, and kind of delegation { only the very base class appears to be reusable without any add-to • the final object contains copies of object fragments of the same class Operating-System Engineering — Object Orientation 9 Operating-System Engineering — Object Orientation 11 Multiple Inheritance Sharing Object Layout this-Polymorphism fragments this Fop Fop Fop Fop Foobar object Fop Foo Bar fop* foo object Foo Bar Fop* Foo* Foobar* Foo Bar fop* 0 fop bar foo Bar* Fop* Foobar foobar Foobar fop bar fop foobar N−1 • the attributes of classes inherited several times are included once only • from Foobar to Foo::Fop ⇒ this remains unchanged • the final object contains copies of pointers to the shared object fragment(s) • from Foobar to Bar::Fop ⇒ this +=sizeof(Foo) Operating-System Engineering — Object Orientation 12 Operating-System Engineering — Object Orientation 14 Object Layout Object Layout this-Adjustment foo__6Foobar: • Foo is on the single inheritance path: this pass through pushl 4(%esp) call foo__3Foo • addl $4711,%eax a method applied to an object is implicitly supplied with the object’s address addl $4,%esp f ret 2 class Foobar : public Foo, public Bar { within the single inheritance path, this is identical for all the classes int foo () f { taking multiple inheritance branches into account, this becomes variable return Foo::foo() + 4711; bar__6Foobar: g movl 4(%esp),%eax testl %eax,%eax ................................... jne .L4 • multiple inheritance may entail pointer manipulation upon method invocation int bar () f xorl %eax,%eax return Bar::bar() + 42; jmp .L5 .p2align 4,,7 { from derived to base class: adding some delta g g .L4: → ; addl $4,%eax { from base to derived class: subtracting some delta p. 16 .L5: pushl %eax call bar__3Bar • Bar is a multiple inheritance branch: (cond.) adjustment addl $42,%eax 2In C++, the pointer to the instance of a class (i.e., object) the invoked method is actually applied to. addl $4,%esp ret Operating-System Engineering — Object Orientation 13 Operating-System Engineering — Object Orientation 15 Late Binding Late Binding C++ → x86 • the compiler implements the common model fb: • .zero 8 the association at runtime of which method is going to be applied to an object . { treats all virtual methods identical . { the object’s methods are bound at the point in time of object instantiation movl $_vt$6Foobar$3Bar,fb+4 movl $_vt$6Foobar,fb . 3 • for methods to be capable of late binding, three preconditions must hold: Foobar fb; .................................................. fb: .zero 8 . 1. they must have been defined in (the external interface of) a base class, • the compiler implements the thunk model . 2. the method’s base class(es) must be inherited by some derived class(es), movl $__vt_6Foobar,fb { gives priority to the single inheritance path movl $__vt_6Foobar.3Bar,fb+4 3. and they must be redefined by the derived class(es) . { handicaps multiple inheritance branches . • also called dynamic binding—but must not be mixed up with dynamic loading 3gcc -O6 -S -fno-rtti -fno-exceptions -fomit-frame-pointer Operating-System Engineering — Object Orientation 16 Operating-System Engineering — Object Orientation 18 Late Binding C++ Case Study Late Binding Method Redefinition f f class Foo class Foobar : public Foo, public Bar int Foobar::foo () f foo__6Foobar: f public: int foo () return 4711; ........................................................ movl $4711,%eax virtual int foo () = 0; return 4711; g ret g; g int Foobar::bar () f bar__6Foobar: f f class Bar int bar () return 42; ........................................................ movl $42,%eax return 42; public: g; ret virtual int bar () = 0; g g; g; • the generated code is the same for the common model and the thunk model int foobar (Foo* fp, Bar* bp) f return fp->foo() + bp->bar(); • that a method is subjected to late binding is transparent to the method itself g; Foobar fb; Operating-System Engineering — Object Orientation 17 Operating-System Engineering — Object Orientation 19 Late Binding Common Model (1) Late Binding Thunk Model (1) • • every class containing a virtual function has a _vt$6Foobar: every class containing a virtual function has a virtual-function table virtual-function table of “call descriptors” .value 0 .value 0 { of function pointers __vt_6Foobar: { atripleofoffset, ?, and function pointer .long 0 .long 0 .value 0 .long 0 class Foobar : public Foo, public Bar f .value 0 .long foo__6Foobar class Foobar : public Foo, public Bar f int foo (); .long foo__6Foobar .................... int foo (); int bar (); .............................. __vt_6Foobar.3Bar: int bar (); g; _vt$6Foobar$3Bar: .long -4 g; .value -4 .long 0 .value 0 • thunks relate to multiple inheritance branches .long __thunk_4_bar__6Foobar