Composite & Adapter

Composite pattern ▶ 1:31:00 – 2:18:32

Compose objects into a tree, so the client can treat one object (a leaf) and a group of objects (a composite) in exactly the same way.

The problem

Some data is naturally a hierarchy (a tree). A file system is the classic one: a folder can hold files and other folders, and those folders can hold more files and folders.

Now you want operations like size, ls, delete, rename, cp. Without a pattern, the client code fills up with type checks: "if this is a file do X, else if it is a folder loop over its children and do Y". Every new node type means editing every one of those if blocks, which breaks the Open/Closed principle (open for extension, closed for modification).

The teacher showed it live in a terminal: ls works on LLD and on LLD/Pradeep without caring which is the parent and which is the child. rm -rf on a folder deletes everything inside it, one level at a time. The command treats parent and child the same way. That is the Composite idea.

The idea in one line

Give leaves and containers one shared interface. The container keeps a list of that interface type (not a list of files plus a list of folders) and implements each operation by calling the same method on its children.

Use it when your objects form a part-whole tree and you want the same operations on the single item and on the group.

Key words

• Component: the shared interface (FileSystemNode).
• Leaf: a node that cannot hold others (File).
• Composite: a node that holds a list of components (Folder).

Building it step by step

Step 1, the bad version. The client must know the type of every node:

# BAD: client does type checking everywhere
def size(node) -> int:
    if isinstance(node, File):
        return node.size
    elif isinstance(node, Folder):
        total = 0
        for f in node.files:          # separate list of files
            total += f.size
        for d in node.folders:        # separate list of folders
            total += size(d)
        return total
    # a new node type (e.g. Shortcut) means editing this function again

Step 2, one interface. "If there is a need to treat everything uniformly, interface is the thing." Create FileSystemNode with the operations every node must support.

Step 3, leaf and composite both implement it. In class the teacher asked: should a folder keep a list of folders, a list of files, or a list of FileSystemNode? Answer: a list of FileSystemNode, so one list holds both and the folder never cares which is which.

from abc import ABC, abstractmethod

class FileSystemNode(ABC):
    """Common contract: files AND folders both support these methods."""
    def __init__(self, name: str):
        self.name = name

    @abstractmethod
    def size(self) -> int: ...

    @abstractmethod
    def ls(self, indent: int = 0) -> None: ...


class File(FileSystemNode):          # the LEAF: cannot contain anything
    def __init__(self, name: str, size: int):
        super().__init__(name)
        self._size = size

    def size(self) -> int:
        return self._size            # a file just knows its own size

    def ls(self, indent: int = 0) -> None:
        print("  " * indent + f"File: {self.name}")


class Folder(FileSystemNode):        # the COMPOSITE: holds other nodes
    def __init__(self, name: str):
        super().__init__(name)
        self.children: list[FileSystemNode] = []   # files OR folders

    def add(self, node: FileSystemNode) -> None:
        self.children.append(node)

    def remove(self, node: FileSystemNode) -> None:
        self.children.remove(node)

    def size(self) -> int:
        # ask every child for its size; a child folder does the same in turn
        total = sum(child.size() for child in self.children)
        print(f"Total size of folder {self.name}: {total}")
        return total

    def ls(self, indent: int = 0) -> None:
        print("  " * indent + f"Folder: {self.name}")
        for child in self.children:  # same call, no type checks
            child.ls(indent + 1)


# usage
snehil = Folder("snehil")
snehil.add(File("LLDNotes", 10))
snehil.add(Folder("HLDNotes"))
payal = Folder("payal")
payal.add(File("DSANotes", 20))
root = Folder("root")
root.add(snehil)
root.add(payal)

root.size()
root.ls()
# Total size of folder HLDNotes: 0
# Total size of folder snehil: 10
# Total size of folder payal: 20
# Total size of folder root: 30
# Folder: root
#   Folder: snehil
#     File: LLDNotes
#     Folder: HLDNotes
#   Folder: payal
#     File: DSANotes

Notice: from the client side, ls and size look the same on a file and a folder. Inside, the folder does more work (a loop), the file just returns. "I don't care which type of object you are, file or folder, give me ls."

Second example (org chart), same shape:

from abc import ABC, abstractmethod

class Employee(ABC):
    def __init__(self, name: str, salary: int):
        self.name, self.salary = name, salary

    @abstractmethod
    def cost(self) -> int: ...


class Engineer(Employee):                 # leaf
    def cost(self) -> int:
        return self.salary


