Sunday 1 February 2015

Week 4: Abstracting away complexities



When we think of the term “abstract”, perhaps the first thought that comes to mind is abstract art. Abstract art holds little or no resemblance to real world objects. The use of lines, shapes and colours in abstract art is typically no where near accurate. This is why someone looking at abstract art may stare at it for hours without understanding what the piece is meant to represent.

We see this word “abstract” in computer science, but unlike it’s artistic variant, abstraction in computer science aims to simplify and consolidate our understanding of complicated programmatic operations without needing to write a single line of code.

Abstraction in action

To put abstraction to use, we’ll begin with a problem, one that was discussed in lecture and one whose solution was first proposed back in 1946 by Alan Turing.

Problem: Given some items (objects/values etc.), we’d like to build a collection of these in ascending order, and be able to add to the collection, and return the latest item when necessary.

Before we jump the gun and think about the code that could solve the problem, we first need to describe the solution so that we’re able to define a model.

Solution: The Stack model. A Stack contains various types of items. New items are pushed (added) onto the top of the Stack, the latest (or top most) items are popped (retrieved) from the top of the Stack. It’s not possible to pop an item from an empty Stack.

Our solution is fairly basic but it has two important properties which are common to all Abstract Models/Abstract Data Types:

  • describes a solution which could be implemented in any programming language
  • describes the data it contains and the actions that can be performed on the data

The Stack Abstract Data Type exists independent of any implementation. Abstract Data Types serve as blueprints or recipes so that they may be easily understood and implemented in any given programming language. However, it’s not guaranteed that all implementations of the ADT will work the same. Some implementations may perform more efficiently than others.

Our Stack solution makes references to nouns, such as item and verbs such as pushed and popped. When describing an ADT, nouns become the data and verbs become the actions (or methods) performed on the data. Select nouns and verbs define the underlying structure of an ADT.

So where do we go from here? We’ve defined our Stack ADT, the next step would be to implement it in our favourite language. Once implemented, the ADT takes on the role of a class, which is a topic for another post.

No comments:

Post a Comment