Discuss the need for sub-programmes and collections within programmed solutions.


Teaching Note:

Show an understanding of the usefulness of reusable code and program organization for the individual programmer, team members and future maintenance.

LINK General principles of computational thinking, connecting computational thinking and program design.

MYP Technology: use of software such as Alice.


Sample Question:


JSR Notes:

Firstly a link back to the first point made at the beginning of 4.3 outside of the assessment statements:

"Use of programming languages

Sub-programs and objects support abstraction, which facilitates: ease of debugging and maintenance, reuse of code, modularity.


An Important Abstraction Point

Here, in the middle of 4.3, in the sub-section titled "Use of Programming Languages" (just before 4.3.6) the IB syllabus makes a really, really important point that actually isn't reinforced properly in one place, though it's the whole gist of modular programming. Not only have I repeated what follows on this page, in addition to it having appeared at then end of the official "abstraction" section of the curriculum, but I'll also paste it some place after you fully appreciate how to make different classes, and different functions within them.

But now is a perfect time to further appreciate why in programming, the concept of abstraction is so important. With abstraction we break up big problems into smaller, more manageable problems, so that we can ignore irrelevant information when solving each individual part, and that, in turn, facilitates each of the following things noted below.

"Sub-programmes and objects support abstraction, which facilitates: ease of debugging and maintenance, reuse of code, modularity."

- Debugging is easier because you can comment out a function and re-run your code and if the bug goes away, you know part of the problem at least must be in that function. And by the same token you can run a multi-class program, and not use one of the classes, and if the problem no longer exists, you have isolated it to be associated with that class.

- Maintenance is easier, simply because you can work with small chunks of a program rather than working with the whole thing. You can focus in on one particular task and work with it, to greater and lesser extents, in isolation from the distraction of everything else.

- Reuse of Code is facilitated simply because you don't have to write the same code over and over again, rather, in the case of functions, you just call them by name, and in the case of classes (of the "template" kind), you can simply make new instances of them. Furthermore you can use the same basic algorithms in different situations.

- Modularity - by using functions and classes, not only can you reuse the code within a certain class or project, you can move them (or versions of them) between programs and projects, similarly to the way you can install various generic car parts on various models of cars.


4.3.12 Itself

Now on to the specific focus of this assessment statement and Teaching Note: sub-programs and objecs as useful to individual programmers, team members and future maintenance

Note that sub-programmes (i.e. methods/functions) and collections are two distinct things. Yet they do indeed share the similarity of being useful to the "individual programmer, team members and future maintenance", in that each, in its own way is indeed reusable code, and each in its own way helps with the organization of a program - functions more the organization of the functionality of a program, and collections more the organization of the data of a program.


Let's take sub-programmes (i.e. methods/functions) first. From the Teaching Note, how are they "useful as reusable code"? Consider that without sub-programs, the length of programs would grow to be unmanageable. Consider that even the lowly System.out.println() is ultimately several lines of code which we would have to write over and over again if we did not use this pre-made "sub-program".

So to the individual programmer, it is useful to simply not have to write the same lines over and over again, rather he/she can call a particular function that does a particular task whenever needed, once that function is made.

To teams, it is organizationally great, because a function made by one programmer can be used by another using a different class, or indeed a different project. All the other team member has to have is access to is the method's public signature (its publicly visible header), which will tell him/her the arguments required if any, and the return type, if any. That, along with well documented pre-conditions and post-conditions, and the utility of that function can be ascertained and it can be used, even without having to know the details of how the function works (a great example of the "information-hiding" of abstraction).

And in terms of future maintenance, functions since they are a compartmentalized piece of code, can be simply and cleanly extracted if/when no longer needed, without affecting anything else (besides code formerly making use of them). Or they can be worked on in relative isolation to correct bugs, and/or add/delete functionality.


Hearkening back to 4.3.10, collections, since they are groupings of data, aid the individual programmer, and teams alike in that an individual collection can be passed around as an individual "container", without having to shuffle around the component individual pieces. It's like having all your eggs in a basket, and carrying the basket, rather than taking one egg at a time and moving it/working with it.

At a deeper layer of abstraction, but one which you have had a glimpse into, there is another boon associated with collections, this one a memory boon. With both Java arrays, and Collections such as ArrayList and LinkedList, the array/list object itself is a true object, i.e. a reference type variable. That means that when sending or receiving an array or Collection between functions or classes, it is only a 64 bit address that is actually being copied. Both copies will end up pointing to the same data which makes up the collection. Hence there is virtually no wastage of memory when using an array/Collection in more than one place.

And in terms of maintenance, because of what was just explained, an array/Collection object can simply and easily be deleted; just 64 bits of memory assigned as free, and the operation is done.