[music] In this segment, I want to start talking about subclassing. This is essential to object-oriented programming and will be a major topic for us in the class, so this is really what object-oriented programming is all about and since many of you have seen OOP before, you've probably seen subclasses in Java, C#, C++, Python, etc. And things in Ruby will be fairly similar, but I think it'll be useful to study things from a careful programming language perspective, and the fact that Ruby is a dynamic language will make things a little bit different, and also in many ways a little bit simpler. So, here's the idea of a subclass. It turns out there's part of a class definition that I just didn't tell you about yet. Which is when you define a class, it always has a superclass. So, you, in the class definition write a less than character and then the name of the superclass. We've been omitting this, in which case , the default in Ruby is that it's just like you wrote less than object where object is a class that's provided by default in the Ruby language. So, what's the purpose of this superclass? It turns out, it affects your class definition by including everything in the superclass. So, any methods defined in the superclass are also methods in the class you're defining with one important exception and that is that the class definition can override some of the methods. So, when you override a method you just define a different method with the same name and then the subclass has everything in the superclass except the replacements and additions, according to the class definition. So, we say that we inherit the methods from the superclass. We get them from our parent class, if you will. And then we can make changes, to add new methods and replace some of the methods we've inherited. By the way, if you've seen subclassing in other languages, you might be curious about fields or instance variables. Well, that doesn't make any sense in Ruby. In Ruby, what instance variables, instances of an, a class have is not part of the class definition. As we've seen, you just assign to instance variables and they come into being. And so, that happens in any object and nothing is changed once we introduce subclassing. When you create an object, initially, it has no instance variables. And then, every time you assign to one,it comes into being. I would also point out that in dynamically typed language. I would also point out that in dynamically typed language. I would also point out that in dynamically typed language, subclassing has nothing to do with any sort of type system, which obviously we don't have. Subclassing is purely about what methods are defined in a class, which is, of course, is the entire purpose of a class definition. So, let me now show you the example that's already hinted at on the slide here. So, I have here a class point for representing a points on the plane, something with a x-coordinate and a y-coordinate. So, it turns out that I can use this shorthand notation I've shown you before to define 4 methods, a getter and a setter for an x and a getter and a setter for a y. So, for example, this defines a method named x that returns the contents of the at x instance variable. Here is my initialized method, it takes in 2 arguments. Maybe it would be easier to understand if I called them a and b. And it just creates two instance variables, x and y, for this object. And initializes them to the contents of a and b. And then, just to keep things short, just two other methods, in addition to the four defined on this first line, and the initialize method, which is the fifth one. How about a method that takes no arguments and reports back the objects distance from the origin, from point 0,0 in the plane, and if you remember your basic geometry, this is the square root of x squared plus y squared, and this first method just from origin just calls the library method Math.sqrt with this argument, which is using the instance variables to get the x-coordinate and the y-coordinate multiplying and adding as appropriate. Very interesting to us in an upcoming segment, so I want to show it here. Is the second version of distfromorigin, which I'll just call distfromorigin2. That looks very, very similar except here, in this expression, I'm actually making four method calls. So, I'm making calls to self.x with no arguments and self.y with no arguments. So, 4 method calls in here, instead of the simpler approach in distfromorigin of just reading the instance variables. So that's a point, now, what about ColorPoint? So, this is a subclass of point, and it has everything that a point has, and then we're going to add two more methods and replace one method. So, this first line is going to add to methods, a getter and a setter for color, so this will define a getter method color, and a setter method color equal. And then, I'm going to replace the initialized method to now be a method that expects either two or three arguments and what it does is it first calls, I'll explain the super call in just a minute, to initialize the x and y instance variables. And then, it sets a color field equal to whatever this c value is. So, super is a keyword in Ruby, if similar keywords in many object-orientated programming languages that says, I know I'm replacing my superclass' method initialize and I want my replacement to use the old one as a helper method. So, if I wrote initialize here, that would not work, right? That would be an infinite loop, right, and that's it calling itself. But super is going to call the initialize method it defined in the point class and that will properly initialize the x and y instance variables. Okay. So, that's most of what I wanted to show you. Now, let's use this here in irb, so I have already loaded the file for you and I could certainly make a point object by just calling the new for point, and I could make it a ColorPoint. And that would work fine as well. How about 0,0 and red, okay? And I could ask p what's it I could call the x method on it, I would get back 0 and I could call cp.x and I would also get 0. I could ask cp.color and I would get red, if I ask p.color, I will get an undefined method, because instances of the point class do not have a method color. So, that's all fairly straightforward. I thought I would show you a couple other things related to some of the support for, for reflection in Ruby. So you can ask any object what is its class, and p is a point, cp is a ColorPoint. But here's something else you can do. You could say, well, your class is ColorPoint but that object has a method superclass. What is the superclass of the class ColorPoint, its point? We could ask what the superclass of that is, its object. We could ask what the superclass of that is, its basic object. And we could ask the superclass of that, it doesn't have one, it's nil. And if you try to take superclass to nil, you'll get an error there. There's no superclass method to find out the nil object. Okay, so what is, the, what are these things? What is a ColorPoint? Well, it turns out that if we ask let's take a regular point. There's an is_a method that takes a class object and returns true if the object is a point. So, that returns true and now the interesting question is, is a ColorPoint, cp, a point? And the answer is, yes. This is something that subclass give us, that, that a ColorPoint is a ColorPoint clearly, but it's also a point and it's also an object, okay? So, subclasses mean the instances of the subclass are also instances of the superclass. Now, there is a different operator in Ruby that makes this distinction. If I instead ask if cp is an instance of point, I get false. The only thing cp is an instance of is ColorPoint, it's exact class not counting any of the superclasses. So, that just shows that there really is a distinction going on here. And let me emphasize that just a little bit more with this slide here. The code here is mostly what I just showed you, maybe with a few slightly different examples. And using these method like is_a and instance_of is actually not particularly OOP style. If you use these in your programs, you're giving up things duck typing. You're saying, I am going to do something different based on whether something is actually a point or actually a ColorPoint or maybe just some other object that has methods like getters and setters for x and y and so on. But nonetheless, this is an interesting semantic point that we have methods that distinguish from, what is your exact class, what are you in instance_of from, including all of your superclasses which is what is_a does. So an instance of ColorPoint is also a Point and is also an Object. And for those of you who come from other languages, this is a little bit confusing in particular, in Java. There's a built in key word, instance of, that is not like the instance_of question mark, it's actually like the is_a. So, different languages end up using the same words for exact opposite concepts and such as life. Java does not have a built-in keyword, for the Ruby's notion of instance_of because is_a is usually what you want to use. Because that way, if you ask, is a point. You have some object, is it a point? You'll get true even for any subclasses. And that's considered good style because you should be able to use instances of the subclass as though there were instances of the superclass and that's our introduction to subclassing.
