W8_L5: Design Patterns — Structural#

0. Where structural patterns sit — 00:27#

The previous lecture covered creational patterns, which "provide object creation mechanisms — they help us create objects in an efficient manner."

This lecture covers structural patterns, which:

help us assemble objects and classes into larger structures, and help us keep these structures flexible and efficient.

Two structural patterns are taught here:

1. Facade — 01:12
2. Adapter — 09:03

1. Facade Design Pattern#

1.1 The problem — 01:22#

You have a task that requires you to:

• Create several objects + perform several steps — initialize many objects, execute methods in the correct order, pass the right parameters
• Use existing complicated library functions
• …and as a result, others reusing your code must know details about which objects to create and which library functions to call

That last point is the real cost: the complexity leaks out to the client, and using your code becomes difficult.

1.2 Concrete example — the seller portal — 02:26#

After a buyer places an order, the system must do four things:

1. Create order
2. Notify seller
3. Prepare packaging
4. Send out for delivery

1.3 The naive implementation ("before") — 03:03#

Four independent classes, each doing one job:

class Order {
    public void placeOrder(String product){
        System.out.println("Order placed for Product " + product);
    }
}

class Seller {
    public void sellerNotification(String sellerName){
        System.out.println("Notified Seller " + sellerName);
    }
}

class Package {
    public void packageOrder(String packagingType){
        System.out.println("Order packed with " + packagingType);
    }
}

class Delivery {
    public void deliver(String buyerName, String address) {
        System.out.println("Sent package to delivery to " + buyerName
                           + " with address " + address);
    }
}

And the client's main has to do all of this by hand, in the right order:

public class FacadeBefore {
    public static void main(String[] args) {
        Order o = new Order();
        o.placeOrder("Lenovo Laptop");

        Seller s = new Seller();
        s.sellerNotification("Seller 1");

        Package p = new Package();
        p.packageOrder("bubble wrap");

        Delivery d = new Delivery();
        d.deliver("abc", "xyz");
    }
}

Reflection question posed at 04:15: how can I make this better for the client? The client "should necessarily not need to know the exact steps which are required."

1.4 The pattern — 04:47#

Facade design pattern: provides a simple interface to a library, or a complex set of classes.

You create one class with one method that internally calls all the required functions across all the required classes. Clients call only that method.

doSomething() {
    Class1 c1 = new Class1();
    Class2 c2 = new Class2();
    Class3 c3 = new Class3();
    c1.doStuff(c2)
    c3.setX(c1.getX());
    return c3.getY();
}

Client1 and Client2 both call Façade.doSomething(). Neither knows that package1.Class1, package2.Class2, package3.Class3 exist.

1.5 The refactored code ("after") — 06:00#

The individual classes do not change. Order, Seller, Package, Delivery stay exactly as they were. You only add a facade class:

class DeliveryFacade {
    public void deliver(String product, String seller, String packagingType,
                        String buyerName, String address) {
        Order o = new Order();
        o.placeOrder(product);

        Seller s = new Seller();
        s.sellerNotification(seller);

        Package p = new Package();
        p.packageOrder(packagingType);

        Delivery d = new Delivery();
        d.deliver(buyerName, address);
    }
}

public class FacadeAfter {
    public static void main(String[] args) {
        DeliveryFacade d = new DeliveryFacade();
        d.deliver("Lenovo Laptop", "Seller 1", /* packaging, buyer, address */ ...);
    }
}

The client now creates one object and calls one function. It doesn't remember which objects to create, nor the exact order of calls.

Before vs After#

1.6 Pros and cons — 07:46#

The coupling cost, shown concretely — DeliveryFacade references Order, Seller, Package and Delivery. If any one of those classes or its methods changes, DeliveryFacade must change too:

2. Adapter Design Pattern#

2.1 The problem: incompatible interfaces — 09:13#

On the seller portal, some products have cost in dollars or euros, so conversion to rupees is needed.

• There is an existing ConversionCalculator class/library — you do not have control over it.
• The Product class cannot directly access it: its interface is incompatible.

