Why Use Subclassing?

Loading...

From the course by University of Washington

Programming Languages, Part C

201 оценки

University of Washington

Programming Languages, Part C

201 оценки

[As described below, this is Part C of a 3-part course. Participants should complete Parts A and B first -- Part C "dives right in" and refers often to material from Part A and Part B.] This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module of Part A. Part B assumes successful completion of Part A. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.

From the lesson

Section 8 and Homework 6 (First Module with Ruby)

Let's get started programming with Ruby, including learning about Ruby's variant of (almost) function closures and the "inheritance and overriding" that is the essence of object-oriented programming. The welcome message has a few additional comments about "what makes Ruby different" and how to approach the (rather different) homework assignment, so let's get started...

Introduction to Ruby11:14

Classes and Objects12:37

Object State13:14

A Longer Example12:19

Everything is an Object8:15

Class Definitions are Dynamic7:42

Duck Typing7:28

Using Blocks6:24

Hashes and Ranges8:59

Subclassing10:11

Why Use Subclassing?7:16

Overriding and Dynamic Dispatch10:56

Method-Lookup Rules, Precisely11:31

Dynamic Dispatch Versus Closures9:38

Optional: Dynamic Dispatch Manually in Racket15:56

Meet the Instructors

Dan Grossman
Professor
Computer Science & Engineering

[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.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play