Lecture 10: Part 1: OO Issues - PowerPoint PPT Presentation

lecture 10 part 1 oo issues n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture 10: Part 1: OO Issues PowerPoint Presentation
Download Presentation
Lecture 10: Part 1: OO Issues

play fullscreen
1 / 12
Lecture 10: Part 1: OO Issues
129 Views
Download Presentation
hideaki
Download Presentation

Lecture 10: Part 1: OO Issues

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Lecture 10: Part 1: OO Issues CS 540 George Mason University

  2. Object-Oriented Languages? What is an OOL? • A language that supports “object-oriented programming” • Term is almost meaningless today — Smalltalk to C++ to Java How does an OOL differ from an imperative language? • Complex type system including inheritance and polymorphism. • Object representation issues • Resolution of names to their implementations CS 540 Spring 2004 GMU

  3. x y z Data Code Data Code Data Code An object is an abstract data type that encapsulates data, operations and internal state behind a simple, consistent interface. Elaborating the concepts: • Each object needs local storage for its attributes • Attributes are static (lifetime of object ) • Access is through methods • Some methods are public, others are private • Object’s internal state leads to complex behavior The Concept: CS 540 Spring 2004 GMU

  4. Implementing Object-Oriented Languages Two critical issues in OOL implementation: • Object representation • Mapping a method invocation name to a method implementation These both are intimately related to the OOL’s name space Object Representation • Static, private storage for attributes & instance variables • Heap allocate object records or “instances” • Need consistent, fast access • Known, constant offsets • Provision for initialization in NEW CS 540 Spring 2004 GMU

  5. Simplistic method: Object Representation Class A { int b,c; A z; f1() f2() } For object x of type A: f1 code f1 code b: c: z f1 f2 b: c: z f1 f2 f2 code f2 code Each object gets copies of all attributes and methods CS 540 Spring 2004 GMU

  6. Better method Class A { int b,c; A z; f1() f2() } For object x of type A: f1 code b: c: z f1 f2 b: c: z f1 f2 f2 code Objects share methods (and static attributes) CS 540 Spring 2004 GMU

  7. More typically: Class A { int b,c; static int d A z; f1() f2() } For object x of type A: parent class b: c: z b: c: z N: 2 d: f1 f2 Class A f1 code f2 code Objects share methods (and static attributes) via shared class object (can keep counter of objects N) CS 540 Spring 2004 GMU

  8. OOL Storage Layout Class variables • Static class storage accessible by global name (class C) • Method code put at fixed offset from start of class area • Static variables and class related bookkeeping Object Variables • Object storage is heap allocated at object creation • Fields at fixed offsets from start of object storage • Methods • Code for methods is stored with the class • Methods accessed by offsets from code vector • Allows method references inline • Method local storage in object (no calls) or on stack CS 540 Spring 2004 GMU

  9. x y Dealing with Single Inheritance • Use prefixing of storage for objects Class Point { int x, y; } Class ColorPoint extends Point { Color c; } self self x y c CS 540 Spring 2004 GMU

  10. Object-Oriented Languages - Dispatching Mapping message names to methods • Static mapping, known at compile-time (Java, C++) • Fixed offsets & indirect calls • Dynamic mapping, unknown until run-time (Smalltalk, C++ with pointers) • Look up name in class’ table of methods This is really a data-structures problem • Build a table of function pointers • Use a standard invocation sequence CS 540 Spring 2004 GMU

  11. draw draw x d2o d2o y x y c Single Inheritance and Dynamic Dispatch Class Point { int x, y; public void draw(); public void d2o(); } Class ColorPoint extends Point { Color c; public void draw(); public void rev(); } table Point: draw self Point: d20 table ColorPoint:draw self rev ColorPoint: rev CS 540 Spring 2004 GMU

  12. Multiple Inheritance The idea • Allow more flexible sharing of methods & attributes • Relax the inclusion requirement If B is a subclass of A, it need not implement all of A’s methods • Need a linguistic mechanism for specifying partial inheritance Problems when C inherits from both A & B • C’s method table can extend A or B, but not both • Layout of an object record for C becomes tricky • Other classes, say D, can inherit from C & B • Adjustments to offsets become complex • Both A & B might provide fum() — which is seen in C ? • C++ produces a “syntax error” when fum() is used CS 540 Spring 2004 GMU