class Manager(Employee):                  # composite (CEO, VP, ...)
    def __init__(self, name: str, salary: int):
        super().__init__(name, salary)
        self.reports: list[Employee] = []

    def add(self, e: Employee) -> None:
        self.reports.append(e)

    def cost(self) -> int:
        return self.salary + sum(r.cost() for r in self.reports)


# usage
ceo = Manager("CEO", 100)
vp = Manager("VP", 50)
vp.add(Engineer("Asha", 20))
vp.add(Engineer("Ravi", 20))
ceo.add(vp)
print(ceo.cost())   # 190
print(vp.cost())    # 90

UML / structure

classDiagram
  class FileSystemNode {
    +name
    +size() int
    +ls()
  }
  class File {
    -size_value
    +size() int
    +ls()
  }
  class Folder {
    -children
    +add(node)
    +remove(node)
    +size() int
    +ls()
  }
  File ..|> FileSystemNode
  Folder ..|> FileSystemNode
  Folder *-- FileSystemNode : children

Read the diagram with the teacher's two relationships:

• IS-A (inheritance): File is a FileSystemNode. Folder is a FileSystemNode.
• HAS-A: Folder has a list of FileSystemNode. It is composition (a strong has-a) because of lifecycle dependency: delete the folder "snehil" and "LLDNotes" and "HLDNotes" go with it, just like rm -rf.

That is also why the pattern is called Composite: a thing of type A contains a list of things of type A. "Folder is a file system node, and folder has file system nodes."

Pros, cons, pitfalls

Homework from class: build your own small file system (folders, files, ls, size, then add rename, delete, and a parent link to walk back up). The teacher said a past student was asked "design a file system" at Rubrik and this pattern was the key.

Adapter pattern ▶ 2:18:40 – 2:52:27

A middle class that converts the interface of an existing (often third-party) class into the interface your client already expects, so two incompatible pieces can work together.

The problem

Your codebase has a PaymentProcessor interface with a pay(amount) method. Your in-house gateway (PhonePe) implements it, and every client calls processor.pay(...). Life is good.

Then management says: "Let's use Razorpay (or Stripe), they are doing good work." But Razorpay's class has a different method, make_payment(amount), and it does not implement your interface. You cannot change their code, and you do not want to rename your pay because who knows how many clients would break. The work is the same (take a payment), only the names do not match. That is an incompatible interface.

The tempting fix is an if in business code:

# BAD: business logic polluted with third-party details
def checkout(gateway_type: str, amount: int) -> None:
    if gateway_type == "stripe":
        StripeGateway().make_payment(amount)
    elif gateway_type == "razorpay":
        RazorPay().make_payment(amount)
    else:
        PhonePay().pay(amount)

Why it is bad: it violates Open/Closed (every new gateway = a new if), the business logic is polluted with third-party details, and testing becomes a nightmare.

The idea in one line

Write a new class that implements the client's interface and holds a reference to the incompatible object (the "adaptee"); each client call is translated into the adaptee's call.

Use it when you must plug a class you cannot (or should not) modify into code that expects a different interface: third-party SDKs, legacy code, deprecated APIs.

Creating a new class breaks no principle: "You guys do your own thing. I will create a new class, I will manage." Neither side is disturbed.

Building it step by step

1. Keep your target interface (PaymentProcessor.pay) exactly as it is.
2. Leave the third-party class (RazorPay.make_payment) untouched.
3. Create RazorPayAdapter that implements PaymentProcessor. Who are we adapting for? The client, because the client is the one making the call. Razorpay will not adapt to us; we adapt to Razorpay.
4. Pass the Razorpay object into the adapter's constructor and keep it.
5. Inside pay(), call self.razorpay.make_payment(amount).

from abc import ABC, abstractmethod

class PaymentProcessor(ABC):              # OUR interface; clients only know pay()
    @abstractmethod
    def pay(self, amount: int) -> None: ...


class PhonePay(PaymentProcessor):         # our in-house gateway, already fits
    def pay(self, amount: int) -> None:
        print(f"Payment of {amount} via PhonePe done")


class RazorPay:                           # THIRD-PARTY class: we cannot edit it
    def make_payment(self, amount: int) -> None:
        print(f"RazorPay processed payment of {amount}")


class RazorPayAdapter(PaymentProcessor):  # the middle layer
    def __init__(self, razorpay: RazorPay):
        self.razorpay = razorpay          # keep a reference to the adaptee

    def pay(self, amount: int) -> None:   # speak the client's language...
        self.razorpay.make_payment(amount)  # ...translate to theirs


