Programming 101

By Way of Java

Instructor: T. Boutell

Transcript for 10/17/96

Stimulants Anonymous
Welcome to the Java programmers' roasteria. A wide variety of stimulating beverages are consumed among the whirring virtual machines.
gnat polishes Tom's apples.
You say, "been done."
jkcohen has arrived.
kristen has arrived.
kate has arrived.
j.j says, "kate! i saved a seat for you by me!"
kate plunks herself, her computer, zad, and a pile of books down next to j.j
jkcohen waves and takes a seat.
You say, "ahem."
jsam sits next to jkc and passes notes.
Tom clears his throat vigorously.
You say, "welcome to Programming 101 by Way of Java. Thanks for coming."
Tom scritches his name on the blackboard, not too excruciatingly.
You say, "we're going to begin with a few ground rules for the class."
You say, "if you are an experienced programmer, you're welcome to remain,"
You say, "but please do not hurriedly answer every question with a smug flourish."
You say, "if you do, Boris the Bailiff will light you up like a christmas tree with his phaser cannon."
You say, "it is devoutly hoped that you have the Java development kit by now, and have hopefully recompiled or at least run one or two of the demo applets that come with it."
You say, "however, we won't be doing much compiling *in* the class. I made that requirement to make sure you can all apply what you learn here."
You say, "this is an introductory programming class. If I seem pedantic, please accept my apologies, but I intend to make this approachable for everyone."
You say, "if you don't understand, and I've come to the end of a sentence,"
You say, "please, please, please interrupt with a question."
You say, "programming is the art of recipe writing."
You say, "yes, programs are often very specific and detailed recipes, but it's not really an analogy; it's more of a synonym."
You say, "there's a lot of talk about object oriented programming, and people tend to be nervous about 'grasping' the 'OO (object oriented) paradigm'."
You say, "actually, most people already interact with the world in terms of objects."
You say, "it's not news to point out that your desk might have a notepad, a coffee mug, another coffee mug, another coffee mug, and a coffee stain on it."
You say, "but there's something odd about that sentence:"
You say, "anyone care to point out an easier way of phrasing it?"
jkcohen says, "Three coffee mugs and a coffee stain?"
You say, "yes."
jkcohen says, "Plus a notebook."
You say, "heh. Yes. Accuracy tends to be important in programming."
You say, "okay. Now, the idea of 'objects' doesn't really cause most people grief..."
You say, "but the idea of 'classes', as used in programming, does tend to frighten people off at first."
You say, "fortunately classes aren't that complicated, they just aren't explained well most of the time."
You say, "when jon summarized my sentence, he made the observation that all coffee mugs have a set of common characteristics which we are all familiar with."
You say, "in everyday conversation, we would say the three objects are the same 'kind' of object."
You say, "in java programming, we refer to them as being of the same 'class.'"
You say, "programmers seek to identify the objects that play a role in a task,"
You say, "and then describe the characteristics and behavior of these objects in a lot of boring detail."
You say, "computers like boring details, but people hate them."
You say, "so programmers realized they could describe the *shared* characteristics and behavior of the objects, and called this information a 'class' of objects."
You say, "a class might have only one object in it, ever, or it might have millions."
You say, "now, I want you all to take a look at the desktop on your computer screen."
You say, "each of your applications has a position on the desktop, a size on the desktop, and so on."
You say, "within each of your applications there are many smaller components, such as scrollbars, text windows, pushbuttons and so forth..."
You say, "each of these small components also has a position, a size, and the knowledge of what larger component it is a part of."
You say, "programmers could describe the behavior of each of these components in agonizing detail, but they wouldn't want to. It would be redundant, and they would make a lot of mistakes."
You say, "worse, if the programmers decided they wanted to change how these general things worked, they would have to change it for each individual component."
You say, "instead, there is a 'class', called 'window', to which all of these components belong..."
You say, "and information that any window will contain, such as size and position and the identity of the parent window, is described by this class."
You say, "the window class also contains instructions -- recipes -- to carry out things that people often want to do to a window."
You say, "which means that a window can be asked to resize itself, or to hide itself, and so on."
You say, "by writing down the correct recipe to do these things in the 'window' class, we are able to avoid reinventing the wheel."
You say, "also, we can change the recipe in one place if we change our minds."
You say, "now, take a look at the menus that appear in the program you're using."
You say, "each of these menus is certainly a window."
You say, "so the programmer could say, 'this is a window, and it also has a label, and another window that pops up when you click on it, and that window has a list of choices on it,' and so on. If there was only one menu, that would seem reasonable."
You say, "of course, there are many menus in many applications, and they all have very similar behavior, and programmers hate to waste time."
You say, "if two or more things have similar behavior, programmers will usually create a 'class' to describe what they have in common."
You say, "a menu, then, is an instance (one of) the class 'menu'."
You say, "but it is also obviously a 'window.' There is a special relationship between these two classes..."
You say, "a 'menu' is 'just like a window,' but it also has a list of items to display on it, a label, and so on..."
You say, "programmers refer to 'menu' as a 'subclass' of 'window.'"
You say, "this is similar to a recipe that starts out with 'prepare the frosting,' knowing that you already have a recipe for that."
You say, "this might seem a bit tricky, but we do this every day. For instance, we know that all collies are dogs. We also know that all dogs are not collies. A collie is a specific variety of dog, just as a menu is a specific variety of window."
Tom takes a deep breath.
You say, "any questions so far?"
kate zzz
j.j shakes her head, "with you so far."
You say, "hee."
j.j nudges kate.
kate says, "sorry. no."
jsam says, "tom, it's a quibble but could you say why 'a menu is obviously a window' to you?"
You say, "sam: well, a button might have been a better example. Menus are actually a bit complex in that there's a window with the label on it, a window with the actual list of choices on it, etc."
gnat says, "so a window is practically any 'thing' that appears on the screen?"
gnat says, "because all the things have a place, contents, a thing they're part of, etc?"
You say, "gnat: if it has a size, a location, and a parent window (which might be 'none'), then a window might be a reasonable way to describe it."
gnat says, "woohoo, I'm on the same page as Tom."
gnat turns his book rightside up.
j.j says, "well, duh."
You say, "gnat: if you find that most of the 'recipe' for windows is not useful for what you're doing, then you might decide to 'subclass' something else (or nothing at all) as your starting point."
j.j duhs that gnat is on the same page as tom. "class showoff."
Tom takes a drink of water. All this talking, you see.
You say, "now, I'm going to move on to some actual Java stuff. Sorry for the necessary pedantry."
jsam nods. "the mac world doesn't use 'window' to describe as many things as the other windowing systems do; this is a terminology question.'
Tom nods to sam.
You say, "okay. Now, in Java, the programming language itself takes advantage of ideas like classes, subclasses and objects by name. You can apply these ideas in any language, even COBOL, but Java makes it easier."
You say, "to describe the relationship between dogs and collies in Java, we might write the following."
You say, "if you don't follow everything in detail at this step, don't worry too much. I have to throw some things around without proper explanation to work with interesting examples."

