CSC 216/s08/be cheerful: Difference between revisions
No edit summary |
(Clarify how the code doesn't match.) |
||
| (10 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
=== | ==That's what it's all about!== | ||
== | ===Overview=== | ||
In this active learning exercise, you can teach the value of superclassing and writing "don't repeat yourself" code to prevent error. When a programmer writes the same code twice, to do the same job, this increases logistical overhead and introduces more chances for error. But if he writes the code once and tells the classes that use it to look at the same piece of code, this can be handily eliminated. This is where inheritance comes in. | |||
=== | ===How It's Done=== | ||
To model writing the code twice, and writing it once, you'll need two volunteers and an inside man -- you could do this yourself or delegate it. Your insider will instruct each of the two volunteers in how to do the hokey pokey. You can do this however you like: by word of mouth, by written instructions, whatever. But the one thing that you have to make sure is that one of the sets of instructions is ''wrong''. You'll see why in a second. | |||
Now, have your two volunteers start dancing, strictly adhering to their instructions. Soon enough, they'll come out of sync, and you'll have your error. As you should reveal to the class at this time, this represents what happens when your two sections of supposedly identical code don't match perfectly. The program breaks or contains bugs. | |||
To fix this, you can use a superclass that they will both take their instructions from. In this case, a nice Google video of a [http://video.google.com/videoplay?docid=-4742763335053216439 strange man doing the hokey pokey]. (This video will also be of use if your volunteers are a little too nervous: it's hard to be more ridiculous than that guy.) Once they've both received the same set of instructions, they can dance the hokey pokey in unison 'til the cows come home. | |||
After a bit more dancing, bring it all together with a nice review of what each part of the exercise represents: repetitive coding, unintended errors, and the efficacy of a superclass. If done right, this will leave a strong impression of the importance of not repeating code. | |||
===References=== | |||
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment] | |||
Latest revision as of 22:06, 3 April 2008
That's what it's all about!
Overview
In this active learning exercise, you can teach the value of superclassing and writing "don't repeat yourself" code to prevent error. When a programmer writes the same code twice, to do the same job, this increases logistical overhead and introduces more chances for error. But if he writes the code once and tells the classes that use it to look at the same piece of code, this can be handily eliminated. This is where inheritance comes in.
How It's Done
To model writing the code twice, and writing it once, you'll need two volunteers and an inside man -- you could do this yourself or delegate it. Your insider will instruct each of the two volunteers in how to do the hokey pokey. You can do this however you like: by word of mouth, by written instructions, whatever. But the one thing that you have to make sure is that one of the sets of instructions is wrong. You'll see why in a second.
Now, have your two volunteers start dancing, strictly adhering to their instructions. Soon enough, they'll come out of sync, and you'll have your error. As you should reveal to the class at this time, this represents what happens when your two sections of supposedly identical code don't match perfectly. The program breaks or contains bugs.
To fix this, you can use a superclass that they will both take their instructions from. In this case, a nice Google video of a strange man doing the hokey pokey. (This video will also be of use if your volunteers are a little too nervous: it's hard to be more ridiculous than that guy.) Once they've both received the same set of instructions, they can dance the hokey pokey in unison 'til the cows come home.
After a bit more dancing, bring it all together with a nice review of what each part of the exercise represents: repetitive coding, unintended errors, and the efficacy of a superclass. If done right, this will leave a strong impression of the importance of not repeating code.