They don't embrace and understand abstractions in their code, or in their learning.

But what are abstractions? And why are they important?

Let's dive in!

What is an Abstraction?

In coding, developers often use abstractions to simplify a system. Abstractions are a way of hiding complicated details from the end user, and trying to simplify whatever task you're trying to do.

But abstractions can be used in more than just code, so let's start with an example.

Coffee machine abstractions

Imagine if you were creating a machine to make coffee for your users. There could be two approaches:

How to Create it With Abstraction

• Have a button that says "Make coffee"

How to Create it Without Abstraction

• Have a button that says "Boil the water"
• Have a button that says "Add the cold water to the kettle"
• Have a button that says "Add 1 spoon of ground coffee to a clean cup"
• Have a button that says "Clean any dirty cups"
• And all the other buttons

Can you see how, when we use abstraction, we don't expect the user to know how the machine makes coffee? But in the machine without abstraction, the user has to know in which order to press each button, which forces the user to understand how the coffee is made.

Why You Should Abstract Your Details

When we use abstractions well, we make our system/codebase/task and so on much easier to understand and use. By hiding away complicated details inside a module, class, prototype, or function, we can make a super simple way to do complicated things.

So for example, let's say we have some complex code that ends up doing lots of complex, hard to understand math. We can wrap all that logic up in a function and provide a really easy interface where you just pass in your number and the function will do the work.

Developers in all languages and across all ecosystems make use of abstractions. The NodeJS team doesn't force you to understand how to modify 0's and 1's on a hard-drive to save text into a file – you can simply call the writeFile function.

When we use abstraction, we are essentially not forcing the person who uses our code to worry about the implementation details. They can just call the function and they'll get their answer back – they don't have to worry about what the function is doing "under the hood".

That's the strength of abstracting details away in your code.

I used to work at a company with a codebase that was 4 million lines long. Can you imagine a senior developer expecting me to understand every function? Every module? Every class? I would have NEVER merged a single change in that codebase if I did!

You can create a reusable, simple to understand, and easily changeable codebase by abstracting away certain details into the correct modules/separating out your code.

An Example Abstraction

Let's try and illustrate this with a code example.

Imagine you're working on a banking app, and you keep coming across this same weird subtraction over and over again, in different places in the code.

const res = bankAccountBalance - 1200

const res = bankAccountBalance – 1500

const res = bankAccountBalance - 1400

Why do we keep subtracting random numbers from everyone's bank balance once a year?! This is so unclear, there are zero comments explaining this?! What's happening? Is this an error?

Now imagine if this feature was clearer and did this:

const minusFeesInUSDollars = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1200 (USD)
    const YEARLY_FEES = 1200;
    return bankAccountBalance - YEARLY_FEES;
}
const minusFeesInGBPounds = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1500 (GBP)
    const YEARLY_FEES = 1500;
    return bankAccountBalance - YEARLY_FEES;
}
const minusFeesInEuros = (bankAccountBalance ) => {
    // Our yearly fees for this account are 1400 (EUR)
    const YEARLY_FEES = 1400;
    return bankAccountBalance - YEARLY_FEES;
}

The example isn't perfect, because we could remove some duplication in these functions – but we have abstracted logic into "something", in this case, a function.

Why Should I Embrace Abstractions?

I have explained abstractions so far in the context of code, but it can apply to your learning journey as well.

If you can't embrace abstractions (at least when you are starting) you will never be able to understand and excel as a developer.

Why is this the case?

Well, because there is always an abstraction beneath you, that you will be tempted to try and understand. This will ultimately frustrate you, overwhelm you, and kill your learning.

Here's an example.

1. You start to learn React.

This is going well! I'm starting to learn my first few bits of code and render some things to my computer screen. This is going well. 😊

2. You learn that React is a library of JavaScript.

Okay that's cool! I should learn a little bit of JavaScript before I start with React then. I'm going to stop learning React, and learn vanilla JavaScript first.

3. You learn JavaScript is a programming language made up of lots of different pieces.

Okay this is getting more complex now. There are JavaScript engines, third party API's, different runtimes. This is getting confusing.

4. You try to understand how an engine interprets JavaScript code.

Okay! So your JavaScript code is being run, by a piece of software coded in C++. What is C++?

5. You start to learn C++.

This learning journey isn't going so well anymore. This is starting to get very confusing and much longer.

