How can you use encapsulation to protect sensitive data in object oriented design?

1 Why encapsulate data?

One of the main benefits of encapsulating data is that it reduces the risk of unauthorized access, modification, or leakage of sensitive information. By restricting the visibility and access of data to the object that owns it, you can prevent other objects or classes from tampering with it or exposing it to external threats. For example, if you have a class that represents a bank account, you can encapsulate the balance and account number fields as private, and only provide public methods for depositing, withdrawing, and checking the balance. This way, you can control how the data is manipulated and validated, and avoid exposing it to hackers or malicious users.

2 How to implement encapsulation in code?

To implement encapsulation in code, you need to use access modifiers that specify the level of visibility and access of your data and methods. The most common access modifiers are public, private, and protected, but some languages may have other variations. Public means that the data or method can be accessed by any object or class in the program. Private means that the data or method can only be accessed by the object or class that defines it. Protected means that the data or method can only be accessed by the object or class that defines it, or by its subclasses. For example, in Java, you can use the following syntax to encapsulate data:

class BankAccount {
  // private fields
  private double balance;
  private String accountNumber;
  // public constructor
  public BankAccount(double balance, String accountNumber) {
    this.balance = balance;
    this.accountNumber = accountNumber;
  }
  // public methods
  public double getBalance() {
    return balance;
  }
  public void deposit(double amount) {
    balance += amount;
  }
  public void withdraw(double amount) {
    balance -= amount;
  }
}        

3 How to test encapsulation in code?

To test encapsulation in code, you need to verify that the data and methods are accessible and functional according to their access modifiers. You can use unit testing frameworks, such as JUnit, NUnit, or PyTest, to write test cases that check the behavior and output of your encapsulated objects and classes. For example, in Java, you can use JUnit to test the BankAccount class as follows:

import org.junit.Test;
import static org.junit.Assert.*;
public class BankAccountTest {
  // test the public constructor
  @Test
  public void testConstructor() {
    BankAccount account = new BankAccount(1000.0, "123456789");
    assertEquals(1000.0, account.getBalance(), 0.01);
    // cannot access the private fields directly
    // account.balance; // compile error
    // account.accountNumber; // compile error
  }
  // test the public methods
  @Test
  public void testDeposit() {
    BankAccount account = new BankAccount(1000.0, "123456789");
    account.deposit(500.0);
    assertEquals(1500.0, account.getBalance(), 0.01);
  }
  @Test
  public void testWithdraw() {
    BankAccount account = new BankAccount(1000.0, "123456789");
    account.withdraw(300.0);
    assertEquals(700.0, account.getBalance(), 0.01);
  }
}        

4 How to design encapsulation in code?

Designing encapsulation in code requires following best practices and guidelines to achieve high cohesion and low coupling. Cohesion refers to the elements of an object or class being closely related and focused on a single purpose, while coupling is the degree of dependency and interaction between different objects or classes. High cohesion and low coupling make code easier to understand, reuse, and modify. To design encapsulation, you should identify data and methods that belong to each object or class, grouping them logically and consistently. Private or protected access modifiers should be used for data and methods relevant or essential to the object or class, while public access modifiers should be used for data and methods necessary for other objects or classes to interact with it. Getters and setters should be provided for data that needs to be accessed or modified by other objects or classes, with validation and error handling logic implemented in them. Additionally, internal implementation details or data structures should be avoided, with abstraction and encapsulation used to hide them behind simple and stable interfaces.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?