Abstraction design: Introduction

Abstraction is one of the most important concepts in the programming world. In OOP (Object-Oriented Programming), abstraction is one of the three core concepts (along with encapsulation and inheritance). In the functional programming community, it is common to say that all we do in programming is abstraction and composition ^milewski. As you can see, we treat abstraction seriously. But what is an abstraction? The definition I find most useful comes from Wikipedia:

In other words, by abstraction we mean a form of simplification used to hide complexity. A fundamental example in programming is interfaces, which are abstractions of classes because they express only a subset of traits. Concretely, abstraction is a set of methods and properties.

There is no single abstraction for every instance. There are many. In terms of objects, a class can be expressed by many interfaces or by multiple superclasses. A key feature of abstraction is that it decides what should be hidden and what should be exposed.

We often forget how abstract everything we do in programming is. When we type a number, it is easy to forget that it is actually represented by zeros and ones. When we type a String, it is easy to forget that it is a complex object in which each character is represented by a defined charset, like UTF-8.

Designing abstractions is not only about separating modules or libraries. Whenever you define a function, you hide its implementation behind this function’s signature. This is an abstraction!

Let's do a thought experiment: what if it wasn’t possible to define a maxOf method that returns the biggest of two numbers?

Of course, we could get along without ever defining this function by always writing the full expression and never mentioning maxOf explicitly:

However, this would place us at a serious disadvantage. It would force us to always work at the level of the particular operations that happen to be primitives in the language (comparison, in this case) rather than in terms of higher-level operations. Our programs would be able to compute which number is bigger, but our language would lack the ability to express the concept of choosing the bigger number.

This problem is not abstract at all. Until version 8, Java lacked the capability to easily express mapping on a list. Instead, we had to use repeatable structures to express this concept:

In Kotlin, since the beginning we have been able to express this using a simple function:

Lazy property initialization patterns still cannot be expressed in Java. In Kotlin, we use a property delegate to express this concept:

Who knows how many other concepts there are that we do not know how to extract and express directly?

One of the features we should expect from a powerful programming language is the ability to build abstractions by assigning names to common patterns^sicp. In one of the most rudimentary forms, this is what we achieve by extracting functions, delegates, classes, etc. As a result, we can then work directly in terms of the abstractions.

Many things happen when you drive a car. It requires the coordinated work of the engine, alternator, suspension and many other elements. Just imagine how hard driving a car would be if it required understanding and following each of these elements in real time! Thankfully, it doesn’t. As a driver, all we need to know is how to use a car’s interface – the steering wheel, gear shifter, and pedals – to operate the vehicle. Anything under the hood can change. A mechanic can change from petrol to natural gas and then diesel without us even knowing about it. As cars introduce more and more electronic elements and special systems, the interface mostly remains the same. With such changes under the hood, the car's performance would likely also change, but we are able to operate it regardless.

A car has a well-defined interface. Despite all the complex components, it is simple to use. The steering wheel represents an abstraction for left-right direction change; the gear shifter is an abstraction for forward-backward direction change; the gas pedal is an abstraction for acceleration; and the brake an abstraction of deceleration. These are all we need in an automobile. These are abstractions that hide all the magic happening under the hood. Thanks to that, users do not need to know anything about their car’s engineering. They only need to understand how to drive it. Similarly, creators or car enthusiasts can change everything in a car, and this is fine as long as the driving stays the same. Remember this metaphor as we will refer to it throughout this chapter.

Similarly, in programming, we use abstractions mainly to:

The first reason was already described in Chapter 3: Reusability, and I assume that it is clear at this point why it is important to extract functions, classes or delegates to reuse common logic or common algorithms. In Item 25: Each function should be written in terms of a single level of abstraction, we will see how to use abstractions to organize code. In Item 26: Use abstraction to protect code against changes, we will see how to use abstractions to give ourselves the freedom to change things. Then, we will spend the rest of this chapter on creating and using abstractions.

This is a pretty high-level chapter, so the rules presented here are a bit more abstract. After this chapter, in Chapter 5: Object creation and Chapter 6: Class design, we will cover some more concrete aspects of OOP design. These chapters will dive into deeper aspects of class implementation and use, but they will both build on this chapter.