6. You learn that C++ is simply an extension of C.

What on earth is C?!

...and so on.

If you continue to dig deeper and deeper and deeper, into every tiny little detail, you are much more likely to quit your learning journey, and it will only be because you feel overwhelmed.

And if by some miracle you haven't given up, you're going to spend a much, much longer time trying to learn some basic skills you might need for a job.

How Do You Embrace Abstractions?

As you're learning, you're going to have to get comfortable with not fully understanding some things in your learning journey.

You can just "abstract" this knowledge away, and stick to the things that are relevant to what you're currently doing.

Don't chase down every tiny little detail that you encounter if you are new in your learning journey. Truth is, even the experts don't know everything! They normally know lots of things in a narrow area.

One Day You Can Dig into the Abstractions

I don't want this article to come across like I am saying you should never delve below the abstractions you use everyday. But what I am saying is it won't help you to delve into the abstractions before you have spent a decent time coding first.

You should try to learn things as you need to learn them if you are early in your journey to become a developer.

After all, learning to code is hard enough, without committing to learning the entire ecosystem before even understanding the basics.

Once you start to become comfortable in your learning journey, and want to improve your skills, then learn how your abstractions work.

Conclusion

I hope this has been useful, and is encouraging if you are feeling overwhelmed with everything you're currently learning.

I tweet my articles here if you would like to read more.

For a drawing, this could be reducing it to its basic lines and shapes. Naturally, there are many levels of an abstraction, since what is inessential is subjective.

This is illustrated in the image below showing a Greek temple and two drawings at different levels of abstraction.

Example of abstraction

As you abstract away more of the details of the temple, you are left with something very simple. In its most basic form, a Greek temple can be thought of as a triangle sitting on top of a rectangle with vertical lines going across the rectangle.

Abstractions are everywhere around us. Google Maps is a good example of this. You can have a satellite, roadmap, terrain, traffic, cycling, public transport or street view, among others. Each of these options abstracts away some details, allowing you to focus on what you want to see.

Even a satellite map is an abstraction, since it is a point in time snapshot and cannot capture every new house, tree, or blade of grass.

The key point is that an abstraction simplifies something by hiding away the underlying details. It is a way of managing complexity.

But there is always a price to be paid. In exchange for hiding away complexity, you lose some lower level details which often means a loss of control if things go wrong.

Abstractions in the Cloud

In cloud computing, abstractions are everywhere. When you choose a particular technology to solve a problem, you are implicitly choosing a level of abstraction.

There are four broad levels of abstraction in cloud computing. These are called the service models:

• IaaS (Infrastructure as a Service)

• PaaS (Platform as a Service)

• FaaS (Function as a Service)

• SaaS (Software as a Service).

These four broad service models are just a guide for splitting out the different levels of abstraction in cloud computing. You can think of them more like well thought-out opinions, rather than some hard rule of physics.

Some people only consider IaaS, PaaS and SaaS as the service models, ignoring FaaS. Others will include Container as a Service, Security as a Service, Database as a Service, and so on.

The examples can go on and on by simply appending “as a service” to different technologies. This makes sense since you can abstract at different levels, which makes any abstraction of the cloud a spectrum of possibilities.

Just like the Greek temple shown above, there can be many intermediary levels of abstraction between a life-like drawing of the temple and a drawing with a triangle sitting on top of a rectangle.

When you choose to use cloud computing instead of an on-premise solution, you are effectively choosing to abstract away some of the underlying tasks and pieces of infrastructure that you would otherwise need to manage.

The figure below shows the differences between an on-premise solution and IaaS, PaaS, FaaS, and SaaS.

Figure illustrating the differences between an on-premise solution vs IaaS, PaaS, FaaS, and SaaS.

As you move to the right in the above illustration, you abstract away more of the underlying infrastructure stack. This reduces the complexity of what you are trying to build, since there are fewer things to build and manage.

But the price you pay for this reduction in complexity is a loss of control. Sometimes, that is a worthy price to pay, and sometimes it is not.

On-Premise Solutions

You are responsible for managing everything in the infrastructure stack, from the physical security of the data centre to the application itself.

In this case, almost nothing is abstracted away. This gives you increased control and flexibility to customise what you want. In exchange for that, you pay the price of managing the entire stack and bearing the risks associated with that.

This is analogous to opening a pizza restaurant, but instead of just renting some space, you build the restaurant from scratch.

