ProgrammingMethodology-Lecture21.pdf

Programming Methodology-Lecture21

Instructor (Mehran Sahami): So welcome back to the beginning of week eight. We're

getting down to the end. Well, we've got a few more weeks to go. It feels like we're

getting down to the end, though. It's one of those inverse relation things for the amount of

work. The amount of work you do as the quarter sort of reaches the end goes up. The

amount of work I do goes down, which I shouldn't laugh about, but that's just the way it

is.

There's two handouts today. One handout's your section handout for this week. Sections

are still happening this week. The other handout is some code on interactors that you saw

last time as well as some additional code that we'll go over today on interactors. Other

announcement, computer science career panel. So just a quick show of hands, how many

people are thinking about computers science as a major?

A few folks. How many people thought about computer science as a major prior to taking

this class? And now they're not thinking about doing computer science as a major? All

right. Sorry. How many people were not thinking about computer science prior to this

class that are now potentially thinking about computer science? A few folks in there, too.

That's good to see.

So this computer science career panel, one thing that people make the mistake of doing is

to equate computer science with programming, which is not at all the case. So if you're

trying to make a decision about whether or not to major in computer science just based on

this class, if you like programming, you should do computer science. You'll be a great

computer science. No doubt.

If you don't like programming, but you were thinking, hey, computer science might be for

me, in fact, many computer science majors don't end up programming after they

graduate. But having a computer science degree opens up doors for them to go into the

industry, in roles which, otherwise, they may not have been able to go to. So if you want

to find out about careers in computer science, and so the folks on this panel include some

people who are engineers, people who are at startups, people who are big companies,

people who are doing design, people who are doing product management. There's also

someone on the panel who went into academia, so not me, but another new professor on

the department. He'll also be talking about careers in academia on this panel.

It's Wednesday, November 14, 5:30 p.m. in Packard 101. There will be food, so don't

worry about missing dinner because there will be food there. There'll folks and there'll be

fun, and there will be computer science. So you just got to make everything start with an

F, and there aren't that many C-words.

So with that said, it's time to delve into a continuation of our last great topic. So it's time

to continue a bit with our friend, the interactor. If we think about the interactor and action

listeners – so last time we talked about having buttons and buttons generated action

events. Remember that? So we're going to do a brief review of that and push it a little bit

further.

So one of the things we talked about is having your program say in your innate method,

innate, somewhere you might have public, void, innate and inside here, you would set up

the parts of your program that you want to actually do something like the various

interactors, that when someone clicks on them, something happens. Then you would say,

add action listeners. What this would do is basically say, hey, I got some buttons in my

program. I want you to be listening for buttons.

So when someone clicks on a button, I want you to call a particular method for me, called

action performed, and then based on when you call action performed, I'll figure out what

button was clicked and then actually do something. Okay? So over here, we had our

friend, public void action performed. And action performed would get, as its parameter,

something called an action event. An action event, we'll just refer to it as E, was basically

what it would check to see what action was actually taken or basically which button was

actually clicked.

So hopefully you remember that. That's just a little bit of review from last time. Now

when we've got this action event, and we said there are a couple things you could do with

it. There was actually one main thing we talked about that you could do with it, and you

could figure out which command was actually the thing that caused this action event to

be generated by saying, hey, you know what I want to do? I want to pull out, as a string,

and I'll just call it CMD for command, the command or the name of the interactor that

caused this action performed method to be called.

So here I would say E dot command equals E dot get action command. And what get

action command does, it's just a method of this action event that says, I'll return to you

the name of the interactor as a string, and button's names are basically just whatever

display's on the button.

So then I can have some ifs in here based on this command. If command dot equals – and

I can check for some name that I might want to take some action based on that button. It

turns out there's something else you can ask this action event, E, for, other than the action

command. You saw this very briefly last time, and the program that we did, and you're

going to see it a little bit more now.

So I want to spend a little bit more time on it. It's something where you can say, E, what I

want to get from you is not the action command. I want to get the source of the action.

Now, the interesting thing about what get source returns to you – actually, let me not put

the semicolon here right now – is get source actually returns to you an object.

It returns to you the object that caused this even to be generated, which means if a button

was clicked, E dot get action command will get the name of the button. E dot get source

will actually give you a reference to the button object. So what you're getting back from

this is an object. You're getting a reference to that object.

So what does that mean for you in your everyday life? What that means is over here,

when you want to set up your initialization, you could say, I want to create a button. So

I'll have some button I want to create. So I'll say new J button, and maybe that button, I

want it to say hi on it. Okay? So one thing I can do is I can say hi equals new J button. Hi,

what I'm going to do is make that an instance variable. So somewhere down here in my

program where I have my I vars, my instance variables, I would have private J button hi.

So I just do the declaration of a variable called hi, which is of type J button, and then in

my initialization method, I actually create that button with the label hi on it. Then I go

ahead and add it somewhere to one of the control bars in my program. So I would say add

hi maybe to the south control bar because we really like adding things to the south control

bar. It's just fun when buttons show up on the bottom of our screen.

So we say add it there, and then wait for something to happen. So add my action listener

in case this button gets clicked. Now when the button gets clicked over here, what I can

do – I could actually ask command to get its name. Or I could ask action event to get the

action command name, and then I could say something like if command dot equals and

the name of the particular button over there happens to be hi, then there's something I

want to do. Maybe I want to print something on the screen or whatever the case may be.

That's one way I could write this, and that's the classic way that you've seen it written

before. That's the way you saw it last time. The other way I can write it, with my friend

get source, is rather than getting the name of the command and checking to see if the

command is equal to hi, I can actually say, Maron told me about this thing called E dot