┌─────────────────────────────┐              ┌──────────────────────────────────┐
│          Product            │              │      ConversionCalculator        │
├─────────────────────────────┤              ├──────────────────────────────────┤
│ - productId: String         │              │                                  │
│ - productName: String       │   ─── ✗ ───  │ + dollarsToRupee(money): double  │
│ - productType: String       │              │ + eurosToRupee(money): double    │
│ - productCost: double       │              │                                  │
├─────────────────────────────┤              └──────────────────────────────────┘
│ + addProduct(id,name,type,  │
│              cost)          │
│ + getProductCost(): double  │
└─────────────────────────────┘

2.2 The pattern — 10:24#

The client wants to call methodB() but can't reach it. So insert an Adapter that acts as a wrapper / link between client and adaptee:

The two methods might be incompatible with each other, but that issue of incompatibility is taken care of by the adapter. The adapter wraps one of the objects to hide the complexity of what is happening behind the scenes.

2.3 Implementation — 12:00#

The adaptee — an existing library class with the actual conversion rates:

class ConversionCalculator {
    public double dollarsToRupee(double money) {
        return (money * 75);
    }
    public double eurosToRupees(double money) {
        return (money * 80);
    }
}

The adapter — bridges Product and ConversionCalculator. It takes a Product p, creates a ConversionCalculator, and passes the product's cost into the right function:

class CostCalculatorAdapter {
    public double getProductCost(Product p) {
        ConversionCalculator calc = new ConversionCalculator();
        return calc.dollarsToRupee(p.getProductCost());
    }
}

The client — Product.addProduct() creates an adapter object and calls the adapter's function. Product needs to know nothing about ConversionCalculator:

public void addProduct(String productId, String name, String type, double cost){
    this.productId   = productId;
    this.productName = name;
    this.productType = type;
    this.productCost = cost;

    CostCalculatorAdapter adapter = new CostCalculatorAdapter();
    this.productCost = adapter.getProductCost(this);
}

2.4 Running it — 14:09#

public class Adapter {
    public static void main(String[] args) {
        //Product from US
        Product p = new Product();
        p.addProduct("1", "Product 1", "Book", 300.00);

        System.out.println("Product cost in Rupees== " + p.getProductCost());
    }
}

Product cost in Rupees== 22500.0

The cost was 300 (dollars); addProduct created the adapter, the adapter called dollarsToRupee, and 300 × 75 = 22500 rupees came back.

2.5 Pros and cons — 14:23#

3. Facade vs Adapter — the easy confusion#

Both wrap other classes and both hide complexity from a client. The difference is why:

4. Cheat sheet#

Structural patterns = composition of classes/objects into larger structures, kept flexible and efficient.

FACADE                                  ADAPTER

Client ──► Facade.doSomething()         Client ──► Adaptor.methodA()
              │                                        │
              ├─► Class1.m()                           └─► Adaptee.methodB()
              ├─► Class2.m()
              └─► Class3.m()            (incompatible interface bridged)
(many steps collapsed into one)

Principles referenced:

• Single Responsibility Principle — a class should do one job (adapter keeps conversion out of Product)
• Open/Closed Principle — open for extension; add new adapters without touching existing classes

5. File manifest#

w8-l5-design-patterns-structural/
├── NOTES.md            # this file
├── shots/              # 15 verified screenshots
├── transcript_ts.txt   # timestamped transcript
├── video.en.vtt        # raw subtitles
└── video.mkv           # source video (720p)

Commands used:

yt-dlp --skip-download --print "%(title)s | %(duration_string)s | %(uploader)s" URL

yt-dlp --skip-download --write-auto-subs --write-subs \
       --sub-lang en --sub-format vtt -o "video.%(ext)s" URL

python3 ~/.claude/skills/youtube-notes/scripts/vtt2txt.py video.en.vtt > transcript_ts.txt

yt-dlp -f "bestvideo[height<=720]+bestaudio/best[height<=720]" -o "video.%(ext)s" URL

~/.claude/skills/youtube-notes/scripts/grab_frames.sh video.mkv shots <<'EOF'
00:00:54|01_types_of_patterns
...
EOF