Building a pizza restaurant from the ground up is like managing on-premise solutions

The upside is you have full control over how the restaurant will look. The downside is the large upfront expenditure you will need to make for plumbing, ventilation, electrical wiring, air conditioning, heating, and so on.

You will also be plagued with questions like “Is the restaurant big enough, or is it too big?” or “How do I expand or scale down based on growing or falling demand?”. Large upfront costs and higher levels of uncertainty are the price you pay for full control.

IaaS (Infrastructure as a Service)

The physical security, data centre infrastructure, networking, servers and virtualisation (the process of creating multiple virtual machines out of a physical server) is abstracted away and managed by the cloud provider.

You are responsible for managing the operating system and everything above it in the infrastructure stack. You still get to customise what virtual machine you want, based on the choices made available by the cloud provider, and you will pay to use the virtual machine on a pay-as-you-go basis.

You don’t have to worry about purchasing more servers or cooling requirements for your servers. All of that is abstracted away and managed for you.

Virtual machines/instances are a good example of IaaS – EC2 from AWS, Compute Engine from GCP, and VMs from Azure.

IaaS is analogous to simply renting some space for your pizza restaurant. The electrical wiring, plumbing, heating, and so on is abstracted away since it is managed by the owner of the building.

You are responsible for paying rent to use the space, hiring chefs, a manager, waiters and cleaners, buying equipment and furniture, choosing decor, building a menu, marketing and getting customers through the door.

Still a lot of work, but all of the non-pizza making activities are hidden away, allowing you to focus on doing what you do best – making pizza.

PaaS (Platform as a Service)

Here, you manage the runtime and everything above it. The runtime is a software environment that provides the necessary resources and services for an application to run. Examples include the Java Virtual machine for Java applications, Python runtime for Python applications, and Node.js for JavaScript applications.

With PaaS, you have abstracted away all of the physical infrastructure. All you need to worry about is your runtime.

Good examples of PaaS are AWS Beanstalk and GCP App Engine. Also, managed database services like AWS RDS and GCP Cloud SQL fall under PaaS.

PaaS is analogous to opening a franchise pizza restaurant. When you open a franchise, you are provided with a pre-built restaurant space, equipment, branding, and a set of processes to follow. You are responsible for the core activities of running the restaurant such as hiring staff, managing inventory, and creating menus.

PaaS works in a similar way, providing developers with a pre-built platform that abstracts away the underlying infrastructure, allowing them to focus on building and deploying applications.

FaaS (Function as a Service)

Here, you manage the functions and the application while the cloud provider manages the rest.

What exactly is a function and how is it different from a runtime? A function is a block of code that performs a specific task, while a runtime is the environment in which that code is executed.

Functions are typically triggered by events such as HTTP requests, database updates, or messages from a queue. When an event occurs, the function is automatically executed, and the result is returned to the calling application.

This is analogous to hiring a freelance pizza chef to cook for you on-demand. When you hire this freelance chef, though, you only pay for the time they spend cooking. The chef starts getting paid in reaction to an event, that is the moment an order comes in, and stops getting paid once the pizza is ready. The rest of the time, the chef is just idle, waiting for the next order but not costing you any money.

Ignoring the corporate sleaze and potential illegality of such a practise, doing something like this will save you money since you are only paying for the duration of a pizza being made.

SaaS (Software as a Service)

Here, you don’t manage anything, but simply consume the service offered. Prime Video, Gmail, and Outlook are great examples of SaaS. When you use these, you don’t care about how the application works. All of that is abstracted away. You simply access the software through a web browser or a mobile app and use as needed.

Drawing on the restaurant analogy, this can be compared to simply ordering a pizza from the restaurant. The restaurant abstracts all the the steps needed to make the pizza.

Examples of IaaS, PaaS, FaaS & SaaS

The table below shows examples of IaaS, PaaS, FaaS and SaaS offerings from the main cloud providers – AWS, GCP & Azure.

Bringing it Together with an Example

If you are building a e-commerce site like Amazon.com, you will need a transactional database to store details about customers like their names, payment details, address, orders, inventories, and so on. How do you choose the right level of abstraction for your database?

You have four options to choose for you database. Starting from the option that abstracts the most from the infrastructure stack:

1. You could choose the use a FaaS option like AWS Aurora Serverless. This automatically starts up the database when it is being used and shuts it down when not in use, allowing you to save money by only paying for when it's in use. This is ideal for an infrequently used database with unpredictable workloads

