[music]. In this segment, I want to continue our

study of subclassing with two classes that override methods of the superclass in

interesting ways. And particularly, the second one will be

much more interesting, because it will use the key idea of dynamic dispatch which is

at the heart of object-oriented programming.

So let me show you the code. We'll do most of it that way.

Here is this class Point that we're familiar with and have been using.

Remember, it has getters and setters for x and y, and has two different ways of

computing the distance from the origin. The first way just directly accesses

instance variables x and y. The second way uses the objects own getter

methods by calling self dot x and, and self dot y with no arguments.

So that's a Point class. Now let's consider a rather controversial

subclass. I'll explain why in just a second, which

are three-dimensional points. So in this subclass, we, in addition to

having an x-coordinate and a y-coordinate, have a z coordinate, which is for the

height to a point in three-dimensional space.

So I just add getter methods for z and setter methods as well.

And then, I change via overriding the initialize method to actually require

three arguments. I used super here so that the initialized

method in the Point class can be used to initialize x and y, and then, I set at z

equal to the z argument. Okay?

So now, I also need to override distFromOrigin and distFromOrigin2.

These need to do different things for a three-dimensional point.

It turns out the distance from the origin in three-dimensional space is the square

root of x squared plus y squared plus z squared.

I could implement those directly, and maybe I could do that.

It would be even shorter here, but I decided to show super in a similar way.

So, for distance from origin, I could get the distance in terms of the x and

y-coordinate by calling super here, that will call the distFromOrigin method.

In the superclass, let that be in this local variable d, and then take the square

root of d times d plus at z times at z and that would get me the proper distance.

For distFromorigin2 I continue this approach of using as helper methods, my

own getter methods. And so, I end up with a similar thing,

except I call distFromOrigin2 in the super class.

And then, add to that the result of calling the z method, calling the z

method, multiplying them together and then I take the square root.

So why is this controversial? Oh, people have been arguing about this

for decades. You could certainly make an argument that

it's a hack. It's an abusive subclassing to treat

three-dimensional points as points, because they really are a different thing.

It's not clear that a point in three-dimensional space is a point in

two-dimensional space. They're kind of fundamentally different

things, whereas other people argue no, no, no that makes perfect sense.

First of all, you get lots of code reuse and we like code reuse.

And moreover, you can think of it as a two-dimensional plane.

Maybe it's the projection of the point down onto the xy plane.

It's the equivalent of treating the z coordinate as zero.

Other people would argue that if that's how you feel about it, that's not how

these distFromOrigin methods behave. They do not return the distance from the

origin of that projected point, they return it in three-dimensional space and

you can argue about this all day long. I just want to argue here that, even if

this is poor style, it does help us learn the semantics of overwriting.

That when I create an instance of 3D point.

I inherit the methods xx equal y and y equal.

I override the methods initialize distFromOrgoin, distFromOrigin2.

And I add the methods z and z equal. And that is the definition of the methods

defined for a 3D point. So it's a good example of how overriding

occurs. In fact, I want to argue that it's a

fairly simple example. Okay.

Because with the examples so far, an object like in the instance of 3D point is

really not that different from a function closure.

A function closure just has one method calling, call me, whereas a 3D point has,

I don't know, eight or nine methods distFromOrigin2 z equals and so on.

Fine. The object has explicit instance variables

at x, at y, at z, whereas a closure has all those things in the environment that

it's allowed to use as it's sort of private state.

Fine, that's a moderate difference. We have this inheritance which let us

inherit things from the superclass, but that's, as I've shown it so far, really

just code reuse convenience. But there's a huge difference between

subclassing and closures, like in functional languages, which is what I'm

about to show you and that is there are ways to use overriding.

That can make a method you inherit from the superclass, still call different

methods in the subclass, and this is the thing that object-oriented programming

does differently than none object languages.

And so I want to emphasize that point, and I will do that, pardon the pun, emphasize

that point, sorry with this final class, PolarPoint.

So if you remember your high school geometry?

If not, bear with me. A PolarPoint is not represented by an

