Abstraction Is The Bridge Between Algorithms And Architecture

2023-5-15

#absurd-abstractions

Abstraction is that weird little concept we associate with abstract paintings or hard to grasp concepts, deeming them too abstract. However abstraction in reality is the ability to filter irrelevant details and being left with the relevant essence within the target context. The way we abstract things is highly dependent on the abstraction goal. In abstract painting it surely could be how something looks or feels, colors or shapes. It can be abstracted in terms of its structures, or another common feature. We decide to represent all the relevant features, while hiding every other feature of the abstracted object behind a metaphorical amorphous question mark, which can be swapped out by any other feature later on. Abstraction is already a common concept in computer science, where it separates interface from implementation. Allowing for polymorphism, run-time dynamics, to enable scalability, maintainability which are necessary to craft complex architectures.

But abstraction is so much more! Abstraction first and foremost is a cognitive model. It influences the way we think about a thing. It enables us to only focus on what is important for us and fade out all the other details that may distract from it and once we eliminate what doesn't concern us we are able to see new connections to other things that seemed totally unrelated before. Enabling metaphors, figures of speech, or modeling an object in terms of another. This mechanism is at the root of symbolism, and the entirety of communication. This notion that abstraction helps us to model something in terms of something else can be applied to algorithms as well.

Now first of all, let us define an algorithm in the most commonly accepted way. An algorithm is a sequence of steps, smaller actions or rules that when followed can be applied to solve a problem.
Now usually we build one algorithm to implement exactly one set of functionality. However an algorithm itself can serve as an abstraction. I came to think about this notion while studying some algorithms and data structures on a coursera course. You can checkout my uni repo, where I implemented one of the algorithms from the course. One thing I noticed is, how close an algorithm is tied to a data structure. There is no data structures and algorithm, but instead they are both the same thing looked at from a different perspective or level of abstraction. The data structure is the static representation of data, optimimized or layed out for a certain process. While the algorithm is the dynamic process processing that representation. What this means generally is, that for any data structure there is an associated algorithm and each algorithm an associated data structure.

The next thing I noticed was, when I had to implement the solution of a problem through the lense of one of the algorithms. Union find is a way to organize a set of entries by grouping them using a symbolic second list representing the relationship of the indexes and if they are connected or not. And to see if two entries are part of the same group or union we iterate over them and check if they share the same root. In one implementation at least. Now facing the problem of perculation -- yet another fun abstract problem that can be applied to all sorts of domains -- we could solve this specific problem by using the more generally applicable union find algorithm. Perculation refers to a material's property, with a complex structure, like a rock formation in a cave, or a circuit in electronics and check if there is a connection between one side and the other effectively enabling the flow of something else through it. Like a maze solver. Now you could make the connection how this more general algorithm can be used to solve a yet more specific problems. And this is the point I am getting at.

Algorithms are not just the step by step procedures to implement a solution but they form a new abstraction, represented by data structures and executed by a process within which we put the particular focus on one concept. Often being able to solve problems in terms of unrelated concepts. We create a structure of abstractions. And here I want to mention another notion related to architecture. In the ideal case in object-oriented programs we have one class responsible for exactly one thing (Single responsibility principle: The S in Solid). But how can we define where one thing starts and ends? I have decided to interpret this one thing as one algorithm. One layer of abstraction, represented by a set of data, driven by one main process to solve one part of a problem. The rest should be interfacing and messaging functions to interact with the object in the original sense of abstraction.

Takeaway

The next time when modeling a system and deciding where and how to define the boundaries, let's use abstraction to guide our intuition. On the other hand we can use abstraction to progressively built up solutions to very complex problems, by modeling in terms of concepts that are easier to reason about. In that sense abstraction becomes the motor for architectural and algorithmic decision making.