2. You could choose a PaaS option like AWS RDS. This is a managed database where AWS abstracts away and manages administrative tasks like OS patching, scaling, database backups and other admin tasks that would otherwise require a database admin (DBA) to manage

3. You could choose an IaaS option by installing a relational database management system (RDBMS) like MySQL on an EC2 instance. AWS will manage the hardware, but you will be responsible for managing the OS and the database application. So, admin tasks like OS patching, scaling, database backups, among others, will be your responsibility

4. You can choose an on premise solution. Here, you will self-host the database and manage the hardware yourself, in addition to all the database admin tasks as described above

Which is the right option to choose? First, it depends on your use case and the benefits and tradeoffs you are comfortable with. This is trite but nevertheless true.

However, a good heuristic that will work most of the time for most problems is to focus on what to avoid. You generally want to avoid an extreme or outlier solution, unless the problem you are trying to solve is indeed extreme or an outlier. And most problems, by definition, cannot be outliers.

The FaaS option using Aurora, and the on premise solution are not ideal, unless your use case specifically demands the features that these options posses.

Aurora serverless is not a very popular service, so finding patterns for integration with other technologies or help with troubleshooting technical problems may be more difficult. Also, there can be some technical issues with using a serverless database like Aurora.

For example, waking it up from an idle state in response to a request can sometimes take a few seconds. And this can be a delay long enough to lose a customer on your e-commerce application.

The on premise solution is not ideal either, because an e-commerce application will have fluctuations in demand as a result of holidays, discounts or some product going viral. On premise solutions are bad at handling large fluctuations in demand.

This simple heuristic of focusing on what to avoid yields two acceptable solutions – the IaaS option of running your database on an EC2 instance or the PaaS option of using a managed database service like RDS. Either of these is fine for the use case described.

The key point to remember is that an abstraction simplifies something by hiding away the underlying details. It is a way of managing complexity.

The higher abstraction solution of using RDS is the less complex solution, since AWS manages all of the underlying complexities of OS patching, scaling, database backups and other admin tasks. The price you pay for this reduction in complexity is less control of the database and a higher AWS bill.

I hope this helps you choose the solution that's right for you. Thank you for reading!

I will explain what they are in simple terms, but my main goal is to change how you think about abstractions in general. All of this is in service of helping you develop the art of programming.

These are the topics I will cover:

• What is an abstraction?

• How to use abstractions in your programs
  – How to use interfaces and protocols
  – How to use function types and lambda expressions

• Is abstraction the most important idea in programming?

• How much abstraction do I need?

The code samples will be in Kotlin, but I have written the article assuming you only have basic programming knowledge in any industry standard language.

I also use a variety of approaches to cover both object-oriented and functional styles of code.

What Is An Abstraction?

To begin with, we will discuss what this term means in the most general sense. Here is a simplified definition I have come up with for an abstraction:

“A less detailed representation of an object or concept in nature.”

I know my definition sounds very vague, but we will discuss some clear examples shortly. First, we must understand what detail is.

What Is Detail?

Detail refers to the quantity, or density perhaps, of information. Here are two examples of data models which are more and less detailed:

User {
  name,
  id
}

User {
  name: String,
  id: Integer,
  phone: Integer,
  email: String
}

There is no need to overthink this point! More details is another way of saying more information or more complexity.

The only other key point is to understand what a representation is.

How to Represent Something

Suppose you are going to travel somewhere which has a particularly deadly kind of venomous snake. In order to gain information about this snake, you have a few different options:

• Read a verbal description of the snake and its behaviour

• Look at a drawing or picture of the snake

• Listen to audio of what it sounds like when behaving aggressively

All of the above points are examples of different kinds of representations, or abstractions, of the venomous snake.

In each case, some pieces of information, which accurately represent properties of the real snake, are conveyed. However, neither a verbal description, nor an image, nor a recording can bite you!

Here we see the main utility of abstractions: Conveying important information (also known as details or properties) of an object or concept, while leaving out the unnecessary information.

How to Use Abstractions In Your Programs

Before we discuss some specifics, it is worth mentioning that everything in a computer program is technically an abstraction.

In fact, programming languages, as well as all forms of mathematics, are systems of abstractions.

However, programmers tend to think of abstractions as a narrow band of software entities usually referred to as:

