Abstraction in Your Code

Now we know what an abstraction is, but how does it apply to code?

All code can be categorized into either policy or detail.

• Policy: These are entities and business logic.

• Detail: This is the implementation of the policy. The detail enforces the policy.

Let’s say you have a User entity. The user has a certain interface, and also some business logic. This User entity also has groups, and you’ve been assigned to write code that will get all the user groups.

Here, the policy is the user itself as it’s an entity, but also it’s the getUserGroups function, as it’s the business logic related to that entity.

How it’s implemented, which database (DB) is used, which ORM (object-relational-mapping) is used, which libraries are used, how that code is written and all of the different implementations are the detail part of your code.

Creating abstraction layers helps improve your code drastically by providing three major benefits: centralization, simplicity and better testing.

In your code, you want to expose the policy while hiding the detail. This decoupling between your policy and detail allows you to switch and easily refactor implementation.

If your policy and detail are coupled, you’ll have a hard time refactoring, as they will be mixed and changes will propagate from one to another.

In a well-designed system, a separation between policy and detail is key.

So how does this apply to abstraction layers?

Example of Creating an Abstraction Layer

Let’s say you’re writing the code for a group creation API:

function createUserGroup(group, userId) {
        logger.info('Creating group for user ${userId}')
        db.startTransaction();
        const isValidGroup = validateGroup(group);
        if (!isValidGroup) throw new Error('Invalid group');
        db.addDoc('groups', group)
        dc.addDoc('quotas/groups', 1)
        .
        .
        .
    }

As you can see in the short example, this function logic is mixed with policy and detail. It does many different things, and it does not use any abstraction layers.

Here’s code that uses abstraction layers:

class GroupsService {
    GROUPS_COLLECTION = 'groups';
 
    createGroup() {
        db.startTransaction();
        
        const isValid = this.validateGroup();
        if (!isValid) throw new Error('Invalid group')
        
        db.addDoc(GROUPS_COLLECTION, group)
        quotasService.setQuota('/groups', 1);
        
        db.finishTransaction();
    }
    
    validateGroup()
    deleteGroup();
}
 
class QuotasService {
    setQuota(collection: string, value: any) {
        dc.addDoc(`quotas/${collection}`, value)
    }
}
 
function createUserGroup(group, userId) {
    logger.info(`Creating group for user ${userId}`)
    groupsService.createGroup();
    
    return {
        status: 200,
        message: 'Group created successfully'
    }
}

There are multiple benefits from the second implementation:

1. It’s easier to understand, as implementation details are abstracted, and you are reading code that interacts with the policy.

2. Everything is centralized in one service. Imagine the code related to the Groups spread across the app. Each change made will need to happen everywhere; it will be problematic, to say the least.

3. Code is more encapsulated. Notice how the controller createUserGroup is not aware of quota now and only aware of group creation because the quota is irrelevant.

4. We can focus on testing implementation while replacing just the details layer with test doubles, making testing easier. For an integration test, we can replace the QuotaService and the GroupService and test the implementation of that specific controller implementation.

Possible Applications

Abstraction layers can be implemented in many different ways, among the top use cases are:

1. Creating leaner components by separating policy and detail : Your code will pass the test of time if changes and refactoring are easy. Separating policy and detail while keeping interactions between components only with the interface provides the infrastructure needed for future code evolution.

2. Wrapping a third-party library : Having an outdated third-party library in your code that prevents you from upgrading other dependencies is a nightmare. Or even worse, if that dependency has a security risk.

By wrapping your third-party libraries with your own interface in one central abstraction layer, changes will be easy because they will only need to be made in that one place where the interface is exposed.

3. Creating a utility service : Utility services are a crucial way to increase development speed and also reuse generic pieces of code.

If you’re working on a feature that deals a lot with different time and dates functionality for example, why not create a couple of utility functions to help you and put them in one place for further reuse?