class dog {
	String name;
	int weight;
}

You say, "That describes dogs as having two characteristics ("data members" in java parlance), 'name' and 'weight'."
You say, "'name' is a String object, so it can contain any amount of text."
j.j holds up a hand
You say, "yes?"
j.j says, "characteristics are objects?"
You say, "good question. Java classes can contain two things: data members, and methods."
j.j says, "so a characteristic is a data member?"
You say, "data members are objects in their own right, describing a particular *part* of the dog."
You say, "yes."
You say, "let me show another example, actually:"

class Dog {
	Tail tail;
	Ear leftEar;
	Ear rightEar;
}

jkcohen says, "So class collie extends class dog?"
You say, "jon: it will, but in a moment."
j.j says, "ok, i'm sorry, but can i ask another question?"
kristen says, "thanks."
You say, "j.j: shoot."
j.j says, "i understood the first example. if you want to create a dog object you give it a name and a weight."
j.j says, "but i don't understand this. if i want to create a dog object using this class, how do i give it a tail and ears and legs and whatever?"
You say, "j.j: one of the nice things about java is that you can start by describing things in general terms, then work on the details..."
You say, "j.j: the answer is that we would next have to describe the Tail and Ear classes."
j.j says, "strings and ints, i can do. tails and ears? how do i tell a program what a tail is?"
You say, "j.j: eventually we describe the simplest components in terms of things that are already built into Java."
j.j says, "okeydoke."
You say, "j.j: turtles all the way down."
j.j makes a note and pipes down.
kristen says, "no, uh, semicolons at end required?"
You say, "kristen: no. That's a C/C++ weirdness."
You say, "a note about java syntax, since someone asked:"
You say, "a statement, such as 'String name;', requires a semicolon at the end. This denotes the end of the statement. Hitting return does *not* denote the end."
You say, "larger things made up of more than one statement are generally enclosed in curly braces, but more about that anon."
You say, "okay. Now, this business with the tail and ears brings up an important point."
kristen says, "the class {} thing doesn't count as a statement?"
You say, "kristen: it is a 'compound statement'. { foo; bar; bletch } is acceptable wherever a single foo; is acceptable."
kristen nods.
kristen says, "i know i will get lost in what requires semicolons and what doesn't. hee."
jkcohen rustles in his seat, passing a sweetmeat to j.j
kate sighs. i lost one of my favorite earrings today.
You say, "sorry about that. Okay:"
You say, "we don't describe a dog as being 'just like a tail, but with a head and ears too.' It would be awkward."
You say, "ie, not *wrong* per se, but awkward to think of."
You say, "java allows us to describe things as *containing* other things."
You say, "that's what I did by listing the tail and ears as members of the dog class."
kate has a question.
You say, "yes, kate?"
kate says, "so, if you have 'ear' and 'tail' they can also be used by a cat class or a donkey class? it's like interchangeable parts?"
You say, "great question. Yes."
j.j says, "woowoo. neat."
You say, "interchangeable parts are a major goal in programming. As I mentioned, people hate reinventing the wheel. At least reinventing it twice themselves."
You say, "as in life, there can be 'wiring problems' with parts that weren't designed to fit together. Java has mechanisms to help with that, which we'll get to eventually."
You say, "now, here's how we would describe the collie class:"