• Interfaces or Protocols

• Abstract Classes

• Function Types/References/Signatures

• Super/Parent-Classes

Unfortunately, the names and mechanics of the above software entities can vary substantially in different programming languages.

For this reason, I will take two examples which may be more or less appropriate to your preferred languages:

1. An interface or protocol (which will also cover abstract classes)

2. A function type or method reference

In any case, don't worry so much about the names or any minor differences in how these things work across languages. Instead, I invite you to focus on the general ideas.

How to Use Interfaces and Protocols

I will use the term interface from here on, but this term is synonymous with protocol. I will also use the term function synonymously with method.

Interfaces allow you to define behaviour of functions, classes, or objects, without defining their implementation.

Don't worry, I am not like some teachers who throw out some jargon and pretend like I am teaching you something.

Let's look at exactly what I mean by behaviour and implementation.

Behaviour literally means a function declaration:

interface UserDataSource {
//this line below has a function declaration but no function "body"
  fun getUserById(id: String): User?
}

data class User(
  val id: String,
  val someData: Any
)

You can see the footnotes below regarding my usage of the term “function declaration.”

To translate this into English, this function declaration says the we are defining a function which:

• Is named “getUserById”

• Accepts a String type called “id” as an argument when called

• Returns a “User” or a null value if no user exists (this is because we have a “?” after the “User” type)

Implementation refers to the function body:

//Note that ":" is short for extends/implements in Kotlin for the class
//declaration
class UserDatabase(): UserDataSource {
//the curly braces, and everything between them, is the implementation
  override fun getUserById(id: String): User? {
    var user: User? = null
    //… not important for this example
    return user
  }
}

Another name for the function inside of the interface is an abstract function. Hopefully, our discussion on abstract meaning “less detail” is starting to make more sense here!

Some notes for accuracy:

1. Some languages have features to define properties, variables, and even implementations (that is, function declarations + function bodies) within interfaces. This does not change the primary purpose of interfaces, though.

2. The term function declaration will be defined differently depending on the language. Instead of worrying about verbal definitions, please consider my code examples to follow what I mean.

What About Abstract Classes?

Apart from in Python (and perhaps other languages I am not aware of), abstract classes are very similar to interfaces except for one key difference: a class may only inherit from a single abstract class.

In my opinion, before languages started to include ways for interfaces to define their own implementations, the use of abstract classes versus interfaces was clear:

• If you only want to share behaviour across a set of software entities, use an interface

• If you want to share implementation and behaviour, use an abstract class instead

Unfortunately, this distinction is very blurry since many languages now have features to add implementation to interfaces (like Java’s Default Methods).

The only general recommendation I can make which does not account for the specific details of any particular programming language is this: Use the simplest construct to get the job done.

How to Use Function Types and Lambda Expressions

There are different ways to achieve abstraction without defining interfaces or classes. But the amount of structure these language features require is still subject to language specifics.

Kotlin provides enough of these features that you will hopefully be able to make some connections with your preferred languages.

How to Use Function Types Instead Of An Interface

We will start with a practical example and then explain the finer details part by part.

Suppose we want to set up an abstract function (recall that this means a function with no implementation) to handle a click event.

Using something like an interface, we could do the following:

//assume this is an platform/OS component that tells you when
//a user clicks something on screen
class PlatformComponent(
  var clickListener: ClickListener? = null
) {
  fun userClickedScreen() {
    //Note: the "?" means handleClick() is only
    //called when clickListener is NOT NULL
    clickListener?.handleClick()
  }
}
//This interfaces hides (abstracts) the concrete class/type
//which handles the click
interface ClickListener {
  fun handleClick()
}
//This concrete class/type handles the click
//by extending the interface
class ScreenController() : ClickListener {
  override fun handleClick() {
    println("Click handled.")
  }
}

fun main() {
  PlatformComponent(
    ScreenController()
  ).userClickedScreen()
}

An alternative approach is to use a function type instead of an interface:

fun main() {
  val controller = ScreenController()
  val component = PlatformComponent(
    //The double colon tells the compiler that we are referring to
    //the function handleClick defined in ScreenController
    controller::handleClick
  )
  component.userClickedScreen()
}

//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    //This is equivalent to calling ScreenController.handleClick(),
    //but PlatformComponent does not know that. Abstraction!
    clickListener()
  }
}
//This concrete class/type handles the click
class ScreenController() {
  fun handleClick() {
    println("Click handled.")
  }
}

