Sample Question:

sdfsdfsf

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, which is 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 - at least for the moment - ignore other information when solving those individual parts. And that (which is the concept of abstraction applied), 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/improve 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.

- Modularity - what we mean here is that we have inter-changable modules. For example, you can take one AAA battery out of one device, and slip it into another; its functionality is contained, entirely, within itself. In the same way, you can take a class, or indeed a function, and "slip it into" another project or class to be used there.

Where, with re-use of code, we can think more in terms of functions, with modularity, we can think more in terms of objects and classes.

And one other final note on modularity, particularly as we get into OOP programming, dividing things up into modules makes the whole system easier to understand and get a bird's eye view of.

 

4.3.12 Itself

Now on to the specific focus of this assessment statement and Teaching Note: sub-programs and collections 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.

Need/benefit of Sub-programmes/functions

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 to have to write the same lines over and over again, rather the programmer 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 them 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.

Need/benefit of Collections

Looking back to 4.3.10, since collections are groupings of data, they 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. This offers on one level programming convenience.

But on another level of abstraction, there is another significant advantage associated with collections, memory benefit. 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 (as argument/parameter), 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. This is beneficial both in terms of programming convenience and memory management.