[music] The question of when it is good style to use subclassing is an important
one, and you could have an entire course on object oriented design.
But here, I just want to answer the question for our simple example of points
and color points by considering some alternatives that we could have pursued
instead. So, remember what we did is we had a Point
class that had several methods to find, like getters and setters for x and y, as
well as from distance for the origin methods and we wanted a different class
that was very similar. That was a ColorPoint class that had all
of that, but also had a getter and setter for a color property.
And then, we had to change our initialize method to make sure that, that color was
properly initialized. So, it turns out here, subclassing worked
very well, it was convenient to reuse all that code from, from Point.
But in general, once programmers learn subclassing, they do often tend to overuse
it. All right.
Most people would agree that in large OOP applications, there tends to be more
subclassing than there probably should be. So, let me show you what else you could do
rather than subclassing in order to get code reuse, even though, in this case, as
we'll see sub classing is actually perfectly good style.
So, here's the first alternative, since we're in a dynamic language where we can
change class definitions anywhere in our program.
What if we, instead of creating a ColorPoint class, just went and added new
things to the Point class. So, go into the point class, we know we
can do this anywhere in our program. Add the color and color equal getter and
setter methods. Change the initialized method, and by
providing a default argument for the color field, all the old uses of the initialize
method. All the old calls to new will continue to
work. We'll just be creating a new instance
variable that people didn't know was there before.
So, you can do this. You can get away with this in Ruby.
It's, it's often bad style if some other library wrote the Point class, you could
be messing up all sorts of invariance by going in and changing it.
You are now requiring every point in your system to have these color properties,
even if many of them don't need it, and it's kind of a non-modular change.
If you add a color field and someone else adds a z-coordinate and someone else adds
a string, which is the name of the Point. You're just bloating your objects with all
these different things, and that's if they're separate.
If they interact in any way, if any of the methods assume the other ones don't exist,
then you get into conflicts and, and all sorts of strange things should happen.
So, this will work, particularly for these sort of simple examples, but it's not a
particularly modular change. If we want to, in any way, keep the idea
of a ColorPoint separate from the idea of a Point.
So, here's a second alternative. Instead of subclassing Point, we could
just copy and paste the methods. Now, we wouldn't be relying on Point at
all, so things would be very separate in modular.
We would just define a class ColorPoint. And since it's such a short class, there
isn't too much to it. You, you know it almost fits on the slide.
I, I omitted the details of the initialized method here and we would just
say a ColorPoint has 3 getters and 3 setters for x, y, and color.
It has an initialize, it has this distFromOrigin method, which I literally
copy and pasted from the Point class, and distFromOrigin2.
Now, what's good about this is that now points and color points are completely
separate. Any changes anyone makes to the Point
class will have absolutely no effect on how any instance of ColorPoint.
And the obvious disadvantage is that I copy and paste the code.
So, I'm not getting any code reuse. If there was some bug in distFromOrigin,
I've just duplicated that bug. If someone adds good new functionality to
Point, I would have to go in and copy that over here.
Otherwise, I wouldn't be able to use it. So, this is a typical trade-off of, do I
want to re-use code or, do I want to make a copy and we generally prefer code
re-use? Here's the third alternative and this is
the one that people in objected oriented languages tend do to little of which is
instead of subclassing Point. What if instances of ColorPoint had inside
of them an instance of Point, in an instance variable as part of their private
state? So, here's how this would work.
I would just define a class ColorPoint, the super class would just be an implicit
object, I'm not going to use anything from the super class explicitly here.
I would have color getters and setters. But then, the other instance variable I
would have is pt here, short for Point. And I will initialize it here in the
initialized method to hold a Point. So now, my methods x, x equal, y, y equal.
Distfromorigin, distFromOrigin2 will not work as they did before, but I could just
forward the message, just make a nested method call to the underlying Point.
So, when someone had an instance of ColorPoint and they called the x method,
that would be this code that you see here. That would just, the body would just send
the same message, would just call the x method on the underlying Point.
Now, the good thing about this is that it encapsulates inside of ColorPoint the fact
that there's a point. It's an implementation detail.
It would let us change certain things. For example, if in ColorPoint, we wanted
the x and y coordinate to be called fu and bar, then we would just change the names
of these methods, and it wouldn't matter that the methods were called something
different than the Point class. The disadvantages are two-fold.
First of all, it's not nearly as convenient to code reuse.
All right, I have to create all these methods just to pass a method to some
underlying thing. But, much more interesting is that now a
ColorPoint really is not a Point. There is a method that we saw in Ruby
actually agrees with me. It's this totally separate thing whose
internal representation happens to include an instance of Point.
So, this is an even bigger deal in languages with static type systems where
it matters to us whether an instance of ColorPoint can have some type that
instances of Point also have. And here they would, they would not.
It's less of a big deal in a dynamically type language like Ruby.
But, if you see code like this for something like ColorPoint it is actually
inferior style, subclassing works really well here.
Subclass says, I really do want to inherit all the methods from Point, I'm just like
a point except I have some new things and I need to change the definition of the
initialized method. And that's why even this third alternative
for color points is an inferior one. But as I mentioned before, often times in
Ruby programs and in other object-oriented programming languages, you should be doing
something like this. But sort of out of laziness or convenience
or sloppy thinking, you end up using subclassing instead.