In this example, we can see how there is even less structure required to achieve the same result. But keep in mind that having less structure does not immediately imply better code. Really, it depends.

In any case, with a practical example in mind, we can break down how this code actually works in more detail.

How to Use Function References

If you are unfamiliar with how function types, method references (or whatever else they are called) work, this section explains them in Kotlin. Feel free to jump to the next section if you are already familiar.

Similar to most modern programming languages, we can create a reference variable to a particular function in Kotlin:

var clickListener: () -> Unit

In Kotlin, function types have the following syntax:

(optional list of parameter types) -> return type

For example:

• (Int, Int) -> Int means that the associated function must take in two Int parameters, and return a single Int

• () -> Unit means that a function has no parameters and executes without returning a meaningful value

Unit is roughly equivalent to Java’s void return type or Python’s None type – at least in principle.

When it comes time to call (invoke) a function reference, we have two options:

• clickListener() for short

• clickListener.invoke() is the full syntax, which is necessary when making null-safe calls like clickListener?.invoke(), for example

How to Use Lambda Expressions

In the previous example, it is worth noting that ScreenController does not care what the actual function it is invoking happens to be named.

We can take this level of abstraction even further, by not even defining a ScreenController:

fun main() {
  //note that the outer parenthesis are optional in Kotlin,
  //but may make this easier to understand
  val component = PlatformComponent(
    { println("Click handled.") }
  )
  component.userClickedScreen()
}
//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    clickListener()
  }
}

Unlike the previous examples, this one is not intended to resemble a practical scenario – just to demonstrate a lambda expression.

The actual lambda expression is this:

{ println(“Click handled.”) }

As you can see, it does not get much more abstract than a lambda expression.

On the surface, it's almost like defining only the implementation but not the behaviour. But at least in Kotlin, the lambda expression must conform to the type we are assigning it to.

In this case, { println(“Click handled.”) } has no parameters and does not return a meaningful value. So it conforms to () -> Unit.

Which Approach Should I Use?

You may wonder which approach you should be using – assuming your language allows for multiple approaches.

The most accurate answer I can give you is that there is no general rule.

Plenty of teachers these days will say “x is worse than y” or simply “x is bad,” because it works great for clickbait and search engine optimization.

But a language, platform, code construct, architecture, and just about anything else can only be judged good, bad, better, or worse relative to your requirements.

In fact, different requirements are the reason we have languages as different as Python and Java which are both extremely popular.

So instead, try different approaches and be skeptical of anyone who makes absolute statements without discussing requirements.

Is Abstraction the Most Important Idea in Programming?

The point of this article was never to say: “Using interfaces and abstract classes everywhere will make you a better programmer.”

In fairness, as many developers do, I went through a phase around 2016–2018 where I did actually think that statement was pretty accurate.

Instead, the point of this article is to explain two things:

• Abstraction in programming, in my opinion, should not specifically mean abstract classes, or any particular code construct

• Abstraction in programming is a process by which we design our software entities according to how much detail they internally (privately) contain and externally (publicly) provide

In a sense, every decision we make about the structure of our code, regardless of the language, comes down to this process of abstraction.

With that being said, how do we know when making some aspect of our program more abstract is beneficial, useless, or detrimental?

How Much Abstraction Do I Need?

I can only think of one kind of situation where you should strongly consider using something like an interface or function type.

Recall that these software entities provide variability of implementation but consistent behaviour. Further, that implementation typically refers to the body of a function.

Two things follow from that observation:

• If no variability of implementation is required, there is not likely to be a benefit of using a more abstract software entity.

• If variability of implementation is required, using a more abstract software entity is likely beneficial.

We will now discuss two situations I have encountered where variability is a requirement.

How to Make Your Code Easier to Test

Suppose that we have some kind of software entity, which must request some user data from a database or network adapter:

