Topics on Inheritance

Document Sample
Topics on Inheritance Powered By Docstoc
					Topics on Inheritance

 Subtyping   and Code Reuse

 Typing   Conversions and Visibility

 Abstract   Base Classes

 Multiple   Inheritance

 Inheritance   and Design

 Detailed   C++ Considerations   ##
Traits Passed Through Inheritance

                                But Mommy, where
                                did my blue eyes
                                come from?

The Inheritance Mechanism

 Means  of deriving new class from existing
  classes, called base classes

 Reuses  existing code eliminating tedious,
  error prone task of developing new code

 Derived  class developed from base by adding
  or altering code

 Hierarchy of related types created that share
  code & interface ##
Single and Multiple Inheritance

Single inheritance occurs
  when single base class

Multiple inheritance occurs
 when more than
 one base class

Credit Cards - Single Inheritance

Same basic features

Each is a little different

Voice Mail - Multiple Inheritance

Voice mail has features
 of both mail and phone

Taxonomic Classification (1 of 3)

Elephant and mouse both mammals
     Descriptions succinct

Root concept "mammal"
     Higher vertebrates
     Nourish young using
     mammary glands

Taxonomic Classification (2 of 3)

        Warm blooded

        Higher vertebrate

        Nourish young with
         milk-producing glands

            Mouse            Elephant
Taxonomic Classification (3 of 3)

 InC++ terms, classes elephant and mouse
  derived from base class "mammal"

 In OOP terms, elephant ISA mammal describes

 Ifcircus had elephants, then object circus
  might have members of type elephant

 Class  circus HASA elephant describes subpart
  relationship ##
Virtual Member Functions

 Functions declared in base class and
  redefined in derived class

 Class hierarchy defined by public inheritance
  creates related set of user types, all of
  whose objects may be pointed at by a base
  class pointer

 By accessing virtual function through this
  pointer, C++ selects appropriate function
  definition at run-time ##
Pure Polymorphism

 Object being pointed at must carry around
  type information so distinction can be made
     Feature typical of OOP code

 Each   object "knows" how it is acted on

 Inheritancedesigned into software to
  maximize reuse and allow natural modeling
  of problem domain ##
The OOP Design Methodology

1. Decide on an appropriate set of types

2. Design in their relatedness

3. Use inheritance to share code
   among classes

A Derived Class

  Class    derived from an existing class
class classname:(public|protected|private)opt basename
     member declarations

  Keyword   class replaced by struct with
     members public by default

  Keywords     public, protected, and private
     to specify how base class members are
     accessible to derived class ##                      13
Students and Graduate Students

A Base Class: student

class student {
   enum year { fresh, soph, junior, senior,
         grad };
   student(char* nm, int id, double g,
       year x);
   void print() const;
   int student_id;
   double gpa;
   year y;
   char name[30];
A Derived Class: grad_student

class grad_student : public student {
   enum support { ta, ra, fellowship, other };
   grad_student(char* nm, int id, double g,
      year x, support t, char* d, char* th);
   void print() const;
   support s;
   char dept[10];
   char thesis[80];

Inheriting from the Base Class

 Derived  class is modification of base class
  that inherits public and protected members
  of base class

 In grad_student, student members are
       student_id   gpa
       name         year
       print   ##

Add New Members in Derived Class

 Derived class adds new members to existing
  class members

 grad_student has three new data members
  and redefined member function
    print()   ##

Benefits of Inheritance

 Code    is reused
     grad_student uses tested code from student

 Reflects   relationship in problem domain
     Special grouping grad student outgrowth of real
     world and treatment of this group

 Polymorphic   mechanisms allow client code to
  treat inherited class as subtype of base class
     Simplifies code, maintains subtype distinctions

Public Inheritance (is a subtype)

 Publicly   inherited remain public

 Private   members can't be inherited

 Protected   members remain protected ##

      student                 shape

   grad_student            ellipse     polygon

Private Inheritance (is not a subtype)

 Public   members become private

 Protected   members become private

 Code   reuse mechanism ##

                  generic tree


                   string tree
Typing Conversions and Visibility

 Publicly   derived class is subtype of base

 Variable of derived class treated as if it were
  base class type

 Pointer type pointer-to-base-class can point
  to objects of derived class type
     Subtle implicit conversions occur between base
     and derived type
     Difficult to follow what member is accessed if
     base and derived class overloaded same member
     name ##                                          22
Students and Graduate Students

