Introduction

In this article, I’ll walk you through a practical implementation of encapsulation and highlight its benefits. To start, we'll look at an inefficient implementation. Why? By first examining an "inefficient example," you'll be able to clearly see the advantages of an encapsulated approach and understand why the initial approach falls short.

Before we dive in, note that this blog uses TypeScript, but the concepts and principles discussed are applicable to any object-oriented programming (OOP) language.

What is encapsulation?

Encapsulation is one of the fundamental principles in Object-Oriented- Programming (OOP). Encapsulation helps to hide the internal implementation details and exposes only the necessary parts of an object.

Think of Encapsulation as a capsule, that holds both information and the tools to work with that information and acts as a shield to the data

Encapsulation involves:

1. Data Hiding: Hiding an object's internal states and details to prevent direct access.

2. Abstraction: Hides complex implementation details and provides a simple interface to interact with the object while keeping the implementation details hidden.

3. Modularity: promotes code organization by grouping related data and methods together.

By following the principle of encapsulation, we can create a flexible, reusable, and maintainable storage class for managing data securely in an app while abstracting the underlying storage mechanisms.

Inefficient Approach: A Non-Encapsulated Solution

Let’s take a look at a 'bad example' of how we might handle secure and local storage in a React Native app without encapsulation.

import AsyncStorage from "@react-native-async-storage/async-storage";
import * as SecureStore from "expo-secure-store";

 // Non-encapsulated approach: mixing storage logic in components

 // Getting from secure storage
 async function getSecureToken() {
   const token = await SecureStore.getItemAsync("ACCESS_TOKEN");
   console.log("Secure Token:", token);
   return token;
 }

 // Getting from local storage
 async function getLocalEnv() {
   const env = await AsyncStorage.getItem("API_ENVIRONMENT");
   console.log("Local Environment:", env);
   return env;
 }

 // Setting to secure storage
 async function setSecureToken(value: string) {
   await SecureStore.setItemAsync("ACCESS_TOKEN", value);
 }

 // Setting to local storage
 async function setLocalEnv(value: string) {
   await AsyncStorage.setItem("API_ENVIRONMENT", value);
 }

 // Deleting from secure storage
 async function deleteSecureToken() {
   await SecureStore.deleteItemAsync("ACCESS_TOKEN");
 }

 // Deleting from local storage
 async function deleteLocalEnv() {
   await AsyncStorage.removeItem("API_ENVIRONMENT");
 }

Why is This Approach Inefficient?

1. Repetition of Logic: In this code, we see that the logic for interacting with secure and local storage is repeated across different functions. Every time we need to get, set, or delete an item, we write the same logic for each storage type. This results in 'code duplication,' making the code harder to maintain.

2. No Abstraction: this means, the details of how the storage works are exposed everywhere. The code is too specific. It's tightly coupled to the current way we're handling storage. If we wanted to change how we handle storage (e.g., switching from SecureStore to another secure storage solution), we would have to modify each function individually.

3. Difficult to Extend: If we later add a new storage type, we'd have to copy and paste all that storage logic again for the new type. This violates the 'Open/Closed Principle' in object-oriented design (software entities should be open for extension but closed for modification).

4. Inconsistent Interface: There is no consistent way to work with the storage. If a developer new to the project wants to interact with storage, they have to remember separate functions for secure and local storage, which is. This will create a workload for anyone trying to understand or use the storage system.

The Encapsulated Approach

Now that we've seen how things can be a mess without encapsulation, let’s explore a more structured and scalable solution by applying 'encapsulation.'.

We’ll create a Storage class that'll handle all the details for interacting with both secure and local storage, providing a cleaner, more maintainable API.

1. Define the Keys:

First, we define the keys that we will use for storing the data. These keys will be consistent across both types of storage. And they are particularly useful with TypeScript’s type inference, helping avoid errors like using incorrect key names. While the same outcome can be achieved with JSDoc

class Storage {
   static keys = {
 	REMOTE_TRACKING_CONFIG_KEY: "REMOTE_TRACKING_CONFIG_KEY",
 	LAST_LOCATION_TRACKING_STATUS: "LAST_TRACKING_STATUS",
 	API_ENVIRONMENT: "API_ENVIRONMENT",
 	DEVICE_ID_KEY: "DEVICE_ID_KEY",
 	ACCESS_TOKEN: "ACCESS_TOKEN",
 	REFRESH_TOKEN: "REFRESH_TOKEN",
   };
 }

2. Create a Helper Class for Each Storage Type

Encapsulation comes into play by creating a StorageHelper class that contains the logic for interacting with either secure or local storage. The StorageHelper class abstracts the implementation details of accessing each type of storage.

import AsyncStorage from "@react-native-async-storage/async-storage"
import * as SecureStore from "expo-secure-store"

class StorageHelper {
   constructor(private type: "secure" | "local") {}

   async setItemAsync(
 	keyName: keyof typeof Storage.keys,
 	value: string
   ): Promise<void> {
 	if (this.type === "secure") {
   	await SecureStore.setItemAsync(keyName, value);
 	} else {
       await AsyncStorage.setItem(keyName, value);
 	}
   }