class PresentationLogic(
 val datasource: Datasource
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

class Datasource() {
    fun getData(): Data {
        var someData = getLocalOrRemoteData()
        //... error handling and so on

        return someData
    }
}

Also suppose that we want to test PresentationLogic without needing a real datasource to supply the data.

There are a few different ways to solve this problem (see the note below), but a simple solution is to make the datasource more abstract:

class PresentationLogic(
 val datasource: DatasourceInterface
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

interface DatasourceInterface {
    fun getData(): Data
}

From there, we can create a fake implementation of the datasource in a test environment:

class FakeDatasource(): DatasourceInterface {
        override fun getData(): Data {
            return Data()
        }
}

@Test
fun testLogic() {
    val logic = PresentationLogic(
       //here we provide the fake version
       FakeDatasource()
    )
}

Using abstraction, PresentationLogic does not know or care whether it is talking to a fake or real datasource. By extension, it does not need to change to work with either of them. Variability of implementation!

Note that there are other way to achieve this variability apart from using an interface. You could use a mocking library, or configure a build tool to swap out implementations.

There is no clear answer to which approach is better outside of discussing specific requirements.

Also, note that this approach would not actually work unless the details of how the datasource is created are kept separate from PresentationLogic.

This is commonly referred to as Dependency Injection, which I will discuss in a separate article.

How to Work With Different Versions and Vendors of a Service

Suppose that for some reason, you must work with different versions or vendors of the same service depending on different requirements.

An example could be supporting both AWS and Firebase to store the same data. Another example could be supporting a legacy version of a service along with a newer version of that same service.

In any case, it is another situation where variability of implementation is expected.

The code examples we will discuss have the following requirements:

• A client program must use three services, all from different vendors, to perform the same behaviour

• The decision to choose a particular service is determined at runtime based on the environment (platform, OS, hardware, and so on) of the client program

For those wondering, “client” in this context is a generic word for some program or software entity which uses other programs or software entities.

For example, YouTube’s website and mobile apps are “client apps” of YouTube’s backend servers.

Without applying any abstraction, our client program will need to know about every possible service and be told which service to choose:

fun clientProgram(
    request: Request, 
    awsService: AwsService,
    firebaseService: FirebaseService,
    parseService: ParseService
): Result {
    val use: USE_SERVICE = determineBestService()

    val result = when (use) {
        USE_SERVICE.AWS -> awsService.executeRequest(request)
        USE_SERVICE.FIREBASE -> firebaseService.executeRequest(request)
        USE_SERVICE.PARSE -> parseService.executeRequest(request)
    }

    //assume additional work is done before returning the result
    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE,
    PARSE
}

Notice that clientProgram has a parameter which refers to specific vendors of the service:

• Amazon Web Services (AWS)

• Firebase

• The now defunct Parse service from Facebook

It follows that any changes to our services will require clientProgram to be refactored (rewritten) appropriately.

The reason I chose Parse as one of the example services is specifically because it was shut down, despite being widely used. There are various reasons why a particular service may no longer fit requirements, but not working any more is a good one.

An alternative approach would be to hide all the details about the service being used from clientProgram. You could use an interface, but for variety’s sake I have used a function type instead:

fun main() {
    //Creating the services
    val awsService = AwsService()
    val firebaseService = FirebaseService()

    //determining which service to use must 
    //not be included in clientProgram
    val use: USE_SERVICE = determineBestService()

    //Assign serviceToUse to the appropriate function
    val serviceToUse: (Request) -> Result = when (use) {
        USE_SERVICE.AWS -> awsService::executeRequest
        USE_SERVICE.FIREBASE -> firebaseService::executeRequest
    }

    val request = getRequest()

    clientProgram(
       request,
       serviceToUse
    )
}


fun clientProgram(
    request: Request, 
    service: (Request) -> Result
): Result {

    val result = service.invoke(request)

    //assume additional work is done before returning the result

    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE
}

class AwsService() {
    fun executeRequest(request: Request): Result = Result()
}
class FirebaseService() {
    fun executeRequest(request: Request): Result = Result()
}

The end result of this abstraction is that we can change services without needing to change clientProgram – assuming our behaviour does not change.

I want to point out that I am not advocating that you hide every service behind some kind of abstraction. If no variability is required or expected, there may not be any benefit to extra abstraction.

Closing Thoughts

I hope it is clear when reading this article that my intention is not to push dogmatic opinions about how abstract your code should be.

As a junior and intermediate developer, it took me a few years to realize that it really does depend on project requirements.

I also hope that this article gave you some new ideas and perspectives about what abstraction is and how it can be applied in your code. Good luck and happy coding!

Before you go...

If you liked this article and want more information on these principles and code constructs, check out my free, full length programming fundamentals course. It includes professionally written English, Burmese, and Arabic subtitles.