DOCSLIB.ORG

The C++ Programming Language Single and Multiple Inheritance In

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The C++ Programming Language Single and Multiple Inheritance In Background The C++ Programming Object-oriented programming is often de- ned as the combination of Abstract Data Language Typ es ADTs with Inheritance and Dy- namic Binding Single and Multiple Inheritance in Each concept addresses a di erent asp ect of system decomp osition: C++ 1. ADTs decomp ose systems into two-dimensional grids of mo dules { Each mo dule has public and private inter- faces Douglas C. Schmidt 2. Inheritance decomp oses systems into three-dimensional www.cs.wustl.edu/schmidt/ hierarchies of mo dules { Inheritance relationships form a \lattice" [email protected] 3. Dynamic binding enhances inheritance Washington University, St. Louis { e.g., defer implementation decisions until late in the design phase or even until run-time! 2 1 Motivation for Inheritance Data Abstraction vs. Inheritance Inheritance allows you to write co de to DATA ABSTRACTION certain cases and allows other de- (2 DIMENTIONAL) handle (2 DIMENTIONAL) velop ers to write co de that handles more sp ecialized cases, while your co de contin- ues to work Inheritance partitions a system architec- ture into semi-disjoint comp onents that are related hierarchically Therefore, we may be able to mo dify and/or reuse sections of the inheritance hierarchy without disturbing existing co de, e.g., { Change sibling subtree interfaces i.e., a consequence of inheritance INHERITANCE (3 DIMENTIONAL) { Change implementation of ancestors i.e., a consequence of data abstraction 3 4 Inheritance Overview Visualizing Inheritance A typ e called a sub class or derived typ e can inherit the characteristics of another typ es called a sup erclass or base typ e Base The term sub class is equivalent to derived typ e { Derived 2 A derived typ e acts just like the base typ e, Derived for an explicit list of: except 1 Derived 1. Sp ecializations 5 { Change implementations without changing base class interface the Derived Most useful when combined with dynamic Derived 4 binding 3 Derived 6 2. Generalizations/Extensions { Add new op erations or data to derived classes 5 6 Typ es of Inheritance Inheritance Trees vs. Inheritance DAGs Inheritance comes in two forms, dep end- ing on numb er of parents a sub class has Single Inheritance SI 1. Base Derived Derived Only one parent per derived class { 1 2 { Form an inheritance \tree" INHERITANCE Derived { SI requires a small amount of run-time over- when used with dynamic binding head Derived TREE 4 3 { e.g., Smalltalk, Simula, Object Pascal 2. Multiple Inheritance MI More than one parent per derived class { Base Base 1 Derived 2 { Forms an inheritance \Directed Acyclic Graph" AG D 1 { Compared with SI, MI adds additional run- overhead also involving dynamic bind- time INHERITANCE ing Derived Derived 3 DAG 4 { e.g., C++, Ei el, Flavors a LISP dialect 7 8 Inheritance Bene ts Inheritance Liabilities 1. Increase reuse and software quality 1. May create deep and/or wide hierarchies Programmers reuse the base classes instead of that are dicult to understand and navi- writing new classes gate without class browser to ols { Integrates black-b ox and white-b ox reuse by allowing extensibility and mo di cation with- out changing existing co de 2. May decrease p erformance slightly Using well-tested base classes helps reduce bugs i.e., when combined with multiple inheritance in applications that use them and dynamic binding Reduce object co de size 3. Without dynamic binding, inheritance has only limited utility 2. Enhance extensibility and comprehensibil- ity Likewise, dynamic binding is almost totally use- less without inheritance Helps supp ort more exible and extensible ar- chitectures along with dynamic binding { i.e., supp orts the op en/closed principle 4. Brittle hierarchies, which may imp ose de- Often useful for mo deling and classifying hierarchically- p endencies up on ancestor names related domains 10 9 Key Prop erties of C++ Inheritance The base/derived class relationship is ex- Inheritance in C++ plicitly recognized in C++ by prede ned standard conversions { i.e., a p ointer to a derived class may always be Deriving a class involves an extension to assigned to a p ointer to a base class that was the C++ class declaration syntax inherited publically But not vice versa::: The class head is mo di ed to allow a deriva- tion list consisting of base classes When combined with dynamic binding, this sp ecial relationship between inherited class typ es promotes a typ e-secure, p olymor- phic style of programming e.g., { i.e., the programmer need not know the actual typ e of a class at compile-time class Foo f /* :::g; class Bar : public Foo f /* :::g; { Note, C++ is not truly p olymorphic class Foo : public Foo, public Bar f /* :::g; i.e., op erations are not applicable to objects that don't contain de nitions of these op- erations at some p oint in their inheritance hierarchy 11 12 Simple Screen Class Sub classing from Screen The following co de is used as the base class: class Screen can be a public base class of class Window class Screen f public: Screen int = 8, int = 40, char = ' '; e.g., ~Screen void; short height void const f return this->height ; g class Window : public Screen f short width void const f return this->width ; g public: = h; g void height short h f this->height Window const Point &, int rows = 24, void width short w f this->width = w; g int columns = 80, Screen &forward void; char default char = ' '; Screen &up void; void set foreground color Color &; Screen &down void; void set background color Color &; Screen &home void; void resize int height, int width; Screen &b ottom void; // ::: Screen &display void; private: Screen &copy const Screen &; Point center ; // ::: Color foreground ; private: Color background ; short height , width ; // ::: char *screen , *cur pos ; g; g; 13 14 The Screen Inheritance Hierarchy Multiple Levels of Derivation A derived class can itself form the basis for further derivation, e.g., Point Menu : public Window f class Screen public: lab el const char *l; set void Color Menu const Point &, int rows = 24, int columns = 80, char default char = ' '; // ::: rivate: p Window char *lab el ; Menu // ::: g; class Menu inherits data and metho ds from b oth Window and Screen { i.e., sizeof Menu >= sizeof Window >= sizeof Screen Screen/Window/Menu hierarchy 15 16 Using the Screen Hierarchy Variations on a Screen: : : e.g., ps1 : Screen f public: virtual void dump ostream &; = 0 g ps2 : class Window : public Screen f Screen Screen class public: virtual void dump ostream &; g; class Menu : public Window f public: virtual void dump ostream &; g; // stand-alone function void dump Screen *s, ostream &o f w : image Some pro cessing omitted Window Menu // s->dump o; // *s->vptr[1] s, o; g Screen s; Window w; Menu m; Vector bv; Bit // OK: Window is a kind of Screen A p ointer to a derived class can be as- dump image &w, cout; signed to a p ointer to any of its public // OK: Menu is a kind of Screen base classes without requiring an explicit image &m, cout; dump cast: // OK: argument typ es match exactly image &s, cout; dump Menu m; Window &w = m; Screen *ps1 = &w; Vector is not a kind of Screen! // Error: Bit Screen *ps2 = &m; dump image &bv, cout; 18 17 Sp ecialization Example Using Inheritance for Sp ecialization Inheritance may be used to obtain the fea- tures of one data typ e in another closely A derived class sp ecializes a base class by related data typ e adding new, more sp eci c state variables and metho ds For example, class Date represents an ar- { Metho d use the same interface, even though bitrary Date: they are implemented di erently class Date f i.e., \overridden" public: Date int m, int d, int y; virtual void print ostream &s const; // ::: { Note, there is an imp ortant distinction between private: overriding, hiding, and overloading::: , day , year ; int month g; Class Birthday derives from Date, adding a name eld representing the p erson's birth- A variant of this is used in the template day, e.g., metho d pattern class Birthday : public Date f { i.e., b ehavior of the base class relies on func- public: tionality supplied by the derived class Birthday const char *n, int m, int d, int y : Date m, d, y, p erson strdup n fg ~Birthday void f free p erson ; g virtual void print ostream &s const; { This is directly supp orted in C++ via abstract // ::: base classes and pure virtual functions private: ; const char *p erson g; 20 19 Alternatives to Sp ecialization Implementation and Use-case Note that we could also use object com- Birthday::print could print the p erson's name p osition instead of inheritance for this ex- as well as the date, e.g., ample, e.g., void Birthday::print ostream &s const f class Birthday f << " was born on "; s << this->p erson public Date::print s; Birthday char *n, int m, int d, int y: s << "\n"; date m, d, y, p erson n fg g // same as b efore private: ; Date date e.g., ; char *p erson g; const Date july 4th 7, 4, 1993; Birthday my birthday "Douglas C. Schmidt", 7, 18, 1962; However, in this case we would not be able to utilize the dynamic binding facilities for july 4th.print cerr; base classes and derived classes // july 4th, 1993 birthday.print cout; my { e.g., // Douglas C. Schmidt was born on july 18th, 1962 Date *dp = &my birthday; Date *dp = &my birthday; // ERROR, Birthday is not a sub class of date! dp->print cerr; { While this do es not necessarily a ect reusabil- // ??? what gets printed ??? ity, it do es a ect extensibility::: // *dp->vptr[1]dp, cerr; 21 22 Extension/Generalization Using Inheritance for Example
Load more

Recommended publications
  • MANNING Greenwich (74° W
    Object Oriented Perl Object Oriented Perl DAMIAN CONWAY MANNING Greenwich (74° w. long.) For electronic browsing and ordering of this and other Manning books, visit http://www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. 32 Lafayette Place Fax: (203) 661-9018 Greenwich, CT 06830 email: [email protected] ©2000 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Library of Congress Cataloging-in-Publication Data Conway, Damian, 1964- Object oriented Perl / Damian Conway. p. cm. includes bibliographical references. ISBN 1-884777-79-1 (alk. paper) 1. Object-oriented programming (Computer science) 2. Perl (Computer program language) I. Title. QA76.64.C639 1999 005.13'3--dc21 99-27793 CIP Manning Publications Co. Copyeditor: Adrianne Harun 32 Lafayette
    [Show full text]
  • A Comparative Study on the Effect of Multiple Inheritance Mechanism in Java, C++, and Python on Complexity and Reusability of Code
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 8, No. 6, 2017 A Comparative Study on the Effect of Multiple Inheritance Mechanism in Java, C++, and Python on Complexity and Reusability of Code Fawzi Albalooshi Amjad Mahmood Department of Computer Science Department of Computer Science University of Bahrain University of Bahrain Kingdom of Bahrain Kingdom of Bahrain Abstract—Two of the fundamental uses of generalization in Booch, there are two problems associated with multiple object-oriented software development are the reusability of code inheritance and they are how to deal with name collisions from and better structuring of the description of objects. Multiple super classes, and how to handle repeated inheritance. He inheritance is one of the important features of object-oriented presents solutions to these two problems. Other researchers [4] methodologies which enables developers to combine concepts and suggest that there is a real need for multiple inheritance for increase the reusability of the resulting software. However, efficient object implementation. They justify their claim multiple inheritance is implemented differently in commonly referring to the lack of multiple subtyping in the ADA 95 used programming languages. In this paper, we use Chidamber revision which was considered as a deficiency that was and Kemerer (CK) metrics to study the complexity and rectified in the newer version [5]. It is clear that multiple reusability of multiple inheritance as implemented in Python, inheritance is a fundamental concept in object-orientation. The Java, and C++. The analysis of results suggests that out of the three languages investigated Python and C++ offer better ability to incorporate multiple inheritance in system design and reusability of software when using multiple inheritance, whereas implementation will better structure the description of objects Java has major deficiencies when implementing multiple modeling, their natural status and enabling further code reuse inheritance resulting in poor structure of objects.
    [Show full text]
  • Mixins and Traits
    ◦ ◦◦◦ TECHNISCHE UNIVERSITAT¨ MUNCHEN¨ ◦◦◦◦ ◦ ◦ ◦◦◦ ◦◦◦◦ ¨ ¨ ◦ ◦◦ FAKULTAT FUR INFORMATIK Programming Languages Mixins and Traits Dr. Michael Petter Winter 2016/17 What advanced techiques are there besides multiple implementation inheritance? Outline Design Problems Cons of Implementation Inheritance 1 Inheritance vs Aggregation 1 2 (De-)Composition Problems Lack of finegrained Control 2 Inappropriate Hierarchies Inheritance in Detail A Focus on Traits 1 A Model for single inheritance 1 2 Inheritance Calculus with Separation of Composition and Inheritance Expressions Modeling 2 3 Modeling Mixins Trait Calculus Mixins in Languages Traits in Languages 1 (Virtual) Extension Methods 1 Simulating Mixins 2 Squeak 2 Native Mixins Reusability ≡ Inheritance? Codesharing in Object Oriented Systems is often inheritance-centric. Inheritance itself comes in different flavours: I single inheritance I multiple inheritance All flavours of inheritance tackle problems of decomposition and composition The Adventure Game Door ShortDoor LockedDoor canPass(Person p) canOpen(Person p) ? ShortLockedDoor canOpen(Person p) canPass(Person p) The Adventure Game Door <interface>Doorlike canPass(Person p) canOpen(Person p) Short canPass(Person p) Locked canOpen(Person p) ShortLockedDoor ! Aggregation & S.-Inheritance Door must explicitely provide canOpen(Person p) chaining canPass(Person p) Doorlike must anticipate wrappers ) Multiple Inheritance X The Wrapper FileStream SocketStream read() read() write() write() ? SynchRW acquireLock() releaseLock() ! Inappropriate Hierarchies
    [Show full text]
  • Mixin-Based Programming in C++1
    Mixin-Based Programming in C++1 Yannis Smaragdakis Don Batory College of Computing Department of Computer Sciences Georgia Institute of Technology The University of Texas at Austin Atlanta, GA 30332 Austin, Texas 78712 [email protected] [email protected] Abstract. Combinations of C++ features, like inheritance, templates, and class nesting, allow for the expression of powerful component patterns. In particular, research has demonstrated that, using C++ mixin classes, one can express lay- ered component-based designs concisely with efficient implementations. In this paper, we discuss pragmatic issues related to component-based programming using C++ mixins. We explain surprising interactions of C++ features and poli- cies that sometimes complicate mixin implementations, while other times enable additional functionality without extra effort. 1 Introduction Large software artifacts are arguably among the most complex products of human intellect. The complexity of software has led to implementation methodologies that divide a problem into manageable parts and compose the parts to form the final prod- uct. Several research efforts have argued that C++ templates (a powerful parameteriza- tion mechanism) can be used to perform this division elegantly. In particular, the work of VanHilst and Notkin [29][30][31] showed how one can implement collaboration-based (or role-based) designs using a certain templatized class pattern, known as a mixin class (or just mixin). Compared to other techniques (e.g., a straightforward use of application frameworks [17]) the VanHilst and Notkin method yields less redundancy and reusable components that reflect the structure of the design. At the same time, unnecessary dynamic binding can be eliminated, result- ing into more efficient implementations.
    [Show full text]
  • Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages
    Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages Corky Cartwright Mar 10-19, 2021 Overview I • In OO languages, OO data values (except for designated non-OO types) are special records [structures] (finite mappings from names to values). In OO parlance, the components of record are called members. • Some members of an object may be functions called methods. Methods take this (the object in question) as an implicit parameter. Some OO languages like Java also support static methods that do not depend on this; these methods have no implicit parameters. In efficient OO language implementations, method members are shared since they are the same for all instances of a class, but this sharing is an optimization in statically typed OO languages since the collection of methods in a class is immutable during program evaluation (computation). • A method (instance method in Java) can only be invoked on an object (the receiver, an implicit parameter). Additional parameters are optional, depending on whether the method expects them. This invocation process is called dynamic dispatch because the executed code is literally extracted from the object: the code invoked at a call site depends on the value of the receiver, which can change with each execution of the call. • A language with objects is OO if it supports dynamic dispatch (discussed in more detail in Overview II & III) and inheritance, an explicit taxonomy for classifying objects based on their members and class names where superclass/parent methods are inherited unless overridden. • In single inheritance, this taxonomy forms a tree; • In multiple inheritance, it forms a rooted DAG (directed acyclic graph) where the root class is the universal class (Object in Java).
    [Show full text]
  • Multiple Inheritance and the Resolution of Inheritance Conflicts
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2005 Vol. 4, No.2, March-April 2005 The Theory of Classification Part 17: Multiple Inheritance and the Resolution of Inheritance Conflicts Anthony J H Simons, Department of Computer Science, University of Sheffield, Regent Court, 211 Portobello Street, Sheffield S1 4DP, UK 1 INTRODUCTION This is the seventeenth article in a regular series on object-oriented theory for non- specialists. Using a second-order λ-calculus model, we have previously modelled the notion of inheritance as a short-hand mechanism for defining subclasses by extending superclass definitions. Initially, we considered the inheritance of type [1] and implementation [2] separately, but later combined both of these in a model of typed inheritance [3]. By simplifying the short-hand inheritance expressions, we showed how these are equivalent to canonical class definitions. We also showed how classes derived by inheritance are type compatible with their superclass. Further aspects of inheritance have included method combination [4], mixin inheritance [5] and inheritance among generic classes [6]. Most recently, we re-examined the ⊕ inheritance operator [7], to show how extending a class definition (the intension of a class) has the effect of restricting the set of objects that belong to the class (the extension of the class). We also added a type constraint to the ⊕ operator, to restrict the types of fields that may legally be combined with a base class to yield a subclass. By varying the form of this constraint, we modelled the typing of inheritance in Java, Eiffel, C++ and Smalltalk.
    [Show full text]
  • Dynamic Object-Oriented Programming with Smalltalk
    Dynamic Object-Oriented Programming with Smalltalk 1. Introduction Prof. O. Nierstrasz Autumn Semester 2009 LECTURE TITLE What is surprising about Smalltalk > Everything is an object > Everything happens by sending messages > All the source code is there all the time > You can't lose code > You can change everything > You can change things without restarting the system > The Debugger is your Friend © Oscar Nierstrasz 2 ST — Introduction Why Smalltalk? > Pure object-oriented language and environment — “Everything is an object” > Origin of many innovations in OO development — RDD, IDE, MVC, XUnit … > Improves on many of its successors — Fully interactive and dynamic © Oscar Nierstrasz 1.3 ST — Introduction What is Smalltalk? > Pure OO language — Single inheritance — Dynamically typed > Language and environment — Guiding principle: “Everything is an Object” — Class browser, debugger, inspector, … — Mature class library and tools > Virtual machine — Objects exist in a persistent image [+ changes] — Incremental compilation © Oscar Nierstrasz 1.4 ST — Introduction Smalltalk vs. C++ vs. Java Smalltalk C++ Java Object model Pure Hybrid Hybrid Garbage collection Automatic Manual Automatic Inheritance Single Multiple Single Types Dynamic Static Static Reflection Fully reflective Introspection Introspection Semaphores, Some libraries Monitors Concurrency Monitors Categories, Namespaces Packages Modules namespaces © Oscar Nierstrasz 1.5 ST — Introduction Smalltalk: a State of Mind > Small and uniform language — Syntax fits on one sheet of paper >
    [Show full text]
  • Multiple Inheritance
    Multiple Inheritance [email protected] Text: Chapter11 and 21, Big C++ Multiple Inheritance • Inheritance discussed so far is Single Inheritance • If a class has only one super class, then it is Single Inheritance • C++, also support Multiple Inheritance , i.e., when a class has more than one parent class Multiple Inheritance • Some of examples are- – Faculty could be Alumnus and Employee in DIICTian scenario – Head-Engineering , needs to be Manager and Engineer both – A CustomerEmployee would be Employee (a Person too), and Customer (a Person too)– forms diamond inheritance Here is how we have multiple inheritance in C++ class C : public A, public B { } • In this case, C inherits from A and B both … “public” Example: Multiple Inheritance Consider Example given • What methods class C has? • What is their visibility in class C? • What data members class C has? • What is their visibility in class C? Example: Multiple Inheritance Issues in Multiple Inheritance : Name ambiguity Base classes A and B of C both has getX() method Issues in Multiple Inheritance : Diamond Inheritance • Class B1 and B2 inherits from L, and • D inherits from B1 and B2, both • Therefore, in D, L inherits twice • It brings in some issues, consider example on next slide • What data and function members C has? • What is their visibility? Issues in Multiple Inheritance : Diamond Inheritance • Class D has – two copies of data ax – Ambiguous method names getX(), getAX() • Two copies of same variable should be more critical Issues in multiple inheritance Virtual Inheritance • C++ addresses this issue by allowing such base (being inherited multiple times) class to be virtual base class • As a result all virtual occurrences of the class throughout the class hierarchy share one actual occurrence of it.
    [Show full text]
  • Nested Class Modularity in Squeak/Smalltalk
    Springer, Nested Class Modularity in Squeak/Smalltalk Nested Class Modularity in Squeak/Smalltalk Modularität mit geschachtelten Klassen in Squeak/Smalltalk by Matthias Springer A thesis submitted to the Hasso Plattner Institute at the University of Potsdam, Germany in partial fulfillment of the requirements for the degree of Master of Science in ITSystems Engineering Supervisor Prof. Dr. Robert Hirschfeld Software Architecture Group Hasso Plattner Institute University of Potsdam, Germany August 17, 2015 Abstract We present the concept, the implementation, and an evaluation of Matriona, a module system for and written in Squeak/Smalltalk. Matriona is inspired by Newspeak and based on class nesting: classes are members of other classes, similarly to class instance variables. Top-level classes (modules) are globals and nested classes can be accessed using message sends to the corresponding enclosing class. Class nesting effec- tively establishes a global and hierarchical namespace, and allows for modular decomposition, resulting in better understandability, if applied properly. Classes can be parameterized, allowing for external configuration of classes, a form of dependency management. Furthermore, parameterized classes go hand in hand with mixin modularity. Mixins are a form of inter-class code reuse and based on single inheritance. We show how Matriona can be used to solve the problem of duplicate classes in different modules, to provide a versioning and dependency management mech- anism, and to improve understandability through hierarchical decomposition. v Zusammenfassung Diese Arbeit beschreibt das Konzept, die Implementierung und die Evaluierung von Matriona, einem Modulsystem für und entwickelt in Squeak/Smalltalk. Ma- triona ist an Newspeak angelehnt und basiert auf geschachtelten Klassen: Klassen, die, wie zum Beispiel auch klassenseitige Instanzvariablen, zu anderen Klassen gehören.
    [Show full text]
  • Reflection in Smalltalk
    Louvain School of Engineering (EPL) rev. 2012-07-03 Computing Science Engineering Department (INGI) . Reflection and Context-Oriented Programming (R+COP)with 2nd practical session ANSWERS Reflection in Smalltalk .This. session is a hopefully gentle introduction to Smalltalk’s meta-object protocol. You can use the tools of the Smalltalk environment to find answers to all questions. In particular: • Use the System Browser to navigate through classes, their methods and their hierarchies. The class browser also gives you valuable information on the overriding of methods and you can use the right-click menu on any method to explore senders and implementors of any messages used inside the method body. • Use the Finder tool to search for methods implementing a particular message. • Use the Inspector for individual objects, and evaluate expressions in the context of the inspected object. • Select an expression in any browser and use the right-click menu to browse all implementors or senders of the method. This session starts the exploration of reflection in Smalltalk by considering class instantiation, class inheritance, and the interaction between these two concepts. The second part of the session focuses on structural and behavioural reflection. Smalltalk Kernel: Instantiation Relationship 1. What is the class of 1984? Which message can you send to obtain the class of an object? Apply this message to 1984 and inspect the result. Inside the inspector, what do you conclude from evaluating and printing the result of self inside the lower-right text pane? The message that retrieves the class of an instance is class. If you inspect the result of 1984 class, you will obtain an inspector window with a SmallInteger class as window title and self bound to SmallInteger, as you can check by printing self.
    [Show full text]
  • Object Oriented Perl: an Introduction
    Object Oriented Perl: An Introduction Object Oriented Perl: An Introduction Abram Hindle Department of Computer Science University of Victoria [email protected] July 13, 2004 Abram Hindle 1 Object Oriented Perl: An Introduction This Presentation • What am I going to cover? – OO Intro – Packages – References – Constructor – Attributes – Methods – Inheritance – Fun Stuff – Getting Help – Conclusions – References Abram Hindle 2 Object Oriented Perl: An Introduction OO Introduction • What are objects? – A combination of attributes and functions associated with those attributes. Objects can have state, identify and behaviors. You can execute actions associated with objects. e.g. A dog object could bark. Effectively objects are instances of Classes. • What are classes? – The definition or blueprint for an object. http://www.justpbinfo.com/techdocs/ooterms.asp Abram Hindle 3 Object Oriented Perl: An Introduction OO Introduction • Why use Object Oriented Programming – OOP helps us organize our code and split our problems up into smaller blocks. – OOP is the current dominant programming style. – OOP seems to be the best that we currently have in imperative programming. – With OOP we gain useful things like polymorphism, encapsulation and other big words/concepts. Abram Hindle 4 Object Oriented Perl: An Introduction Packages • What are Packages? – The main way code is organized in Perl is with packages. – Sample Package: ∗ package Name; use strict; #save us debugging time ...code... 1; # outdated, used for a return from a use. – More than 1 package can exist in a file. Usually packages are saved into .pm files like Name.pm Abram Hindle 5 Object Oriented Perl: An Introduction Packages • More Details... – Our Class Names will be the package name.
    [Show full text]
  • An Exemplar Based Smalltalk
    An Exemplar Based Smalltaik Will R. LaLonde, Dave A. Thomas and John R. Pugh School of Computer Science Carleton University Ottawa, Ontario, Canada KIS 5B6 Abstract Two varieties of object-oriented systems exist: one In this paper, we detail some of the Smalltalk deficiencies based on classes as in Smalltalk and another based on that are a direct result of its class based orientation and describe exemplars (or prototypicai objects) as in Act/l. By converting how a more general and flexible system is obtained by Smalltalk from a class based orientation to an exemplar base, changing its underlying organizational base from classes to independent instance hierarchies and class hierarchies can be exemplars. The work is relevant to the evolution of any provided. Decoupling the two hierarchies in this way enables object-oriented system including the Flavour system in Lisp the user's (logical) view of a data type to be separated from the [Weinreb 807, Loops [Bobrow 81], Trellis [O'Brien 857, and implementer's (physical) view. It permits the instances of a more conventional languages being retro-fitted with class to have a representation totally different from the object-oriented facilities; e.g., C [Cox 84], Pascal [Tesler 847, instances of a superclass. Additionally, it permits the notion of Forth [Duff84], and Prolog [Shapiro 83, Vaucber 867. multiple representations to be provided without the need to Exemplar based systems include Act/l[Lieberman 81, introduce specialized classes for each representation. In the Smallworld [Laffgl], Thinglab [Borning 827, and Actra context of multiple inheritance, it leads to a novel view of [Thomas 857.
    [Show full text]