                         In many respects, they
                         are the same, but in
                         some they differ.

More on the student Program (1 of 7)

student::student(char* nm, int id,
           double g, year x)
     :student_id(id), gpa(g), y(x)
  strcpy(name, nm);

 Constructor   for base class does series of
  simple initializations

 Calls   strcpy() to copy student's name   ##

More on the student Program (2 of 7)

//publicly derived
grad_student::grad_student(char* nm, int id,
         double g, year x, support t,
         char* d, char* th)
        :student(nm, id, g, x), s(t)
{ strcpy(dept, d);
  strcpy(thesis, th); }

 Constructor    for student invoked as part of
  initializer list
      Logically base class object needs to be
      constructed first before object can be completed
More on the student Program (3 of 7)

 Reference to derived class may be implicitly
  converted to a reference to public base class

grad_student gs("Morris Pohl", 200, 3.2564,
grad, ta, "Pharmacy", "Retail Pharmacies");
student& rs = gs; //alias
student* ps = &gs; //pointer init

 Variable   rs is reference to student
      Base class of grad_student is student Reference
      conversion is appropriate
More on the student Program (4 of 7)

void student::print()
  cout << name << " , " << student_id
    << " , " << y << " , " << gpa << endl;
void grad_student::print()
  student::print(); //base class info
  cout << dept << " , " << s << endl
     << thesis << endl;

         loop if not scope-resolved
 Infinite
  student::print()                           27
More on the student Program (5 of 7)

#include "student.h"
main()    //Test pointer conversion rules
  student s("Mae Pohl", 100, 3.425, fresh),
         *ps = &s;
  grad_student gs("Morris Pohl",200, 3.2564,
       grad, ta, "Pharmacy",
       "Retail Pharmacies"), *pgs;
  ps —> print();    //student::print
  ps = pgs = &gs;
  ps —> print();    //student::print
  pgs —> print(); //grad_student::print
More on the student Program (6 of 7)

 main() declares both class variables and
  pointers to them

 Conversion   rule - pointer to publicly derived
  class may be converted implicitly to pointer
  to its base class

 Pointer ps can point to objects of both
  classes, but pointer pgs can point only at
  objects of type grad_student ##

More on the student Program (7 of 7)

 First   ps -> print() invokes student::print

 ps = pgs = &gs; both pointers pointing at
  object of type grad_student and assignment
  to ps involves implicit conversion

 Second    ps -> print(); invokes student::print
       Irrelevant that pointer points at grad_student
       variable gs ##

 pgs   -> print(); invokes grad_student::print
Creating a New vect Class

                            “We can rewrite this
                            safe-array code to include
                            a new vect_bnd class with
                            dynamic bounds checking.
                            We’ll use vect as a base
                            class, and let vect_bnd use
                            inheritance so we don’t
                            have to repeat all the vect
                            code. It’s basic functions
                            serve our purposes

Dynamic Array Bounds (1 of 2)

 Subscripting   & assignment use these
     Right side, lvalue automatically dereferenced
     Left side specifies where value is stored

 Safe array vect_bnd produced by deriving it
  from vect and invoking appropriate
     function-header : base-class-name (args)    ##

Dynamic Array Bounds (2 of 2)

 Safe array has constructors, destructor and
  overloaded subscripting operator
     Constructors convert ordinary integer array to
     safe array by allocating sufficient memory

     Upper and lower bounds checked

     Subscript operator [] overloaded with function
     which tests for out-of-bounds condition on array
     access ##
Using Dynamic Array Bounds

 Reuse code and extend vect type to safe
  array with dynamic bounds
     More flexible and allows indices to correspond
     directly to problem domain

 Example:    Fahrenheit temperatures of water
  in its liquid state are is 32—212 degrees
     Lower bound of 32 and upper bound of 212
     Safe array vect checked array bounds for in
     range and created arrays using free store ##

Dynamic Array Bounds (1 of 8)

class vect {
public:         //constructors & destructor
   vect(); //create a size 10 array
   vect(int l); //create a size l array
   vect(const vect& v); //init by vect
   vect(int a[], int l); //init by array
   ~vect() { delete [] p; }
   int ub() const {return (size—1);}
   int& operator[](int i); //range checked
   vect& operator=(vect& v);
   vect operator+(vect& v);
   int *p; //base pointer
   int size;            //number of elements
};                                             35
Dynamic Array Bounds (2 of 8)

class vect_bnd: public vect {
   vect_bnd(int, int);
   int& operator[](int);
   int ub() const { return (u_bnd); }   //accessor
   int lb() const { return (l_bnd); }
   int l_bnd, u_bnd;
 Derived   type members l_bnd and u_bnd
   privately store lower and upper bounds
Dynamic Array Bounds (3 of 8)