class Collie extends Dog {
	Adorableness a;
}

You say, "we don't have to repeat the description of common dog characteristics."
j.j says, "just like that? with the word "extends" in it?"
You say, "yes."
j.j says, "neat. ok."
You say, "you can only use 'extends' once for a particular class. A Collie can't be 'like' a dog and 'like' an 'appropriate housepet', for instance."
jkcohen says, "But a collie is differentiated from other dogs by being adorable? Other dogs would seem to be adorable as well."
You say, "jon: that is an important point, which I will touch on in a moment."
kristen says, "hm, what, tom? last sentence?"
j.j says, "wait, which bit can only be used once?"
kristen says, "you can't do class Collie extends Housepet { blah } in same program?"
You say, "okay. Sometimes you might think something is 'like' two existing classes, not just one. A Car is both 'Transportation' and a 'Hazard'."
j.j says, "collie extends..." or "...extends dog"?"
You say, "you might wish you could say this:"

You say, "class Car extends Transportation, Hazard { ... }"

You say, "to save you grief at this stage, I will point out that java does NOT allow this."

You say, "this is frustrating at times, but there are theoretical reasons I don't want to go into now..."
kate says, "so something can only have one parent class?"
You say, "kate: yes."
kate hmm. OK.
You say, "in fact, there is a way around this, but I will explain it later. For now understand that you can only have one parent class."
You say, "this can be frustrating. It can also lead to good design, because it forces you to think carefully about the way you arrange your 'tree' of classes."
You say, "now, let me deal with Jon's point:"
You say, "I said that a Collie possessed an object of the Adorableness class as a data member..."
You say, "but many other dogs are adorable too. In fact, most any dog can probably be assigned a value on the spectrum of adorableness."
You say, "so far, I've stuck to description, rather than action. But now it's time to look at how we might assign a value to that attribute."
j.j says, "in your example, was "a" the value of Adorableness?"
You say, "j.j: yes. A bit awkward, and now I'm going to do it much less awkwardly."
j.j says, "ok. thanks."
You say, "let's suppose that adorableness is measured on a scale from 0 to 100."
You say, "then an integer 'variable' might be a reasonable place to keep that information."
You say, "so I could restate the class of dogs like this, leaving out some irrelevant stuff:"

class Dog {
	int adorableness;
}

You say, "then I might write the class of collies like this:"

class Collie extends Dog {
	Collie() {
		adorableness = 90;
	}
}

You say, "now, you might ask how we create a Collie object, all parentage questions aside."
jkcohen says, "What does the Collie() do?"
You say, "creating an actual object -- not just the general class of them, but a specific Collie -- is an action. There must be a recipe -- a "method" -- to carry it out."
You say, "now, a class can have many methods. But a very important one is the 'constructor' method."
You say, "the 'constructor' is the recipe to create an object of that class. It is called automatically whenever an object of that class is created."
You say, "the constructor always has the same name as the class itself."
You say, "this particular constructor method carries out one action: it assigns the value 90 to the adorableness variable."
You say, "every dog possesses *some* value for adorableness, but we have now made sure that collies in particular will always have the value 90."
You say, "any questions at this point?"
j.j says, "i think i'm ok."
jkcohen says, "So the notation Collie() is the constructor method?"
You say, "jon: yes."
kristen says, "no constructor is required for the parent class?"
kristen says, "i mean, you only have the constructor at the end of the chain?"
You say, "kristen: good question. It is good practice to have constructors in all classes..."
j.j says, "good practice, but not necessary?"
kristen says, "um, uh, like a Dog constructor?"
You say, "j.j: not necessary in theory. Members such as 'tail' that refer to objects will be set to null, which means 'no object assigned yet,' and numeric variables will be assigned zero."
You say, "j.j: in practice, this is usually not what you want, and a constructor is needed."
j.j says, "ok"
You say, "we're going to end this particular class at 7:15, so let me show one more method. This one is not a constructor."
You say, "I'll repeat the whole class for comprehensibility:"

