CSC 216/s08/be cheerful: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(Clarify how the code doesn't match.)
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
===Formatting Resources===
==That's what it's all about!==
[http://meta.wikimedia.org/wiki/Help:Wikitext_examples Formatting Help Guide from MetaWiki]


==Place Title of Exercise Here==
===Overview===


Give the title of your exercise, which may include the name of the topic you are covering, or some other catchy title.
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.


===The problem===
===How It's Done===


Describe what you are attempting to teach students by this exercise.
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.


===Participants and props===
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.


How many students will participate? What else do you need (e.g., old tennis ball, Powerpoint slides, software).
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.


===The script===
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.


Describe how to do your exercise.
===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.

References