Explain why abstraction is required in the derivation of computational solutions for a specified situation.


Teaching Note:

Students should be aware of the concept of objects, for example, the use of collections as objects in the design of algorithms.


- Databases: tables, queries
- Modeling and simulation: an abstraction of reality
- OOP: classes, sub-classes
- Web science: distributed applications


Sample Question:


JSR Notes:

Why Abstraction? Life is Complex...

By "derivation of computational solutions for a specified situation" we mean coming up with coding solutions to the problems we are working with. And recall that abstraction is basically "the process of filtering out unnecessary information".

So why abstraction? Abstraction is necessary in solving our problems because our problems are complex; therefore they are best solved one piece at a time. In solving each piece, we need not be distracted or indeed overwhelmed with all the other pieces. So through abstraction we focus in on what is necessary for that particular part of the problem, filtering out everything else. And when that piece of the puzzle is put into place, we move on to another piece, once again focusing in on the essentials of that piece, filtering out the rest.

OOP and Functions To the Rescue...

In terms of the Teaching Note, and how Object Oriented Programming (OOP) helps us with applying abstraction, OOP comes to the rescue by breaking a complex problem into more manageable pieces. Because of the "encapsulated" nature of OOP classes, each class can focus in on one particular set of data attributes, and not have to worry about all the other classes of the project. Yes, any one class can use objects of other classes, but it does not have to be concerned about the details of how those other objects work. The "information hiding" of those other classes helps keep the one class manageable and understandable.

Though not in the Teaching Note, the same applies to functions. Within each class, the overall functionality is divided up into sub-programs, or functions. Each function can focus in on itself, not worrying about the details of the other functions. And yes, here too, one function can use other functions, but all they really need to know about each other is their names, their return types and their parameter lists, along with (hopefully) the communication of pre and post conditions.

Non-Computer Examples

One person alone cannot run an IASAS soccer tournament, if only because a lot of jobs need to be done concurrently. And the person working on housing does not need to know whether or not golden goals will be played in the case of a tie, any more than the head official does not need to be in on discussions centering around curfew. This leads to focus on the essentials for each person and their particular assigned task(s).

Or you could think of a large corporation with all kinds of different departments, each with its own specializations. The legal department does not need to know how the IT department looks after the network, and the advertising department does not have to know how the transportation department works. They can use the "public interfaces" of each other's departments without knowing the inner workings of those other departments. We could go further levels of abstraction down, and within one department, a copyright lawyer needs not know exactly how the employment lawyer works.

Computer/Programming/Java Examples

It makes a lot of sense to divide a big Movie database program into the following classes:

And indeed the last two could be made into sub-classes (via inheritance). For example, the Open class and Save class have certain similarities, but certain other things that are more their own essence, allowing them to be even more specialized, and even less influenced by the "noise" of other things beyond their remit. The same can be done within each class, with specialized functions being made.

But one way or the other, the bottom line of the reason for abstraction, is that problems are often too big to just sit down and try to solve them in one big procedural, step-by-step way. It makes more sense to determine the discrete parts of the bigger problem, and solve each of them in turn, each time disregarding all but the essentials of the other parts. Abstraction should be used in such a case where subtasks are obvious to identify.