get source. As a matter of fact, I don't even need this line for command anymore. Let me

just comment it out so I don't erase him.

I can say if E dot get source – this returns an object to me. I want to check to see if that

object that it returns is my hi button. So here, I check directly, is it equal to hi, and then I

do whatever I was going to do. So this has exactly the same effect as before. It's checking

to see if I've gotten a button that is the hi button that was clicked. So the difference

between these two things, if you kind of think about them, one of them is I'm just using a

name as a string, and the other ones, I'm using the actual object.

Now, if you think about it more deeply what that means, if I think about the name over

here, if I think just in terms of the name, I never need to be able to refer to the actual

object. Which means if I don't need to refer to the actual object again over here, I don't

necessarily need it as an instance variable. I only need it as an instance variable if I'm

going to refer to it again in some place that's in a different method than some other

method I may have already used it in.

So let me show you an example of what I mean by that in code to make that more

concrete. So if we come over here to code, here's essentially the code I just wrote for

basically reacting a button. So it's just the code I wrote on the board, except I made the

font bigger. I create a button with the name hi. I put it in the southern region, and I add

my action listeners to listen for that button getting clicked.

When the button gets clicked, I say, is the thing that got clicked this button that I created?

Here I actually called it hi button instead of just hi over there. I shortened it to hi so it'd

take up less board space.

If it's actually the source of that action, is my hi button, then I will print out hello there.

So I can go ahead and run this program. If I run this program, this is – I click hi, I get the

same thing I saw before. Every time I click hi, I get hello there. Now, alternatively, I

could've written this slightly differently, which is the way you saw it last time.

What I can do here is I can say, when I'm going to do the add, just go ahead and create

that button and add it, all in one line because I don't need to have some variable that

stores the button. Down here, I don't need to check for the source of what that action

event was. I'm going to say, action event, give me your command. The command is going

to be the name of the button, so I no longer need a variable to actually store a reference to

the actual button object because this is going to give me the name whenever I need it.

So as a result, notice here I don't have an instance variable. So this is one of those things

that's a tradeoff. It should also give you a little bit more insight into when you have

instance variables versus when you don't have instance variables. You need to have the

instance variable in the case, where you need to – wrong line. I want the new one. You

want the instance variable in the case where you want to be able to refer to this variable

in some method that's different than perhaps the method, which got created.

So I created the button over here, and I stored it somewhere, but I need to be able to refer

to it in some other method, so it's got to be an instance variable. If I don't need to refer to

it in any other method, which is what I saw in the second case, I don't need to refer to it

again. As a matter of fact, there's no other place I need to refer to it after I create it. Then

I don't need to store it anywhere. Any questions about that?

Student: [Inaudible]

Instructor (Mehran Sahami): So that's a bug in your logic. The computer shouldn't try

to figure out which one because if you give it two buttons with the same name, it says, I

have no idea. It's going to cause you problems, so don’t do it. If you want to see what

happens, go ahead and try. It's a bug in logic, not a bug in what the computer's executing.

Any other questions? Uh huh?

Student: [Inaudible].

Instructor (Mehran Sahami): It's still going to get the actual button, so you're saying in

this other case over here, what is this thing going to return if I didn't create a variable

over here? This thing's still going to return some reference to your object. The only issue

for you now, though, is you have no way of checking for equality with some object. If

you don't have this as an instance variable, you can't check to see if that thing's equal to

hi button.

So if you created hi button over here and just immediately added it and never kept track

of it over here, this guy would return to you a pointer to hi button, and you'd say great, I

got a pointer to hi button. How do you know it's hi button? You don't. You have no way

of comparing it to the actual hi button you created. That's why we need to store it.

All right. So why do I show you these two different ways of doing it? The reason why I

show you these is because now you're going to actually make use of this with respect to

some other interactors that you're actually going to see where we care about viewing get

source as opposed to the action command.

So what we're going to do next is we're going to say, you know, a lot of times in

programs, what you really want to have is some way of letting the user have some way to

specify some text in a program that's running interactively that's not in the console.

They'd like to be able to type something in, so let me just show you an example of this.

So here's a little program that's go what we refer to as a text field down here, and I call

that name. So if I say, hey, my name's Maron, it says, hello, Maron. I say, no, my name is

really Sally. Most of you don't know this. It says, oh, hello, Sally. It's just some way of

being able to have some text field over here that the user fills in. This is an interactor,

right? This is just one field. It's not on the console. Then do some action, and the action

we happen to do here is just to write something to the console that makes use of the text

that the user actually typed in.

So how do we get something like that to work? So what we need to do is have an

interactor that's called the text field. Basically, text field is just that thing you saw. It's a

little place where someone can type some text as an interactor. So it shows up in one of

the control bars, and then potentially, when they hit enter, you get some action event that

tells you, you need to actually – of if you want, you can do something with this text. So

that's the basic idea.

What you really get is a box, and that's all you get with it. If want to add a label to that

box, like we added name over here, we need to specify that. I'll show you how to do that

in just a second, but what you get is the box. The user types in something and then hits

the enter key. Then potentially some event is generated for you. So how is that actually

set up?

So the thing we want to create is a J text field. It's just another one of these interactor like

you saw before with check boxes and combo boxes and all that stuff. It's just called a J

text field. I'll name this one TF to stand for text field. What you do when you create a

new one of these is you say, new J text field. What you give it as a parameter, and here's

the funky thing.

You don't give it its label. The label doesn't come with the text field. You need to create

the label separately. What you give it is the size of that text field, how big it should be in

terms of the maximum number of characters that would show up in there. So if you say

ten, for example, what you're saying is I want to have some text field that will hold, at

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: