1 / 12

Lecture 10: Part 1: OO Issues

Lecture 10: Part 1: OO Issues. CS 540 George Mason University. 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?

hideaki
Télécharger la présentation

Lecture 10: Part 1: OO Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related