Abstraction in OOP: A Checkout That Ignores Payment Details

OOP in Practice · Episode 2 of 70 · OOP Foundations · Beginner · TypeScript 7.0.2 on Node.js v22.23.4

Step 1: Identify the objects and responsibilities

The verb every payment method shares is “charge this amount”. That verb becomes the interface.

Step 2: The naive approach and why it breaks

type Payment =
  | { kind: "card"; cardNumber: string; limitLeft: number }
  | { kind: "upi"; vpa: string }
  | { kind: "wallet"; balance: number };

function checkout(totalPaise: number, p: Payment): string {
  if (p.kind === "card") {
    if (totalPaise > p.limitLeft) return "DECLINED card limit exceeded";
    p.limitLeft -= totalPaise;
    return `PAID card ••••${p.cardNumber.slice(-4)}`;
  } else if (p.kind === "upi") {
    if (!p.vpa.includes("@")) return "DECLINED bad UPI id";
    return `PAID UPI ${p.vpa}`;
  } else if (p.kind === "wallet") {
    if (totalPaise > p.balance) return "DECLINED wallet balance";
    p.balance -= totalPaise;
    return "PAID wallet";
  }
  return "PAID"; // unknown kind falls through as success
}

This compiles under --strict and works for three methods. It breaks as soon as the business changes:

• Adding a gift card edits checkout, plus every other function that switches on kind.
• A missed branch becomes a free order. Add "giftcard" to the union, forget the branch, and the final return "PAID" still compiles. Nothing was charged. An unexpected kind from JSON does the same.
• Checkout holds card numbers it never needed, so every checkout test builds fake card data.
• Nothing is private. Any caller can set balance, which undoes encapsulation.

Step 3: The design

            +------------------------------+
            |           Checkout           |
            |------------------------------|
            | pay(items, method): Receipt  |
            +--------------+---------------+
                           | depends only on the interface
                           v
          +-----------------------------------+
          |   <<interface>> PaymentMethod     |
          |-----------------------------------|
          | readonly label: string            |
          | charge(amountPaise, orderId)      |
          |     : ChargeResult                |
          +-----------------------------------+
             ^          ^           ^          ^
             |          |           |          |   implements
  +----------+--+ +-----+------+ +--+-------+ +-+------------+
  | CardPayment | | UpiPayment | | Wallet-  | | GiftCard-    |
  | #number     | | vpa check  | | Payment  | | Payment      |
  | #limitLeft  | |            | | #balance | | #balance     |
  +-------------+ +------------+ +----------+ +--------------+

Wikipedia’s definition fits well: an abstraction “provides access while hiding details” (Abstraction (computer science)). Checkout needs “charge this amount”, not card limits.