   async getItemAsync(
 	keyName: keyof typeof Storage.keys
   ): Promise<string | null> {
 	if (this.type === "secure") {
   	return SecureStore.getItemAsync(keyName);
 	} else {
   	return AsyncStorage.getItem(keyName);
 	}
   }

   async deleteItemAsync(keyName: keyof typeof Storage.keys): Promise<void> {
 	if (this.type === "secure") {
   	await SecureStore.deleteItemAsync(keyName);
 	} else {
   	await AsyncStorage.removeItem(keyName);
 	}
   }
 }

3. Create Factory Methods for Secure and Local Storage

Now, we modify the main Storage class to provide factory methods for creating instances of StorageHelper that interact with secure or local storage.

class Storage {

   static keys = {
 	REMOTE_TRACKING_CONFIG_KEY: "REMOTE_TRACKING_CONFIG_KEY",
 	LAST_LOCATION_TRACKING_STATUS: "LAST_TRACKING_STATUS",
 	API_ENVIRONMENT: "API_ENVIRONMENT",
 	DEVICE_ID_KEY: "DEVICE_ID_KEY",
 	ACCESS_TOKEN: "ACCESS_TOKEN",
 	REFRESH_TOKEN: "REFRESH_TOKEN",
   };

   static secure() {
 	return new StorageHelper("secure");
   }

   static local() {
 	return new StorageHelper("local");
   }
 }

4. Final code

import AsyncStorage from "@react-native-async-storage/async-storage"
import * as SecureStore from "expo-secure-store"

class StorageHelper {
   constructor(private type: "secure" | "local") {}

   async setItemAsync(
 	keyName: keyof typeof Storage.keys,
 	value: string
   ): Promise<void> {
 	if (this.type === "secure") {
   	await SecureStore.setItemAsync(keyName, value);
 	} else {
       await AsyncStorage.setItem(keyName, value);
 	}
   }

   async getItemAsync(
 	keyName: keyof typeof Storage.keys
   ): Promise<string | null> {
 	if (this.type === "secure") {
   	return SecureStore.getItemAsync(keyName);
 	} else {
   	return AsyncStorage.getItem(keyName);
 	}
   }

   async deleteItemAsync(keyName: keyof typeof Storage.keys): Promise<void> {
 	if (this.type === "secure") {
   	await SecureStore.deleteItemAsync(keyName);
 	} else {
   	await AsyncStorage.removeItem(keyName);
 	}
   }
 }


export class Storage {

   static keys = {
 	REMOTE_TRACKING_CONFIG_KEY: "REMOTE_TRACKING_CONFIG_KEY",
 	LAST_LOCATION_TRACKING_STATUS: "LAST_TRACKING_STATUS",
 	API_ENVIRONMENT: "API_ENVIRONMENT",
 	DEVICE_ID_KEY: "DEVICE_ID_KEY",
 	ACCESS_TOKEN: "ACCESS_TOKEN",
 	REFRESH_TOKEN: "REFRESH_TOKEN",
   };

   static secure() {
 	return new StorageHelper("secure");
   }

   static local() {
 	return new StorageHelper("local");
   }
 }

5. Using the Storage Class

Now that we’ve encapsulated the logic for managing both storage types, we can interact with the storage in a more readable and convenient way. Here’s how you would use the Storage class:

## Example for Secure Storage:

Storage.secure()
   .getItemAsync("ACCESS_TOKEN")
   .then((token) => {
 	console.log("Secure token:", token);
   });
 

## Example for Local Storage:

 Storage.local()
   .getItemAsync("API_ENVIRONMENT")
   .then((env) => {
 	console.log("Local environment:", env);
   });

Setting Items:

## Set in secure storage

Storage.secure().setItemAsync("ACCESS_TOKEN", "your-secure-token");


## Set in local storage

Storage.local().setItemAsync("API_ENVIRONMENT", "production");

Deleting Items:

## Delete from secure storage
Storage.secure().deleteItemAsync("ACCESS_TOKEN");

## Delete from local storage
Storage.local().deleteItemAsync("API_ENVIRONMENT");

Benefits of Encapsulation in This Example

1. Data Abstraction: When using the Storage class, there is no need to worry about whether the data is stored securely or locally. Users only interact with a clean interface provided by StorageHelper.

2. Simplified API: The methods are like Storage.secure().getItemAsync() and Storage.local().getItemAsync() are pretty straightforward. API, becoming intuitive and easy to use. Users don’t need to remember or deal with SecureStore or AsyncStorage directly. .

3. Maintenance: All the storage related operations are contained in the StorageHelper class. If you need to modify how storage is handled or switch to a different method, you can do so seamlessly without impacting other parts of the application.

4. Flexibility: The Storage.secure() and Storage.local() methods make it easy to manage different storage types without creating redundant or complicated code.

Conclusion

This example demonstrates the importance of encapsulation and how it enhances the organization and maintainability of your code. However, this example can be further improved. For instance, you could create a StorageHelper interface or abstract class, then implement specific storage classes for various storage types (e.g., in-memory cache or IndexedDB if exporting for the web). These could be exposed through the Storage class. In this example, I’ve used just one StorageHelper class for both types of storage because there are only two types of storage.

The key takeaway is that there’s always room for improvement. By applying OOP concepts like encapsulation, you can create code that is more flexible, easier to maintain, and future-proof. This is especially important as applications grow in size, and with that growth comes increased complexity.