Software Engineering Abstraction
What are abstractions? why even care? how to utilise them in software engineering.
A vague concept at first. What is it? How can you utilise it? Why have it in the first place? When to use it? Where can you find it? Those are all questions this article is going to answer. You may not learn much here if you know what abstraction is and how to reason with it. The intended audience is newer software engineers that may still be studying or working. No coding will be done here as will be thinking in abstraction, pun intended. Let's get started. An abstraction is a cover around something you can operate with. Think of an ATM. You interact with it by inserting your bank card and it outputs money out assuming you have enough in the bank. The ATM is an abstraction. Abstractions don’t tell you much about themselves apart from presenting their interface to the outside world. Every time you interact with one, you don’t know what is happening. You can presume but not for sure. That’s the whole idea. It is black box as said in Physics. So it is something you don’t how it works but you know what it does based on the outside interface. How does that link to software engineering? Quite simple really, imagine you’re printing ‘Hello world’ to the console. You wrote some code to do that. You ran the code and it printed out the text. You just interacted with an abstraction. By now you should have an idea of what an abstraction is. You can probably derive why it is important. Lets spell out the importance: - Abstractions allow you to interact with a system without having to worry how it works internally - Abstractions reduce the things you need to keep in mind while using them Ok. We’ve established the importance. What defines an abstraction? Any piece of code that you’re making for reusability by other callers is probably an abstraction. If you don’t expect the caller to care about how the code is implemented then that’s an abstraction. Some examples include having a function that converts the temperature from Celsius to Fahrenheit, charge the user money, allocate more memory to be used by your app and so on… All abstractions tend to be things you’re interested to use without caring how they work behind the scenes. Frankly that’s why we can use first/third party libraries to do things for us like serialising JSON, reading from the file system, making calls to a network and so on… Furthermore, it is the reason why we can be productive utilising other code because we think of abstractions. We don't say how am I going to decode the data, it is already handled by the abstraction. Most of the time it doesn’t make sense to write new code for something that’s already implemented outside and ready for use. We can rely on the existing abstractions. Certain times, abstractions become leaky. What a leak you might say? Imagine the ATM ran out of cash. As soon as they don’t work on a specific case or all of a sudden, that’s leakiness. It is more of a problem if you care to know what every part of the code does because you care about performance of the code. Sometimes we mitigate leakiness by substituting for the abstraction, introducing corrective code, defensive mechanisms to catch errors or build on top of abstractions. That’s all part of the process of abstraction, we try to minimise amount of things you keep in mind for most optimal productivity. Often you bite the bullet, abstractions fail and it could be for a very valid reason like the electricity ran out in the ATM machine. I mentioned we build on top of abstractions. In reality that’s what we do all the time. Everything we interact with/through is pretty much that. Visiting a web page on your computer goes through so many abstractions you probably can’t imagine how much. Let’s try to list out the potential abstraction layers and then discuss how and why each helps the other. The layers are: - Enter website url - Ask DNS for IP - Call server through the IP - Receive webpage - Construct the window in memory - Update the monitor to render the new window That was a mouthful list of operations. Each has its own layers of abstractions. A layer of abstraction is a single abstraction interfacing with another abstraction. It is the pleasure of abstractions, you as a software engineer usually interact with one abstraction layer at a time because it is easy and part of your speciality. This entire article might’ve been an abstraction for you. It is usually difficult at first exposure to get it. Once you get it, you start to appreciate the wonder it can serve you. The better the abstractions the faster you are able to extend existing software because you don’t worry about the underlying structure. You can learn more about good software engineering design and why abstraction is at the centre of quality software by reading the following article of mine: [https: //ramihikmat.net/Article/2023-book-recommendation%3A-a-philosophy-of-software-design](https://ramihikmat.net/Article/2023-book-recommendation%3A-a-philosophy-of-software-design)