Level design — Python: Building data abstractions

We will look at another simple system — rational numbers and the operations on them. Remember that we can represent a rational number as a fraction a/b, where a is the numerator and b is the denominator. Also, b cannot be zero since division by zero is not allowed.

Python does not support rational numbers. So, we will create an abstraction for them ourselves. As usual, we need a constructor and selectors:

# We have created a rational number
num = make_rational(1, 2)
numer = get_numer(num)
# 1
denom = get_denom(num)
# 2

We have defined a rational number using three functions. One function as a constructor assembles it from separate parts, and others as selectors allow us to extract them. In this case, it is unimportant what num is from a language point of view. You can do this with functions, lists, and dictionaries.

In the internal implementation, you can even use strings:

def make_rational(numer, denom):
    return f"{numer}/{denom}"

def get_numer(rational):
    numer, _ = rational.split('/')
    return numer

def get_denom(rational):
    _, denom = rational.split('/')
    return denom

make_rational(10, 3)
# "10/3"

Abstraction becomes useful when it becomes possible to operate on it. For rational numbers, arithmetic operations are basic operations like addition, subtraction, or multiplication. Multiplication of rational numbers is the basic operation. To perform it, you need to multiply the numerator and the denominator:

3/4 * 4/5 = (3 * 4)/(4 * 5) = 12/20

The curious part begins with the implementation. Suppose the rational number structure looks like this:

def multiply_rational(rational1, rational2):
    return {
        "numer": rational1["numer"] * rational2["numer"],
        "denom": rational1["denom"] * rational2["denom"],
    }

Everything is fine from the perspective of the calling code — we preserved the abstraction. We pass rational numbers to multiply_rational which returns a rational number. But there is no abstraction inside. The handling of rational numbers relies on knowledge of their structure.

Any change in the internal implementation of rational numbers will require you to rewrite all operations that work on rational numbers directly without selectors or a constructor.

This code violates the principle of single-layer abstraction. In developing complex systems, we use level design approach. Essentially, the system has a structure of successive levels. Each level combines parts from the previous one considered elementary at that level.

The elements built at each level work as elementary at the next level.

Level-based design permeates the entire technique of building complex systems. For example, when designing computers, resistors and transistors are combined and described using the language of analog circuits, and from them, we can build AND, OR, and other elements, which serve as the basis of the language of digital circuits.

These elements build processors, buses, and memory systems, which serve as construction elements of computers using languages suitable for describing computer architecture. Computers, combined, give distributed systems describing network interactions, and so on. (c) SICP

def multiply_rational(rational1, rational2):
    return make_rational(
        get_numer(rational1) * get_numer(rational2),
        get_denom(rational1) * get_denom(rational2),
    )

In our example, the basic level is the types built into the language: numbers and a dictionary. Based on them, we create a level for presenting rational numbers:

• make_rational
• get_denom
• get_numer

Then, we have the level where we implement addition, subtraction, multiplication, and other arithmetic operations on rational numbers.

We emphasize that we're talking about the implementation of the levels themselves. For example, the addition operation relies entirely on the constructor and selectors but does not and cannot know about the internal structure of the rational numbers themselves.

On the other hand, this doesn't mean that functions from different levels can't appear in one place. They can, and this is normal in many cases. For example:

def f(rational1, rational2):
    rational3 = add_rational(rational1, rational2)
    denom = get_denom(rational3)
    numer = get_numer(rational3)
    print(f"Denom: {denom}")
    print(f"Numer: {numer}")