class Dog {
	Tail tail;
	int adorableness;
	boolean Petted(int seconds) {
		if (adorableness > seconds) {
			tail.wag();
			return true;
		} else {
			return false;
		}
	}
}

j.j says, "that's a lot of new stuff."
You say, "yes. I'm not going to try to explain every part just now."
You say, "but look at the first line of Petted."
You say, "this method has several parts..."
You say, "it has a return type, which is useful to find out if it did what was expected, or for use in calculating something elsewhere."
You say, "the return type in this case is 'boolean', which can have the value 'true' or the value 'false'."
You say, "this method has a name, of course, 'petted'."
You say, "this method also takes an argument, 'seconds'. Methods can take several arguments, separated by commas, if desired."
You say, "the argument is used within the method to help determine how the dog responds."
You say, "in the body of the method, the argument and the 'adorableness' variable are used to decide whether the dog was pleased."
kate says, "so it's a kind of test?"
You say, "yes."
You say, "any guesses what tail.wag() is supposed to mean in java terms?"
jkcohen says, "It's a method of the Tail class?"
j.j says, "it's an action?"
kate says, "a method of acting on a tail object?"
You say, "yes, exactly."
You say, "the dog class responds to being petted by asking the tail to wag."
You say, "it is then up to the tail class -- perhaps written by you, perhaps another programmer -- to do something reasonable when asked to wag."
You say, "now, we're about out of time for this session, so I should ask if there are any more questions."
j.j says, "yeah, can we keep going?"
Tom laughs.
jkcohen says, "What would you recommend for homework?"
You say, "well, I promised that the class would end in time for everyone, so I'd better stop. But feel free to hang out and badger."
You say, "for homework, I recommend that you explore the 'demo' subdirectory that came with the Java Developer's Kit. Try running those applets. Also try deleting the .class files from one of them and recompiling them."
kristen says 'yikes' to the tail.wag().
kate says, "will it be cool to occasionally bug you with a question before next week's class?"
jsam says, "Tom: does java match C++ by not providing a default constructor if there are any constructors declared?"
You say, "next class, we will cover enough to be dangerous and start hacking applets."
You say, "you may already find you know enough to tamper with existing applets in interesting ways."
You say, "sam: yes."
kristen says, "i am confused why you needed a collie constructor inside the collie class but not for dog?"
You say, "kristen: I should have included one for simplicity's sake, but if you do not have a constructor, java provides one that initializes things to default values..."
You say, "kristen: in fact, my code was incomplete, because the tail, ears, etc. all need to be created..."
jsam nods.
You say, "kristen: but we haven't covered quite enough about objects yet. Next week we will."
kristen says, "oh. just saying Tail tail; inside dog doesn't work?"
kristen says, "oh, okay."
You say, "kristen: that creates a 'slot', if you will, that a tail can be attached to."
You say, "kristen: but if you were to try to wag that tail, java would let you know there isn't one attached."
You say, "ERROR: MANX"
kate giggles.
kate says, "yes, those famous manx collies."
j.j laughs.
jkcohen says, "Yeesh, Tom. Looking at the sample applets, there's all sorts of things I don't understand."
You say, "jon: heh. You will. There are a number of things we didn't get to that are important even for fairly simple applets."
jkcohen says, "public class Blink extends java.applet.Applet implements Runnable {"
j.j says, "oh my."
Tom nods. We will talk about most of that next week. Not 'implements' until a bit later.
jkcohen says, "OK. Good night."
jkcohen waves to all.
jkcohen has disconnected.
jkcohen goes home.
j.j defines Class Sushi:

Class Sushi {
	Rice rice;
	Fish fish;
	Seaweed seaweed;
}

j.j then creates subclasses for yellowtail, tuna, and california rolls.
j.j says, "dinner!"
You say, "hee."
kristen says, "tom, you'd want to include constructors for tail and those other objects of Dog, inside the Dog parent class?"
You say, "kristen: the constructors for the tail, ears, etc. go in the Tail and Ear classes."
You say, "kristen: then, to actually *create* a tail, ears, etc., you would need to initialize the variables like this:"
You say, "kristen: tail = new Tail();"
You say, "But I will be covering this next week."
j.j says, "what is with the parens?"
You say, "j.j: the constructor can take arguments if the programmer desires."
You say, "j.j: the parens in this case are empty, denoting no arguments."
kristen says, "can i just get this straight? you'd have class Dog {Tail tail;} and also class Tail {blah} ?"
j.j says, "ok."
j.j says, "thanks."
You say, "kristen: yes."
You say, "kristen: saying 'this dog contains a tail' isn't much different from saying 'this dog contains a string'. Both classes have to get defined somewhere."
You say, "kristen: String is defined for you, but it behaves much like any object of your own."
kristen says, "okay."

---

Next | Up to the Index

---