So Checkout points at one interface and never names a concrete class. Each payment class keeps its state in JavaScript private fields (#balance), which code outside the class cannot reference (MDN: private elements).

Interchangeable classes behind one interface is what the Strategy pattern formalises (Refactoring.Guru: Strategy). It gets its own episode, and calling charge() on whichever object you were given is polymorphism.

Step 4: The abstraction in OOP solution in TypeScript

// Abstraction in OOP: checkout depends on a PaymentMethod contract,
// not on card, UPI or wallet internals. Amounts are integer paise (₹1 = 100).

type ChargeResult =
  | { ok: true; reference: string }
  | { ok: false; reason: string };

/** The abstraction: everything checkout needs from a payment method. */
interface PaymentMethod {
  readonly label: string; // safe to print on a receipt
  charge(amountPaise: number, orderId: string): ChargeResult;
}

class CardPayment implements PaymentMethod {
  readonly label: string;
  #number: string;
  #limitLeft: number;
  constructor(cardNumber: string, limitPaise: number) {
    if (!/^\d{16}$/.test(cardNumber)) throw new Error("card number must be 16 digits");
    this.#number = cardNumber;
    this.#limitLeft = limitPaise;
    this.label = `Card ••••${cardNumber.slice(-4)}`;
  }
  charge(amountPaise: number, orderId: string): ChargeResult {
    if (amountPaise > this.#limitLeft) return { ok: false, reason: "card limit exceeded" };
    this.#limitLeft -= amountPaise; // a real gateway call would use this.#number here
    return { ok: true, reference: `CRD-${orderId}` };
  }
}

class UpiPayment implements PaymentMethod {
  readonly label: string;
  constructor(vpa: string) {
    if (!/^[\w.-]+@[a-z]+$/.test(vpa)) throw new Error(`invalid UPI id "${vpa}"`);
    this.label = `UPI ${vpa}`;
  }
  charge(_amountPaise: number, orderId: string): ChargeResult {
    return { ok: true, reference: `UPI-${orderId}` };
  }
}

class WalletPayment implements PaymentMethod {
  readonly label = "Wallet";
  #balance: number;
  constructor(balancePaise: number) {
    this.#balance = balancePaise;
  }
  charge(amountPaise: number, orderId: string): ChargeResult {
    if (amountPaise > this.#balance) {
      return { ok: false, reason: `wallet has only ${rupees(this.#balance)}` };
    }
    this.#balance -= amountPaise;
    return { ok: true, reference: `WAL-${orderId}` };
  }
}

interface LineItem {
  readonly name: string;
  readonly unitPaise: number;
  readonly qty: number;
}

interface Receipt {
  readonly orderId: string;
  readonly totalPaise: number;
  readonly via: string;
  readonly result: ChargeResult;
}

/** Knows carts, totals and order ids. Knows nothing about how money moves. */
class Checkout {
  #nextOrder = 1;
  pay(items: readonly LineItem[], method: PaymentMethod): Receipt {
    if (items.length === 0) throw new Error("cart is empty");
    for (const i of items) {
      if (!Number.isSafeInteger(i.unitPaise) || i.unitPaise <= 0) throw new Error(`bad price for ${i.name}`);
      if (!Number.isSafeInteger(i.qty) || i.qty < 1) throw new Error(`bad quantity for ${i.name}`);
    }
    const totalPaise = items.reduce((sum, i) => sum + i.unitPaise * i.qty, 0);
    const orderId = `ORD-${String(this.#nextOrder++).padStart(3, "0")}`;
    return { orderId, totalPaise, via: method.label, result: method.charge(totalPaise, orderId) };
  }
}

function rupees(paise: number): string {
  return `₹${(paise / 100).toFixed(2)}`;
}

function show(r: Receipt): void {
  const status = r.result.ok ? `PAID     ref ${r.result.reference}` : `DECLINED ${r.result.reason}`;
  console.log(`${r.orderId}  ${rupees(r.totalPaise)}  ${r.via.padEnd(18)} ${status}`);
}

// ── Added later: a new payment method. Checkout is not edited. ──
class GiftCardPayment implements PaymentMethod {
  readonly label = "Gift card";
  #balance: number;
  constructor(balancePaise: number) {
    this.#balance = balancePaise;
  }
  charge(amountPaise: number, orderId: string): ChargeResult {
    if (amountPaise > this.#balance) return { ok: false, reason: "gift card balance too low" };
    this.#balance -= amountPaise;
    return { ok: true, reference: `GFT-${orderId}` };
  }
}

// ── Demo ──
const cart: LineItem[] = [
  { name: "Notebook", unitPaise: 12_000, qty: 2 },
  { name: "Pen", unitPaise: 2_500, qty: 3 },
];
const checkout = new Checkout();
const card = new CardPayment("4111111111111111", 50_000);
const methods: PaymentMethod[] = [card, new UpiPayment("asha@okbank"), new WalletPayment(20_000), new GiftCardPayment(100_000)];

console.log("Same cart, four payment methods:");
for (const m of methods) show(checkout.pay(cart, m));

console.log("\nSecond order on the same card (limit ₹500.00):");
show(checkout.pay(cart, card));

console.log("\nA test double is just an object with the right shape:");
const timeout: PaymentMethod = { label: "Test double", charge: () => ({ ok: false, reason: "gateway timeout" }) };
show(checkout.pay(cart, timeout));

console.log("\nRejected before any money moves:");
const bad: Array<[string, () => unknown]> = [
  ["empty cart", () => checkout.pay([], card)],
  ["zero quantity", () => checkout.pay([{ name: "Pen", unitPaise: 2_500, qty: 0 }], card)],
  ["bad UPI id", () => new UpiPayment("asha at okbank")],
];
for (const [name, attempt] of bad) {
  try {
    attempt();
    console.log(`  ${name}: accepted (unexpected)`);
  } catch (e) {
    console.log(`  ${name}: ${(e as Error).message}`);
  }
}

• The interface is tiny on purpose. Anything you add, every payment method must implement.
• implements PaymentMethod is a check, not a conversion. The handbook says an implements clause “is only a check that the class can be treated as the interface type” (TypeScript Handbook: implements clauses). It flags a misspelled charge at the class.
• Declines are values, not exceptions. ok tags the union, so you must check it before reading reference.
• Bad input throws before any charge. Prices and quantities must pass Number.isSafeInteger (MDN).
• readonly label can be set only in the constructor (TypeScript Handbook: readonly).
• The gift card is one new class. Checkout is not edited.

Step 5: Run it and check the output

Same cart, four payment methods:
ORD-001  ₹315.00  Card ••••1111      PAID     ref CRD-ORD-001
ORD-002  ₹315.00  UPI asha@okbank    PAID     ref UPI-ORD-002
ORD-003  ₹315.00  Wallet             DECLINED wallet has only ₹200.00
ORD-004  ₹315.00  Gift card          PAID     ref GFT-ORD-004

Second order on the same card (limit ₹500.00):
ORD-005  ₹315.00  Card ••••1111      DECLINED card limit exceeded

A test double is just an object with the right shape:
ORD-006  ₹315.00  Test double        DECLINED gateway timeout

Rejected before any money moves:
  empty cart: cart is empty
  zero quantity: bad quantity for Pen
  bad UPI id: invalid UPI id "asha at okbank"

Tested: TypeScript 7.0.2 on Node.js v22.23.4 — tsc --strict --target es2022 --module commonjs main.ts && node main.js, 2026-11-13. Output above is copied from that run.

Checkout treats all four methods the same way. The card’s second order is declined because the first used ₹315.00 of its ₹500.00 limit.

The test double is a plain object. TypeScript accepts it because type compatibility “is based on structural subtyping” (TypeScript Handbook: Type Compatibility).

Why this design works

• Abstraction: checkout depends on what a payment method does, not how.
• Encapsulation: each class keeps its limit or balance in a # field. Abstraction hides which class you have; encapsulation protects its state.
• Open for extension: the gift card arrived as new code, not as edits to tested code. That is the open-closed principle in miniature.
• Single responsibility: checkout owns totals and order ids; each payment class owns one way of moving money.
• Testability: any object with the right shape works, so tests need no card data.

Trade-offs, edge cases and when not to use it

Abstract classes cannot be created with new and force subclasses to implement abstract members (TypeScript Handbook: abstract classes). Choosing between them is its own episode: interface vs abstract class.

Interfaces are erased at compile time: “type annotations never change the runtime behavior” (TypeScript Handbook: Erased Types). So instanceof PaymentMethod is impossible, and JSON input is unchecked unless you validate it. Abstractions also leak; Joel Spolsky’s law says “all non-trivial abstractions, to some degree, are leaky” (Wikipedia: Leaky abstraction). Real gateways are asynchronous, which this contract cannot express yet.

My recommendation: with one implementation and no second in sight, skip the interface. Extract it when a second case or a test double appears.

Interview follow-up questions

The same solution in Python

from __future__ import annotations
import re
from abc import ABC, abstractmethod
from dataclasses import dataclass


@dataclass(frozen=True)
class ChargeResult:
    ok: bool
    detail: str  # reference when ok, reason when declined


class PaymentMethod(ABC):
    """The abstraction: everything checkout needs from a payment method."""
    label: str

    @abstractmethod
    def charge(self, amount_paise: int, order_id: str) -> ChargeResult: ...


class CardPayment(PaymentMethod):
    def __init__(self, number: str, limit_paise: int) -> None:
        if not re.fullmatch(r"\d{16}", number):
            raise ValueError("card number must be 16 digits")
        self._number, self._limit_left = number, limit_paise
        self.label = f"Card ••••{number[-4:]}"

    def charge(self, amount_paise: int, order_id: str) -> ChargeResult:
        if amount_paise > self._limit_left:
            return ChargeResult(False, "card limit exceeded")
        self._limit_left -= amount_paise
        return ChargeResult(True, f"CRD-{order_id}")


class UpiPayment(PaymentMethod):
    def __init__(self, vpa: str) -> None:
        if not re.fullmatch(r"[\w.-]+@[a-z]+", vpa):
            raise ValueError(f'invalid UPI id "{vpa}"')
        self.label = f"UPI {vpa}"

    def charge(self, amount_paise: int, order_id: str) -> ChargeResult:
        return ChargeResult(True, f"UPI-{order_id}")


class WalletPayment(PaymentMethod):
    label = "Wallet"

    def __init__(self, balance_paise: int) -> None:
        self._balance = balance_paise

    def charge(self, amount_paise: int, order_id: str) -> ChargeResult:
        if amount_paise > self._balance:
            return ChargeResult(False, f"wallet has only {rupees(self._balance)}")
        self._balance -= amount_paise
        return ChargeResult(True, f"WAL-{order_id}")


class Checkout:
    """Knows carts, totals and order ids. Knows nothing about how money moves."""

    def __init__(self) -> None:
        self._next = 1

    def pay(self, items: list[tuple[str, int, int]], method: PaymentMethod) -> str:
        if not items:
            raise ValueError("cart is empty")
        total = sum(price * qty for _, price, qty in items)
        order_id, self._next = f"ORD-{self._next:03d}", self._next + 1
        r = method.charge(total, order_id)
        status = f"PAID     ref {r.detail}" if r.ok else f"DECLINED {r.detail}"
        return f"{order_id}  {rupees(total)}  {method.label:<18} {status}"


def rupees(paise: int) -> str:
    return f"₹{paise // 100}.{paise % 100:02d}"


cart = [("Notebook", 12_000, 2), ("Pen", 2_500, 3)]
checkout = Checkout()
for m in [CardPayment("4111111111111111", 50_000), UpiPayment("asha@okbank"), WalletPayment(20_000)]:
    print(checkout.pay(cart, m))
try:
    PaymentMethod()  # the abstraction itself cannot be instantiated
except TypeError as e:
    print(f"PaymentMethod() -> {type(e).__name__}")

ORD-001  ₹315.00  Card ••••1111      PAID     ref CRD-ORD-001
ORD-002  ₹315.00  UPI asha@okbank    PAID     ref UPI-ORD-002
ORD-003  ₹315.00  Wallet             DECLINED wallet has only ₹200.00
PaymentMethod() -> TypeError

Practice: extend it yourself

• Abstraction in OOP means a caller depends on what an object does, never on how a specific class does it.
• TypeScript checks interfaces structurally: any object with the right members fits, with or without implements.
• TypeScript interfaces are erased at compile time, so instanceof cannot check them.
• Keep the abstraction small: checkout needs only a label and charge().
• With the abstraction in place, a new payment method is one new class and zero checkout edits.

References

• TypeScript Handbook — Classes: implements clauses
• TypeScript Handbook — Classes: abstract classes and members
• TypeScript Handbook — Classes: readonly
• TypeScript Handbook — Type Compatibility
• TypeScript Handbook — The Basics: Erased Types
• MDN — Private elements (#)
• MDN — Number.isSafeInteger()
• Python docs — abc: Abstract Base Classes
• Python docs — typing.Protocol
• Wikipedia — Abstraction (computer science)
• Wikipedia — Leaky abstraction
• Refactoring.Guru — Strategy pattern