OOP Concepts: Abstraction

Abstraction means exposing only what’s essential and hiding implementation details behind clear interfaces. An abstraction hides complexity.

Compare this lack of abstraction:

record struct Order(double Total, ...);

public class StripeApi
{
  public void SetApiKey(string key) { ... }
  public void CreateCharge(double amount) { ... }
}

public class OrderService
{
  public string ApiKey = string.Empty;

  public void Checkout(Order order)
  {
    var stripe = new StripeApi();
    stripe.SetApiKey(ApiKey);
    stripe.CreateCharge(order.Total);
  }
}

… to:

record struct Order(double Total, ...);

interface IPaymentMethod
{
  void Process(double amount);
}

public class StripePaymentMethod : IPaymentMethod
{
  StripePaymentMethod(string apiKey);
  void Process(double amount) { ... }
}

public class OrderService
{
  public void Checkout(IPaymentMethod paymentMethod, Order order) =>
    paymentMethod.Process(order);
}

I initially had:

interface IPaymentMethod
{
  void Process(Order order);
}

… but now we have IPaymentMethod concerned with Order objects, when all IPaymentMethod should care about is $$$.

The hard part is choosing the right level of abstraction. Too abstract, e.g., doWork(), and your interface becomes meaningless. Too specific, and you haven’t actually abstracted anything. Think of it from the perspectives of the operations that the caller needs to perform.

If an abstraction doesn’t reduce cognitive load, then it’s not doing its job. There is a hump when it comes to learning new abstractions, but once you learn an abstraction in a system, does it help you reason faster and more concisely about the system?

OOP Concepts | Hello Interview Low Level Design. www.hellointerview.com . Accessed Sep 14, 2026.