 Derived type reuses base type's
  representation and code

 Derived class constructors invoke base class

 Syntax   is same as member initialization
 function header: base—class—name(args)   ##

Dynamic Array Bounds (4 of 8)

vect_bnd::vect_bnd() :vect(10)
{ l_bnd = 0;
  u_bnd = 9;              l_bnd                 u_bnd
                               01 2 3 4 5 6 7 8 9

vect_bnd::vect_bnd(int lb, int ub) :
           vect(ub — lb + 1)
{ l_bnd = lb;
  u_bnd = ub;
 Additional   code initializes bound's pair

 Derived    constructors call base constructors        38
Dynamic Array Bounds (5 of 8)

 Alternatively,   could be done in initializing list

vect_bnd::vect_bnd(int lb, int ub)
     vect(ub — lb + 1), l_bnd(lb),
     u_bnd(ub) {}

Dynamic Array Bounds (6 of 8)

int& vect_bnd::operator[](int i)
   if (i < l_bnd || u_bnd < i) {
     cerr << "index out of range" << endl;
   return (vect::operator[](i — l_bnd));

 Reuse    code in overloading indexing operator
       Very inefficient - checking bounds twice
Dynamic Array Bounds (7 of 8)

 Toavoid inefficient double bounds check,
  make two changes

 Firstchange access privilege of vect::p to
  protected so derived class has direct access
  to previously private implementation of vect

 Allows  us to make second change of using p
  in vect_bnd::operator[]() ##

Dynamic Array Bounds (8 of 8)

int& vect_bnd::operator[](int i)
   if (i < l_bnd || u_bnd < i) {
      cerr << "index out of range\n";
   return (p[i — l_bnd]);

Determining Access Privilege

 Tradeoff   in code reuse and efficiency

 Inheritancerequires thinking about three
  access boundaries

 What is to be strictly private and what is to
  be protected depends on what is reusable ##

Dynamic Virtual Function Selection

 Typicallybase has virtual function and
  derived have their versions of function

 Pointer to base class can point at either base
  or derived class objects

 Member   function selected depends on class
  of object being pointed at, not on pointer

 In absence of derived type member, base
  class virtual function used by default ##     44
Virtual & Overloaded Function Selection

 Overloaded  member function is compile-time
  selected based on signature

 It   can have distinct return types

 Once  declared virtual, this property is
  carried along to all redefinitions in derived
       virtual modifier not needed in derived functions

Virtual Function Selection (1 of 2)

#include <iostream.h>

class B {
   int i;
   virtual void print_i() const
     { cout << i << " inside B" << endl; }
class D: public B {     //virtual too
   void print_i() const
    { cout << i << " inside D" << endl; }
};                                           46
Virtual Function Selection (2 of 2)

int main()                                   1 inside B
{                                            2 inside D
   B b;
   B* pb = &b;       //point at a B object
   D f;

    f.i = 1 + (b.i = 1);
    pb —> print_i(); //call B::print_i()
    pb = &f;         //point at a D object
    pb —> print_i(); //call D::print_i()

Comments on the virt Program

 Different   print_i() executed
     Dynamically selected on object pointed at

 "Objectsent message print_i and selects its
  corresponding version of method"
 Pointer'sbase type is not determining
  method (function) selection
 Different class objects processed by
  different functions at run-time
 ADTs, inheritance, and process of objects
  dynamically are essentials of OOP ##           48
Confusion with Overloading (1 of 2)

 Member    function overloading and virtual
   functions cause mix-ups and confusion
class B {
   virtual foo(int);
   virtual foo(double);
class D: public B {
};                                             49
Confusion with Overloading (2 of 2)

  D d;
  B b, *pb = &d;;         //selects B::foo(double);;         //selects D::foo(int);
  pb —> foo(9.5); //B::foo(double);

 Base class function B::foo(int) overriden in
  derived class
 Base class function B::foo(double) hidden in
  derived class                                   50
Restrictions on virtual Functions

 Only   non-static member functions virtual

 Virtual   characteristic is inherited
     Derived class function automatically virtual
     virtual keyword not needed

 Constructors    cannot be virtual

 Destructors    can be virtual   ##

A Shape Hierarchy


           Polygon               Oval

Triangle                                Circle

Using virtual (1 of 2)

class shape {
   virtual double area() const {return (0);} protected:
   double x, y;

class rectangle: public shape {
   double area() const {return (height * width);}
   double height, width;
Using virtual (2 of 2)

class circle: public shape {
   double area() const
    { return (PI * radius * radius); }
   double radius;

Comments on the shapes Program

 Virtual   function allow run-time decisions

 Different   shapes derived from shape base

 Derived classes correspond to important,
  well understood types of shapes

 Added     to by deriving further classes

 Area    calculation is a local responsibility ##
Client Code for shapes

shape* p[N];
for (i = 0; i < N; ++i)
  tot_area += p[i] —> area();

 Advantage  that client code need not change
  if new shapes added

 Change   managed locally and propagated
  automatically by polymorphic character of
  client code
Classes and Virtual Functions

 Rootclass of hierarchy usually contains
  number of virtual functions to provide
  dynamic typing

 Pure  virtual function provides dummy
  functions as placeholders in base class
  which had specific functions in derived
  classes ##

Pure Virtual Functions

 Pure   virtual function has body
  virtual function prototype = 0;

 Pure virtual function used to defer
  implementation decision of the function

 In   OOP terminology - deferred method    ##

Abstract Base Classes

 Class   with at least 1pure virtual function

 Useful to have root class for type hierarchy
  as abstract class

 Basic common properties of derived classes
  but cannot itself declare objects

 Declare pointers that access subtype objects
  derived from abstract class ##
Using Abstract Base Classes (1 of 2)

 Primitive form of ecological simulation in
  which world has different forms of life

 Abstract    base class is living
     Interface inherited by various forms of life

 Fox as archetypal predator and rabbit as its

 Rabbit   eats grass   ##
Using Abstract Base Classes (2 of 2)

Predator - Prey (1 of 5)

hierarchy living
const int N = 40; //size of square board
const int DRAB = 3, DFOX = 6, CYCLES = 5;

class living;         //forward declaration
typedef living* world[N][N];

 Akin   to Conway's "Game of Life" simulation
 Rules for who lives in next cycle given
  populations in neighborhood of square          62
Predator - Prey (2 of 5)

class living {         //what lives in the world
   virtual state who() = 0;      //state id
   virtual living* next(world w) = 0;
   int    row, column;           //location
   void sums(world w, int sm[]);

 Virtual functions incur small added run-time
   cost over normal member functions, use only
   when necessary
Predator - Prey (3 of 5)

//currently only plant life

class grass : public living {
   grass(int r, int c):{row=r; column=c;}
   state who() { return GRASS; }
   living* next(world w);

 Similar   code developed for fox and rabbit

Predator - Prey (4 of 5)

//nothing lives here
class empty : public living {
   empty(int r, int c): {row=r; column=c;}
   state who() { return EMPTY; }
   living* next(world w);

 Inheritance    hierarchy one level deep
 Design  allows other forms of predator, prey,
  and plant life development using further level
  of inheritance
Predator - Prey (5 of 5)

living* grass::next(world w)
  int sum[STATES];
  sums(w, sum);
  if (sum[GRASS] > sum[RABBIT]) //eat grass
     return (new grass(row, column));
     return (new empty(row, column));
 Ifmore grass than rabbits, grass remains;
  otherwise grass eaten
 Rabbits die of old age or eaten by foxes foxes
  die of overcrowding and old age             66
Comment on the living Program

 More  interesting to simulate other behaviors
  such as sexual reproduction, where animals
  have gender and can mate

 Array   world is container for life forms
     Has responsibility for creating current pattern
     Needs to have ownership of living objects to
     allocate new ones and delete old ones

 Rulesin versions of next() determine possibly
  complex set of interactions ##
Multiple Inheritance

 Derived   class from more than one base

 Can’t be circular, so no class may, through its
  inheritance chain, inherit from itself

           arise when deriving identically
 Ambiguities
  named member from different classes

 Virtualinheritance eliminated duplication of
  subobjects having same name

 Constructor invoke order may cause problems,
  and should be explicit ##                      68
Using Multiple Inheritance

       tools      parts      labor


Multiple Inheritance (1 of 3)

#include <iostream.h>

class tools {
   int cost() { return (1); }
class labor {
   int cost() {return (2); }
class parts {
   int cost() {return (3); }
Multiple Inheritance (2 of 3)

class plans : public tools, public parts,
          public labor {
   int tot_cost()
    {return (parts::cost()+labor::cost());}

 Header     has base classes, privacy designation

 Publicly    inherits members of all base classes

Multiple Inheritance (3 of 3)

{ int price;
  plans* ptr;
  tools t; labor l;
  parts p; plans pl;
  ptr = &pl;
  price = ptr -> cost(); //ambiguous cost
  price = ptr -> tools::cost();
  cout << "\ntools cost = " << t.cost()
   << " labor cost = " << l.cost()
   << " parts cost = " << p.cost()
   << " plans cost = " << pl.tot_cost()
   << " total cost = " << price << endl;
Virtual Inheritance

 Two base classes derived from common

 Ifboth base classes used in ordinary way by
  derived class, that class will have two
  subobjects of common ancestor

 Duplication, if not desirable, eliminated by
  using virtual inheritance ##

Using Virtual Inheritance (1 of 2)

class under_grad: public virtual student {

class grad: public virtual student {


class attendee: public under_grad,
          public grad {
Using Virtual Inheritance (2 of 2)


            under_grad         grad


  Without use of virtual, class attendee would
  have objects of class::under_grad::student
  and class::grad::student

Constructors and Destructors

   With all these classes
   interacting, how do the
   constructors and
   destructors get

Constructor Destructor Execution (1 of 4)

 Order   for initializing constructors
     Base classes initialized in declaration order
     Members initialized in declaration order
 Virtual base classes have special precedence
  & are constructed before their derived
     Constructed before non-virtual base classes
     Construction order depends on their DAG
     It is a depth-first, left-to-right order
     Destructors invoked in reverse order of
     constructors ##                                 77
Constructor Destructor Execution (2 of 4)

class tools {
class parts {
class labor {
Constructor Destructor Execution (3 of 4)

class plans: public tools, public parts, public labor {
   special a;           //class with constructor
   plans(int m): tools("lathe"),
       parts("widget"), labor(m), a(m)

 Oldstyle list implicitly called base class
  constructor is allowed for SI - poor style
Constructor Destructor Execution (4 of 4)

 Constructor    initializing list and member
  initializing list in declaration order
     Good style - avoids confusion and should match
     declaration order as documentation

 Since its constructor was last, ~a()
  destructor is invoked first, followed by
  ~labor(), ~parts(), ~tools(), and ~plans()

 Example  of MI in iostream.h - derived from
  istream and ostream ##
Inheritance And Design

Inheritance is a code-sharing technique

Inheritance reflects understanding of problem

Inheritance reflects relationships between
  parts of problem space

The ISA Relationship

 Public inheritance expression of ISA
  relationship between base and derived

 Rectangle   is shape
     Make shape superclass
     Allow behavior described by public member
     functions interpretable on objects within type
     Subclasses derived from it share its interface   ##

Design Tradeoffs

 Design   involves tradeoffs between objectives

 Generality   at odds with efficiency

 Use   class hierarchy for ISA relationships
    Compartmentalize coding relationships
    Coding inefficiencies having various layers of
    access to (hidden) state description
    Simplifies overall coding process   ##

Drawing Different Shapes

Designing a Shape Drawing Package

 Need    not anticipate future additional shapes

 Class  developer imports base class "shape"
  interface and provides code that implements
  operations such as "draw"

 What is primitive or common remains

 Also   unchanged is clients use of package   ##

Concerns Affecting Class Development

 Undue amount of decomposition imposes its
  own complexity

 Granularity   decision
    Classes highly specialized do not provide enough
    Better folded into larger concept   ##

Single vs.. Multiple Inheritance

 Single   Inheritance    Multiple Inheritance

Credit Cards               Voice Mail
Same basic features but    Features of both mail phone
each a little different

Deciding on Which Inheritance to Use

 Generally    types are best understood as SI

 Some programmers prefer SI and
  aggregation to MI and composition

 MI   presents problems for type theorist
       A student might be derived from person
       An employee might be derived from person
       What about a student-employee? ##
What About Bats?

 Isvampire bat mammal that flies, flying
  machine that is mammal, or flying machine
  and mammal?

 Depending  on what code is available,
  developing proper class for vampire bat
  might involve MI derivation or SI with
  appropriate HASA members ##

Subtyping Form

 ADTs  successful insofar as behave like
  native types

 Native types such as integer types in C act
  as subtype hierarchy

 Useful model for publicly derived type

 Promotes   ease of use through polymorphism

Flexibility in Design (1 of 2)

class Abstract_Base {
//interface — largely virtual
   Abstract_Base(); //default constructor
   Abstract_Base(const Abstract_Base&);
   virtual ~Abstract_Base();
   virtual void print() = 0;   //usual print
protected://replaces private - inheritance
private: //empty — avoid: constrains future
Flexibility in Design (2 of 2)

class D_is_AB: virtual public Abstract_Base {
   //interface — supports concrete instance
   D_is_AB();           //default constructor
   D_is_AB(const D_is_AB&);               //copy
   D_is_AB& operator=(const D_is_AB&);
   void print(); //usual print expectation
protected://replace private for inheritance
Comments on the abs_base Program

 Usual  to leave root of hierarchy as abstract -
  yields most flexible design

 Generallyno concrete implementation
  developed at this point

 Pure virtual functions preclude from
  declaring objects of this type

 print()   function is pure   ##

First Design Level is Public (1 of 2)

 Operations   expected of any subtype in

 Ingeneral, basic constructors expected and
  they may not be virtual

 Most  useful aggregates require explicit
  definition of assignment that differs from
  default assignment semantics ##

First Design Level is Public (2 of 2)

 Destructorvirtual - response at run-time
  and dependent on object's size

 Virtualpublic inheritance ensures that in MI
  schemes, no multiple copies of abstract base
  class ##

Multiple Inheritance Relationships

ISA       sub-type      "whale is mammal"

LIKEA     code-reuse    "bat is like airplane"

HASA      sub-element "a plane has motor"

Chief confusion is multiple inheritance in place
 of HASA

C++ and Virtual Functions

 Virtualfunction and derived instances having
  same signature must have same return type
        Virtual function redefinition is overriding
        Non-virtual member functions having same
        signature can have different return types

 Allmember functions except constructors,
  and overloaded new and delete can be virtual

C++ and Constructors and Destructors

 Constructors, destructors, and conversion
  functions do not have return types
     Return type of an overloaded new operator must
     be void*
     Return type of an overloaded delete operator
     must be void

 Constructors, destructors, overloaded
  operator=, and friends not inherited ##

Operator Overloading

=  , () , [] , and —> done only with non-
  static member functions

 new  and delete done only with static member

 Other  overloadable operators done with
  either friend, member, or ordinary functions


 Unionmay have constructors and destructors
 but not virtual functions

 Unioncannot serve as base class, nor can it
 have base class ##

C++ and Access Modification (1 of 2)

 With   public inheritance destroys subtype

 Can’t    broaden visibility

class B {
   int k;
   int j, n;
   int i;
};                                             101
C++ and Access Modification (2 of 2)

class D: public B {
   int m;
   B::n; //illegal protected access
          //cannot be widened
   B::j; //otherwise default protected

Summary of Inheritance (1 of 6)

 Inheritance is mechanism of deriving new
  class from old one
     Inherits base class code
     Typically modifies & extends base class

 Existing class added to or altered to create
  derived class

 Inheritanceallows creation of hierarchy of
  related ADTs that share code ##
Summary of Inheritance (2 of 6)

  Class    derived from existing class
class classname:(public|protected|private)         basename
     member declarations

  Keyword     class can be replaced by keyword
     struct, with implication that members by
     default public ##

Summary of Inheritance (3 of 6)

 Keywords   public, private, and protected
  available as visibility modifiers for class
     Public member visible throughout its scope
     Private member visible to other member
     functions within its own class
     Protected member visible to other member
     functions within its class and any class
     immediately derived from it

 Derived class has its own constructors,
  which invoke base class constructor ##          105
Summary of Inheritance (4 of 6)

 Specialsyntax to pass arguments from th
  derived class constructor back to base class
     function header: basename (argument list)

 Publicly   derived class subtype of its base

 Variable of derived class treated as if it were
  base class type

 Pointer to base class can point to objects of
  publicly derived class type ##                  106
Summary of Inheritance (5 of 6)

 Reference to derived class may be implicitly
  converted to reference to public base class

 Keyword  virtual is function specifier that
  provides mechanism to select at run-time
  appropriate member function
     Used only to modify member function
     declarations and is called overriding
     Pure polymorphism   ##

Summary of Inheritance (6 of 6)

 Possible  to declare reference to base class
  and initialize it to reference an object of
  publicly derived class
 Public   inheritance creates type hierarchy
     Generality from additional implicit type
     Run-time selection of overridden virtual functions

 ADTs, inheritance, ability to process objects
  dynamically are essentials of OOP ##