[MUSIC] In this segment, I want to start talking about subclassing. This is essential to Object Oriented Programming. It will be a major topic for us in a class. So this is really what Object Oriented Programming is all about. And since many of you seen a little P before, you've probably seen subclasses in Java/C#/C++/Python etc., and things in Ruby will be fairly similar but I think it will 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 a part of a class definition I just didn't tell you about yet, which is when you define a class, it always has a superclass so, you in a class definition right 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 is that 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 the 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 have to find 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 definitions. 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 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 sub classing. 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 sub classing 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 the class, which is of course, the entire purpose of a class definition. So, let me now show you the example that's already hinted out on the slide here. So, I have here a class point for representing a point on the plane, something with an x coordinate and a y coordinate. So it turns out that I can use this shorthand notation I've shown you before to define four methods. A getter and a setter for an x and a getter and a setter for a y. So for example, this defines method named x that returns the content of the at x instance variable. Here is my initialized method. It takes in two arguments. Maybe it will be easier to understand if I call them a and b and it just creates two instance variables, x and y, for this object then 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 0.00 in the plane. And if you remember your basic geometry, this is the square root of x2+y2. And this first method distFromOrigin 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 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, four method calls in here instead of the simpler approached in distFromOrigin of this reading the instance variables. So, that's a point. Now, what about a color point. So, this is a sub class 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 two methods, a getter and a setter for color. So this'll define a getter method color and a setter method color equal. And then I'm going to replace the initialize method to now be a method that expects either two or three arguments. And what it does is it first calls, I'll explain this super call in just a minute, to initialize the x and y instance variables. And, then it sets a color field equal to whatever the c value is. So, super is a keyword in Ruby, we have similar keywords in many object-oriented programming languages. It says I know I'm replacing my superclass's 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. That would be an infinite loop, right? A method 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've already loaded the file for you. And I could certainly make a Point Object by just calling the new for point and I can make a color point, and that will work fine as well. How about 0,0 and red. And I could ask P what it's, 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 straight forward. I thought I would show you a couple other things related to some of the support for reflection in Ruby. So you can ask any object what is it's class. And p is a point. Cp is a color point, but here's something else you can do. You could say, well, your class is color point but that object has a method superclass. What is the superclass of the class color point, it's point. We could ask what the superclass of that is, it's object. We could ask what the superclass of that is, it's basic object. And we could ask the super class of that, it doesn't have one, it's nil. If you try to take super class of nil you'll get an error. There is no super class method defined on the nil object. Okay, so what are these things? What is a color point? 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 color point, cp, a point? And the answer is yes. This is something that subclasses give us, that a color point is a color point, 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 super class. 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 it's color point, 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 methods like is_a and instance_of is actually not particularly OOP style. To use this in your programs, you're giving up things like duck typing. You're saying I'm going to do something different based on whether something is actually a pointer, actually a color pointer, maybe just some other object that has methods like a getter 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 your 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 keyword instanceof, that is not like the instance_of? here it's actually like the is_a?. So different languages end up using the same words for exact opposite concepts in such as life. Java does not have a built in keyword for the Ruby's notion of instance of and that's considered a matter of style 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 a subclass as though they were instances of the superclass. And that's our introduction to subclassing.