def checkout(processor: PaymentProcessor, amount: int) -> None:
    processor.pay(amount)                 # client code never changes


# usage
checkout(PhonePay(), 100)
checkout(RazorPayAdapter(RazorPay()), 200)
# Payment of 100 via PhonePe done
# RazorPay processed payment of 200

The teacher's slides used Stripe (StripeGateway.makePayment with a StripePaymentAdapter); the live code used Razorpay. Same structure.

UML / structure

classDiagram
  class PaymentProcessor {
    +pay(amount)
  }
  class PhonePay {
    +pay(amount)
  }
  class RazorPayAdapter {
    -razorpay
    +pay(amount)
  }
  class RazorPay {
    +make_payment(amount)
  }
  class Client
  Client --> PaymentProcessor
  PhonePay ..|> PaymentProcessor
  RazorPayAdapter ..|> PaymentProcessor
  RazorPayAdapter --> RazorPay : adaptee

Pros, cons, pitfalls

• Pro: neither your code nor the third-party code changes; new gateways = new adapter classes (Open/Closed).
• Pro: third-party details stay out of business logic, so testing is easy (mock the interface).
• Con: one more class per incompatible API. If the two interfaces differ a lot (different data shapes, async vs sync), the adapter can get heavy.
• Pitfall: do not add new behaviour (retries, caching) inside an adapter. Its job is translation. Extra behaviour belongs in a Decorator or Proxy.

Quick revision: Singleton & Decorator ▶ 0:48:51 – 1:30:43

Before the new patterns the teacher re-explained Singleton (one object only) and Decorator (add behaviour on top of an object without changing it).

Singleton in 60 seconds

Why: some objects must exist exactly once (config, logger). Two of them cause inconsistent state, wasted resources, race conditions and hard debugging. Singleton is a creational pattern (it controls how objects are created): a class has only one instance and gives global access to it.

How (Java): make the constructor private so nobody outside can call new; expose a static getInstance() that creates the object only if it is still null.

import threading

class Logger:
    _instance = None
    _lock = threading.Lock()

    def __new__(cls):
        if cls._instance is None:              # 1st check: fast path, no lock
            with cls._lock:                    # only one thread enters here
                if cls._instance is None:      # 2nd check: still empty?
                    cls._instance = super().__new__(cls)
        return cls._instance

    def log(self, msg: str) -> None:
        print(f"LOG: {msg}")


# usage
a, b = Logger(), Logger()
print(a is b)   # True

Decorator in 60 seconds

Problem: you have ConsoleLogger and FileLogger. Product then asks for a timestamp, then JSON formatting, then a log level... Making ConsoleLoggerWithTimestamp, FileLoggerWithTimestampAndLevel and so on causes a class explosion, and editing the existing classes breaks Open/Closed.

Rules: (1) every decorator is a Logger, so the client still calls only log(); (2) every decorator has a Logger (the base it wraps); (3) it runs its own code first, then hands over to the base. Because a decorated logger is still a Logger, decorators can be nested in any order.

import json
from abc import ABC, abstractmethod

class Logger(ABC):
    @abstractmethod
    def log(self, msg: str) -> None: ...


class ConsoleLogger(Logger):
    def log(self, msg: str) -> None:
        print(msg)


class FileLogger(Logger):
    def __init__(self):
        self.lines: list[str] = []         # stand-in for a real file

    def log(self, msg: str) -> None:
        self.lines.append(msg)


class LoggerDecorator(Logger, ABC):
    """Every decorator IS a Logger and HAS a Logger (the base it wraps)."""
    def __init__(self, logger: Logger):
        self.logger = logger


class TimestampDecorator(LoggerDecorator):
    def log(self, msg: str) -> None:
        msg = f"[12:00:00] {msg}"          # decorator's own work first...
        self.logger.log(msg)               # ...then hand over to the base


class JsonParserDecorator(LoggerDecorator):
    def log(self, msg: str) -> None:
        self.logger.log(json.dumps({"message": msg}))


# usage: decorators can be stacked in any order
logger = TimestampDecorator(JsonParserDecorator(ConsoleLogger()))
logger.log("user signed in")
# {"message": "[12:00:00] user signed in"}

classDiagram
  class Logger {
    +log(msg)
  }
  class LoggerDecorator {
    -logger
    +log(msg)
  }
  ConsoleLogger ..|> Logger
  FileLogger ..|> Logger
  LoggerDecorator ..|> Logger
  LoggerDecorator o-- Logger : wraps
  TimestampDecorator --|> LoggerDecorator
  JsonParserDecorator --|> LoggerDecorator