>> SPEAKER 1: Suppose now that I wanted to give Scratch the ability
to sneeze as well.
Well, my first instincts would be, as before, to make a
block, call this sneeze.
Specify that I'd like to specify with a number how many times
Scratch should sneeze.
Thereafter clicking OK.
Let me move this over to the right to give myself some more room.
>> And then let me again go to Repeat, overriding the default 10 with n.
Let me go to the say statement and say not "hello", but
"achoo" for one second.
Then take a moment's respite.
And that's it.
>> Now I have a block called sneeze, as well as a block called cough.
So that now if I want Scratch to cough and sneeze, I can simply specify a
sneeze below his cough.
Three times, say.
Click the green flag, and I should see indeed, cough, cough, cough.
Followed by achoo, achoo, achoo.
My most realistic sneezes to date.
>> Now notice something that's bad about this design.
Even though I didn't outright duplicate any puzzle pieces, I
definitely dragged and dropped pretty much the same puzzle pieces, giving
the one function an ever so slightly different name than the other, sneeze
versus cough.
So this is an opportunity for factoring out some common code.
Indeed, notice the only difference between cough and sneeze is that one
has Scratch saying "cough," the other of which saying "achoo."
>> So couldn't we somehow generalize this code in such a way that we simply
specify what word we want to Scratch to stay?
And depending on that word, it will effectively be a cough or
it will be a sneeze.
So let's go ahead and do this.
Let's make a third function and call this one, "say." and I want it to
accept, not just a number, but this time a string, otherwise known as a
word or phrase.
>> And we'll call this "word."
And how many times do I want to say this word?
Well let's specify a number, calling it again n.
And just to make this block more readable, let me go ahead and add a
label called "times." So that when you read this block from left to right, it
literally says "say word n times."
>> Now let me go ahead and click OK.
And now let me implement this block, again using a repeat block.
Specifying that I want it to repeat n times.
Specifying that I want to say something for one second.
But rather than something hard coded into this function, let's instead drag
and drop the word that's been passed in.
Let's then wait for one second.
So now let me go back and refine my implementations of cough and sneeze,
in such a way that those two functions call this third function, thereby
minimizing the amount of duplicate code.
So let's literally throw this code away.
Let's throw this code away.
And this time, let's simply specify that cough should be implemented by
saying "cough" some number n of times.
>> And similarly, can we go back and re-implement sneeze so that it uses
say with an argument of "achoo" n times.
So what have we done?
We've recognized the code that was common to both our cough and our
sneeze functions, factored it out into a new third function, and then
rewritten cough and sneeze in such a way that they call that
third and new function.
>> Now we have absolutely made this whole program more complicated than it
really needs to be.
After all, at the end of the day, we just need Scratch to cough three times
and sneeze three times.
And we could have done that with just a few puzzle pieces.
But as our programs get much more complicated, and our programs more
sophisticated, this technique of factoring out common code, or
hierarchical decomposing your program into smaller function, each of which
call other functions, is a very compelling technique.
Because it will ensure that your code, even as it gets more complex, remains
easy to update and also very readable.
>> Indeed, consider the end result.
When the green flag is clicked, cough three times, sneeze three times.
And that's it.
In fact, let's do exactly that.
Click the green flag and we get one cough, two coughs, three coughs.
Followed by, we hope, once sneeze, two sneezes, and a third sneeze.
Hope he gets better soon.