Chapter 3.5 - Procedural Abstraction

In this lesson we won’t add new functionality to the Paint Pot app. Instead, we will revise the code, leaving the app’s behavior unchanged. This process is called refactoring and programmers do this to improve the quality of their code in various ways -- e.g., to simplify its design, make it easier to read and easier to maintain. In this case we will introduce the concept of a programmer-defined function that will help reduce the complexity of our code and make it easier to read and maintain. This is an example of procedural abstraction, a very important concept and practice in programming. Objectives: The objectives of this lesson are: to continue learning how to navigate the Thunkable online programming platform; to introduce the concept of a programmer-defined function.

Getting Ready

Open Thunkable with your Paint Pot app from the previous lesson.

Code Walkthrough and Critique

If you completed each of the mini-projects in the Paint Pot Projects lesson, your code might look something like the code for our solutions:

Notice that the circled segments are three occurrences of exactly the same code. The circled code performs the task of displaying the current dot size in the format Dotsize = 5.

This is an example of redundant code and it is generally not a good idea. For one thing, it makes it more complicated to modify and maintain the program. For example, suppose we decided that we want to change the display to say Dot Radius: 5 instead of Dotsize = 5. This is a subtle change but to effect this change we would have to find and change all three occurrences of that code. If we forgot one, that would introduce a bug into the program.

This is a fairly minor and innocuous example, but you can imagine cases where forgetting to change some piece of code could seriously affect the behavior of the program.

Procedural Abstraction

A better way to code this task of displaying the dot size would be to define a named function that encapsulates the display algorithm and to call the function by name whenever we want to display the dot size. This is another important use of abstraction in computer science.

Refactored Code

Consider the following refactored version of the program. In this case we have defined a function named displayDotsize, which now contains the code for displaying the dot size. And we are calling it, by invoking its name, from three different places in the program.

This is a much improved version of the program. For example, think about what we need to do now if we want to change the display to Dot Radius = 5. We need only change the code inside the function and the change will take effect throughout the program. The code we need to change is easy to find because it is encapsulated within the displayDotsize function.

By defining and using a function in this way, we have reduced the complexity of our code. A good way to think about this is that the function enables us to reduce the number of details involved in a task so we can focus on the relevant aspects of the task. In this case, we can focus on the purpose of the task -- i.e., to display the dot size -- without having to worry about the exact details of how that is done.

How to Define a function

To define a function in Thunkable, you will need to open the Functions drawer in the Blocks editor. In this case you want to select the first function-definition block in the drawer, the to do something block, and drag it to the workspace. (The second to do something and return block is used for defining functions, which are functions that return a value, and we’ll get to them later.)

Once you have the to function block, you’ll want to change the word do something to a more descriptive name for the function -- in this case to displayDotsize:

A function-definition block, such as this one, defines what it means to displayDotsize. And we do that by placing our algorithm -- the steps we take to displayDotsize -- inside its slot:

How to Call a function

The above steps suffice to define the function. In order to use the function we need to call it or invoke it. Whenever you define a function, Thunkable automatically makes a function-call block and places it in the Functions drawer:

Now, whenever we want to perform the defined function, we simply call it, as shown in the refactored version of the program. We can call it as many times as we like from anywhere within the program. And we don’t have to worry about how to find its code if we want to change the algorithm because it is encapsulated within the function-definition block.

Built-in and Programmer-defined functions

Notice that function-definition and function-call blocks are purple. In that respect they resemble the built-in function blocks we’ve been using in our apps. For example, in the I Have a Dream app we used built-in functions to start and stop the audio player:

The algorithms required to perform these type of operations on the Sound component are probably much more complex than our simple displayDotsize function. So in this case, the abstraction we’re using, the in MLKPlayer call Play function, is hiding quite a bit of complexity. Similarly, in the PaintPot app, we use the draw filled circle at function to draw circles on the Canvas:

Here too, using the built-in function allows us to focus on the relevant task -- i.e., drawing a circle -- rather than having to worry about the underlying complexities involved.

However, even though these are built-in functions, the principle is the same: once we have a function, whether built-in or programmer-defined, using the function allows us to focus better on the relevant tasks rather than worrying about the complex details encapsulated in the function definition.

Adding Comments to Code

An important feature of every programming language, including Thunkable, is the ability to add comments to the code. A comment is a non-executable block of text that can be added to a program to provide clarification and documentation of the code. Adding comments to one’s code is a standard practice that programmers employ to help others (and themselves) understand their code.

In Thunkable, each non-collapsed block comes with the capability of having a comment added to it. To access this capability, click on the small comment-icon, a blue circle with a question mark, on the block (as shown here).

To add or edit the comment, simply click on the comment-icon and type in your comment, as shown here:

Good Commenting Practice

A good practice to follow is to provide comments in the following situations:

• To document every function that you define, as shown in this example here.

• To clarify a complex algorithm that isn’t clearly obvious.

3.5.3. Summary

In this lesson, you learned how to:

Learning Objective CRD-2.G: Describe the purpose of a code segment or program by writing documentation.

Learning Objective CRD-2.H: Acknowledge code segments used from other sources.

Learning Objective CRD-2.I.a: For errors in an algorithm or program: a. Identify the error.

Learning Objective CRD-2.I.b: For errors in an algorithm or program: b. Correct the error.

Learning Objective AAP-3.B: Explain how the use of procedural abstraction manages complexity in a program.

Learning Objective AAP-3.C: Develop procedural abstractions to manage complexity in a program by writing procedures.

3.5.4. Self-Check

Vocabulary

Here is a table of the technical terms we've introduced in this lesson. Hover over the terms to review the definitions.

comment computer bug debugging	procedural abstraction refactoring

Check Your Understanding

Complete the following self-check exercises.

Q-1: What does refactoring mean?

A. Revising a program to remove bugs.

B. Restructuring a program without changing its basic behavior.

C. Restructuring a program to make it behave differently.

D. Changing the way the program behaves.

3.5.5. Reflection: For Your Portfolio

Answer the following portfolio reflection questions as directed by your instructor. Questions are also available in this Google Doc where you may use File > Make a Copy to make your own editable copy.