x-coordinate or y-coordinate. It's represented by a radius, a distance

from the origin r, and a theta, the angle of, of the point from, from flat.

So you represent it with an r and a theta. So here I am having Polar, PolarPoint

subclass point. But I'm going to override a bunch.

I'm going to override just about everything I'm going to have an initialize

method that instead of taking an x and a y, takes an r and a theta.

And initializes different instance variables.

Add r and add theta. Now, this is actually interesting.

My instances of PolarPoint won't even have instance variables x and y.

In most object-oriented programming languages, it, it would have them, but not

use them. Here, because of how Ruby does instance

variables it doesn't even have them, I'm just using different instance variables in

my subclass. So it turns out that I need to override

xy, x equal, and y equal, because I need to compute those methods differently when

my internal representation uses an r and a theta instead of an x and a y.

And the trigonometry is that the way you compute the value of the x-coordinate is

you return the radius times the cosine of the angle.

So, here is r times cosine theta, and the y is r times sine of theta.

Don't worry, you won't be tested on the trigonometry.

Just point, just pointing out that to the client, these look like getter methods,

but they're actually performing in an interesting computation.

Setter methods are actually a little more complicated.

If you want to set the x value in terms of some new x value you still have the old y

value. And you have to do a bunch of stuff with

arctangent and square root and all sorts of stuff.

I do believe this works. I'm just using this built-in y getter

methods. I'm calling this method here.

I'm storing at a local variable so I don't call y more than once, even though, I use

b multiple times and trust me that the math is correct.

Y equals is similar we do basically the same computation to set the new y field.

Now, for the interesting stuff. Let's override distFromOrigin and

distFromOrigin2. Well, it turns out the entire advantage of

a polar representation of a point is the distFromOrigin is trivial.

That's exactly what the r instance variable holds.

So, we need to do this override. If you look up in the superclass, this

computation, sorry, that's 3D point. This computation would be wrong.

We would go to read the x field or the at y field, they are not even there, we would

get nil back. If you try to multiply nil, you get an

error message. So it's essential that we do this

override. But now, the fascinating part is that

distFromOrigin2 doesn't need overriding. We could override it if we want, but it

works as is and this is the thing I want to emphasize to you.

If you look at distFromOrigin2, what it does when called is call self dot x and

self dot y, and then compute with the result.

Even though, distFromOrigin2 is inherited from the Point class, it is now down here,

part of the PolarPoint class. And so, when we execute those calls to

self dot x and self dot y on an Instance of PolarPoint, we get this code and this

code, these methods and therefore this will work.

Let me prove that to you. This is the key example.

I've already loaded the file. I could make a PolarPoint dot new 4,

comma, how about math pi over 4 ? So like this and it turns out I could ask

pp dot x and you get 2.82 and you could ask pp dot y and I get 2.82.

So what's happening here in the code is, even though, there's an instance variable

@r and an instance variable @theta, when I call the x method or the y method, I do

these computations and it turns out I get 2.8 from both of them.

If I ask pp dot distFromOrigin, I get 4 and that's because @r is 4.

And this code right here just returns it, it really is just a getter for r.

And now the interesting one, if I do distFromOrigin2 I do get 4, although, it

did some floating point computations, so I actually get 4.0.

And that is because I inherit distFromOrigin2, so I evaluate dist code.

But in an environment where the object itself is an instance of PolarPoint, so

when I say self dot c and self dot y, I execute this code down here, so I end up

taking r cosine theta, r sin of theta, squaring them, taking the square root and

I get the right answer, okay? So this is the key punchline, that when

you have a method that makes another call on the same object, when it uses self,

that self is the entire object. And if self is an instance of a subclass,

then you use the subclass' methods like the overridden x and y that we saw in our

definition of PolarPoint. That is the thing that distinguishes

object-oriented programming and subclassing from other things we've seen

in this course. So, I've now shown you an example.

And in the next segment, we can take a step back and give a more precise

definition of the semantics of method look up.

So, that we can understand this behavior precisely.