CS 330 Lecture 39 – Inheritance
Agenda
- what ?s
- why inheritance?
- how is inheritance done?
- inheritance gotchas
- virtual
- override
- is-a vs. has-a
TODO
- I’ve added a Wasd grader and fixed some omissions in the specification. Make you pull these down.
- One more 2-participation point extra credit opportunity for those of you who couldn’t make the evening talks: make two models in Madeup. The objects must be reasonably interesting and not just random globs of triangles. At least one must be an everyday object that you “reverse engineer” into an algorithm. Find documentation under the About menu. Email me the Madeup source code before the Monday of finals week.
Note
Today we focus on one of those pillars of object-oriented programming: inheritance. We first set a foundation for our discussion by thinking about a couple of questions:
- Why do we use inheritance in our programming languages?
- How is it implemented?
As handy as inheritance is, it’s a feature that brings with it some issues. We’ll walk through a gallery of those issues in our discussion today.
Gotchas
Virtual
What happens when we run the following code?
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'
We probably don’t get the output that you expect. In C++, what method is called is by default determined solely by the compile-time type of the invoking object. In this case, the compile-time type is Parent, so we call Parent::foo. What you are probably used to from Java is a method’s determination based on the run-time type. To get that, we need to mark foo as virtual.
Override
What happens when we run this code?
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'
When overriding, it’s easy to alter the method signature to the point where you’ve introduced a completely independent method without realizing it. Many languages let you tag your code to make your intentions of overriding clear. In Java, we use @Override. In C++11, we use override. If the compiler detects that we haven’t really overridden anything, we get a compilation error.
Is-a vs. Has-a
Probably the biggest criticism of inheritance is that we use it as a means for code reuse without realizing the implications it has on the problem we are trying to model. By inheriting a superclass, we inherit not only the implementation we want to reuse, but also the interface. This can expose us to some vulnerabilities. We’ll look at one such example with vectors in Ruby and another for a raffle class in C++.
One fix is to favor composition over inheritance, modeling a has-a relationship instead of an is-a relationship. This forces us to explicitly delegate tasks to the composite objects. C++ provides another possible solution, which I think is overlooked: private inheritance.
Code
parentchild.cpp
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'
shaper.cpp
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'
v.rb
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'
raffle.cpp
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information
from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from ./coderay:24:in `'