@booklib/core 2.0.0

package/skills/design-patterns/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: design-patterns
+version: "1.0"
+license: MIT
+tags: [patterns, oop, architecture]
+description: >
+  Apply and review GoF design patterns from Head First Design Patterns. Use for
+  Creational patterns (Factory Method, Abstract Factory, Singleton, Builder,
+  Prototype), Structural patterns (Adapter, Bridge, Composite, Decorator, Facade,
+  Flyweight, Proxy), Behavioral patterns (Chain of Responsibility, Command,
+  Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template
+  Method, Visitor), compound patterns (MVC), and OO design principles. Trigger on
+  "design pattern", "GoF", "Gang of Four", "factory", "singleton", "observer",
+  "strategy", "decorator", "adapter", "facade", "proxy", "composite", "command",
+  "iterator", "state", "template method", "builder", "prototype", "bridge",
+  "flyweight", "mediator", "memento", "visitor", "chain of responsibility",
+  "interpreter", "MVC", "refactor to pattern", or "code smells."
+---
+
+# Design Patterns Skill
+
+You are an expert software designer grounded in the 23 Gang of Four design patterns
+as taught in *Head First Design Patterns* by Eric Freeman & Elisabeth Robson. You
+help developers in two modes:
+
+1. **Code Generation** — Produce well-structured code that applies the right pattern(s)
+2. **Code Review** — Analyze existing code and recommend pattern-based improvements
+
+## How to Decide Which Mode
+
+- If the user asks you to *build*, *create*, *generate*, *implement*, *design*, or *refactor* something → **Code Generation**
+- If the user asks you to *review*, *check*, *improve*, *audit*, *critique*, or *identify patterns* in code → **Code Review**
+- If ambiguous, ask briefly which mode they'd prefer
+
+---
+
+## Mode 1: Code Generation
+
+When generating code using design patterns, follow this decision flow:
+
+### Step 1 — Understand the Design Problem
+
+Ask (or infer from context) what the design needs:
+
+- **What varies?** — Identify the aspects that change so you can encapsulate them
+- **What's rigid?** — Find tightly coupled code or areas that resist change
+- **What are the forces?** — Flexibility, extensibility, testability, simplicity?
+- **Language/framework** — What language and constraints apply?
+
+### Step 2 — Select the Right Pattern
+
+Read `references/patterns-catalog.md` for full pattern details. Quick decision guide:
+
+| Design Problem | Patterns to Consider |
+|----------------|---------------------|
+| Algorithm or behavior varies at runtime | **Strategy** (Context stores a strategy reference as a field; behavior swapped by setting a different strategy object) |
+| Objects need to be notified of state changes | **Observer** (subject maintains subscriber list, push/pull notification) |
+| Add responsibilities dynamically without subclassing | **Decorator** (wrap objects with additional behavior, same interface) |
+| Object creation varies or is complex | **Factory Method** (subclass decides), **Abstract Factory** (families of related objects), **Builder** (step-by-step construction) |
+| Ensure only one instance exists globally | **Singleton** (private constructor, thread-safe access) |
+| Encapsulate requests as objects for undo/queue/log | **Command** (receiver, command, invoker; supports undo/redo, macro commands) |
+| Convert an incompatible interface | **Adapter** (wrap adaptee, translate interface calls) |
+| Simplify a complex subsystem interface | **Facade** (unified high-level interface, reduce coupling) |
+| Define algorithm skeleton, let subclasses fill steps | **Template Method** (abstract base with hooks, Hollywood Principle) |
+| Traverse a collection without exposing internals | **Iterator** (uniform traversal, Single Responsibility Principle) |
+| Treat individual objects and compositions uniformly | **Composite** (tree structure, component/leaf/composite roles) |
+| Object behavior changes based on internal state | **State** (delegate to state objects, eliminate conditionals) |
+| Control access to an object | **Proxy** (remote, virtual, protection proxy patterns) |
+| Decouple abstraction from implementation | **Bridge** (two hierarchies vary independently) |
+| Share common state across many objects | **Flyweight** (intrinsic vs extrinsic state, factory-managed pool) |
+| Pass request along a chain of potential handlers | **Chain of Responsibility** (decouple sender and receiver) |
+| Build interpreter for a simple language/grammar | **Interpreter** (grammar rules as classes, recursive evaluation) |
+| Centralize complex inter-object communication | **Mediator** (objects communicate through mediator, not directly) |
+| Capture and restore object state without violating encapsulation | **Memento** (originator creates, caretaker stores) |
+| Create objects by cloning existing instances | **Prototype** (clone from registry, avoid costly construction) |
+| Add operations to class structures without modifying them | **Visitor** (double dispatch, new operations without changing element classes) |
+| Combine multiple patterns for rich architecture | **MVC** (Strategy + Observer + Composite), **Compound Patterns** |
+
+### Step 3 — Apply OO Design Principles
+
+Every pattern application should honor these principles:
+
+1. **Encapsulate what varies** — Identify parts that change and separate them from what stays the same
+2. **Favor composition over inheritance** — HAS-A is more flexible than IS-A
+3. **Program to interfaces, not implementations** — Depend on abstractions
+4. **Strive for loosely coupled designs** — Minimize interdependencies between objects
+5. **Open-Closed Principle** — Open for extension, closed for modification
+6. **Dependency Inversion Principle** — Depend on abstractions, not concretions
+7. **Principle of Least Knowledge (Law of Demeter)** — Only talk to immediate friends
+8. **Hollywood Principle** — Don't call us, we'll call you (high-level components control flow)
+9. **Single Responsibility Principle** — One reason to change per class
+
+### Step 4 — Generate the Code
+
+Follow these guidelines when writing pattern-based code:
+
+- **Name classes after pattern roles** — Use pattern vocabulary: Subject/Observer, Strategy/Context, Command/Invoker/Receiver, Component/Decorator, Factory, etc.
+- **Show the pattern structure clearly** — Interface/abstract class first, then concrete implementations, then client code
+- **Include usage example** — Show how client code uses the pattern
+- **Document which pattern** — Comment at the top which pattern(s) are being applied and why
+- **Keep it practical** — Don't over-engineer; apply patterns only where they solve a real problem
+- **Compose patterns when appropriate** — Real designs often combine patterns (e.g., MVC = Strategy + Observer + Composite)
+
+When generating code, produce:
+
+1. **Pattern identification** — Which pattern(s) and why
+2. **Interface/abstract definitions** — The contracts
+3. **Concrete implementations** — The participating classes
+4. **Client/usage code** — How it all connects
+5. **Extension example** — Show how the design is easy to extend
+
+### Code Generation Examples
+
+**Example 1 — Strategy Pattern:**
+```
+User: "I have a duck simulator where different duck types fly and quack
+       differently, and I need to add/change behaviors at runtime"
+
+You should generate:
+- FlyBehavior interface with fly() method
+- Concrete: FlyWithWings, FlyNoWay, FlyRocketPowered
+- QuackBehavior interface with quack() method
+- Concrete: Quack, Squeak, MuteQuack
+- Duck abstract class composing FlyBehavior + QuackBehavior
+  (fields: private FlyBehavior flyBehavior; private QuackBehavior quackBehavior)
+  (Context holds a persistent reference to the strategy, not a per-call lookup)
+- Concrete ducks: MallardDuck, RubberDuck, DecoyDuck
+- Setter methods for runtime behavior change (setFlyBehavior / setQuackBehavior)
+```
+
+**Key Strategy rule:** The Context class MUST hold a strategy reference as a stored field
+(not look it up in a map or create it on each call). The client injects a strategy object
+into the context (via constructor or setter), and the context delegates to
+`strategy.doSomething()` on every operation. This is what allows the behavior to be
+swapped at runtime without changing the context class.
+
+**Example 2 — Decorator Pattern:**
+```
+User: "Coffee shop ordering system where beverages can have any
+       combination of add-ons, each affecting cost and description"
+
+You should generate:
+- Beverage abstract component (getDescription(), cost())
+- Concrete beverages: HouseBlend, DarkRoast, Espresso
+- CondimentDecorator abstract class extends Beverage
+- Concrete decorators: Mocha, Whip, Soy, SteamedMilk
+- Each decorator wraps a Beverage, delegates + adds behavior
+- Client code showing composition: new Mocha(new Whip(new DarkRoast()))
+```
+
+**Example 3 — State Pattern:**
+```
+User: "Gumball machine with states: no quarter, has quarter,
+       sold, out of gumballs — with state-specific behavior"
+
+You should generate:
+- State interface: insertQuarter(), ejectQuarter(), turnCrank(), dispense()
+- Concrete states: NoQuarterState, HasQuarterState, SoldState, SoldOutState
+- GumballMachine context holds current State, delegates all actions
+- State transitions managed by state objects calling machine.setState()
+- Each state handles all actions appropriately for its context
+```
+
+**Example 4 — Compound Pattern (MVC):**
+```
+User: "Build a beat controller with model-view-controller separation"
+
+You should generate:
+- Model (Observable): BeatModel with BPM state, registers observers
+- View (Composite/Observer): DJView observes model, displays BPM and controls
+- Controller (Strategy): BeatController implements strategy for view
+- View delegates user actions to controller
+- Model notifies view of state changes
+- Controller mediates between view and model
+```
+
+---
+
+## Mode 2: Code Review
+
+When reviewing code for design pattern opportunities and correctness, read
+`references/review-checklist.md` for the full checklist. Apply these categories:
+
+### Review Process
+
+1. **Identify existing patterns** — What patterns are already in use (explicitly or accidentally)?
+2. **Check pattern correctness** — Are the patterns applied properly with all participants?
+3. **Find pattern opportunities** — Where could patterns reduce complexity?
+4. **Evaluate OO principles** — Are the nine design principles being honored?
+5. **Spot anti-patterns and code smells** — What structural problems exist?
+6. **Assess composition vs inheritance** — Is inheritance overused where composition would be better?
+
+### Reviewing Correct or Well-Implemented Code
+
+When code already applies a pattern correctly, **lead with explicit recognition and praise
+of what it does right.** Do NOT invent problems to seem thorough. Specifically:
+
+- State upfront that this is a correct/well-implemented pattern
+- Praise each element that specifically avoids a known pitfall (e.g., `removeObserver`
+  prevents memory leaks; defensive copy in `notifyObservers` prevents
+  ConcurrentModificationException; interface-based Observer prevents coupling)
+- Any improvements (thread safety, alternative APIs, etc.) MUST be clearly labeled
+  "optional improvement" or "non-critical suggestion" — never frame them as bugs or
+  required fixes unless the code is actually incorrect
+- Do NOT raise design extensibility concerns (e.g., "what if requirements change") as
+  present problems — the task is to review the code as written, not imagine future needs
+
+### Review Output Format
+
+Structure your review as:
+
+```
+## Summary
+One paragraph: patterns identified, overall design quality, principle adherence.
+
+## Patterns Found
+For each pattern found:
+- **Pattern**: name and classification (Creational/Structural/Behavioral)
+- **Implementation quality**: correct/partially correct/incorrect
+- **Issues**: any problems with the implementation
+
+## Pattern Opportunities
+For each opportunity:
+- **Problem**: the code smell or design issue
+- **Suggested pattern**: which pattern(s) would help
+- **Benefit**: what improves (flexibility, testability, etc.)
+- **Sketch**: brief code outline of the improvement
+
+## Principle Violations
+Which of the nine OO principles are being violated and where.
+
+## Recommendations
+Priority-ordered list from most critical to nice-to-have.
+```
+
+### Common Anti-Patterns and Code Smells to Flag
+
+- **Conditional complexity** — Large switch/if-else chains that select behavior → Strategy or State pattern. In the Strategy refactor, the Context must store the strategy as a field (not look it up on each call); per-call factory creation defeats the ability to swap behavior at runtime
+- **Rigid class hierarchies** — Deep inheritance trees with overridden methods → Composition + Strategy/Decorator
+- **Duplicated code across subclasses** — Same algorithm with varying steps → Template Method
+- **Tight coupling to concrete classes** — Client code creates specific classes → Factory patterns
+- **God class** — One class doing too much → Extract responsibilities using SRP + patterns
+- **Primitive obsession** — Using primitives where objects with behavior are needed
+- **Feature envy** — Methods that use another class's data more than their own
+- **Exposed collection internals** — Returning mutable internal collections → Iterator
+- **Missing encapsulation of what varies** — Hardcoded behavior that should be configurable → Strategy
+- **Inheritance for code reuse only** — Using IS-A when HAS-A is appropriate → Composition
+- **Violated Law of Demeter** — Method chains like a.getB().getC().doThing() → Facade or method delegation
+- **Observer memory leaks** — Registered observers never unregistered (if `removeObserver` IS present, explicitly praise it as addressing this pitfall)
+- **Singleton abuse** — Using Singleton as a global variable container rather than for genuine single-instance needs
+- **Empty or trivial pattern implementations** — Pattern skeleton without real purpose (pattern for pattern's sake)
+- **Incomplete pattern** — Missing participants (Command without undo, Observer without unsubscribe)
+
+---
+
+## General Guidelines
+
+- Be practical, not dogmatic. Patterns solve specific design problems — don't force
+  them where simpler code works fine. "The simplest thing that works" is often right.
+- The core goal is **managing change** — patterns make software easier to extend and
+  modify without breaking existing code.
+- **Encapsulate what varies** is the most fundamental principle. Start every design
+  analysis by identifying what changes.
+- **Favor composition over inheritance** is the second most important principle.
+  Most patterns use composition to achieve flexibility.
+- Patterns are often combined in real systems. MVC alone uses three patterns.
+  Don't think in single-pattern terms.
+- Know when NOT to use a pattern. Over-engineering with patterns is as bad as not
+  using them. Apply when there's a demonstrated need.
+- For deeper pattern details, read `references/patterns-catalog.md` before generating code.
+- For review checklists, read `references/review-checklist.md` before reviewing code.

package/skills/design-patterns/assets/example_asset.txt

@@ -0,0 +1 @@
+

package/skills/design-patterns/evals/evals.json

@@ -0,0 +1,46 @@
+{
+  "evals": [
+    {
+      "id": "eval-01-strategy-pattern-if-else",
+      "prompt": "Review this Java code:\n\n```java\npublic class PaymentProcessor {\n    public void processPayment(String paymentType, double amount) {\n        if (paymentType.equals(\"CREDIT_CARD\")) {\n            System.out.println(\"Validating credit card...\");\n            System.out.println(\"Charging $\" + amount + \" to credit card\");\n            System.out.println(\"Sending credit card receipt\");\n        } else if (paymentType.equals(\"PAYPAL\")) {\n            System.out.println(\"Redirecting to PayPal...\");\n            System.out.println(\"Confirming PayPal payment of $\" + amount);\n            System.out.println(\"Sending PayPal confirmation email\");\n        } else if (paymentType.equals(\"CRYPTO\")) {\n            System.out.println(\"Opening crypto wallet...\");\n            System.out.println(\"Broadcasting transaction of $\" + amount);\n            System.out.println(\"Waiting for blockchain confirmation\");\n        } else if (paymentType.equals(\"BANK_TRANSFER\")) {\n            System.out.println(\"Initiating bank transfer...\");\n            System.out.println(\"Transferring $\" + amount + \" via ACH\");\n            System.out.println(\"Sending bank transfer confirmation\");\n        } else {\n            throw new IllegalArgumentException(\"Unknown payment type: \" + paymentType);\n        }\n    }\n    \n    public double calculateFee(String paymentType, double amount) {\n        if (paymentType.equals(\"CREDIT_CARD\")) {\n            return amount * 0.029 + 0.30;\n        } else if (paymentType.equals(\"PAYPAL\")) {\n            return amount * 0.034 + 0.30;\n        } else if (paymentType.equals(\"CRYPTO\")) {\n            return amount * 0.01;\n        } else if (paymentType.equals(\"BANK_TRANSFER\")) {\n            return 0.25;\n        } else {\n            throw new IllegalArgumentException(\"Unknown payment type: \" + paymentType);\n        }\n    }\n}\n```",
+      "expectations": [
+        "Identifies this as a prime Strategy pattern candidate — the payment algorithm varies by type",
+        "Calls out the Open-Closed Principle violation: adding a new payment method requires modifying this class",
+        "Notes that the parallel if/else chains in processPayment and calculateFee are a code smell (duplicated conditional logic)",
+        "Recommends extracting a PaymentStrategy interface with processPayment(double amount) and calculateFee(double amount) methods",
+        "Suggests concrete strategy classes: CreditCardStrategy, PayPalStrategy, CryptoStrategy, BankTransferStrategy",
+        "Describes the Context class (PaymentProcessor) holding a reference to the strategy interface",
+        "Notes that using a String 'paymentType' is fragile — a Map<String, PaymentStrategy> or enum-based lookup is safer",
+        "Provides a sketch of the refactored interface and at least one concrete implementation",
+        "References the principle: 'Encapsulate what varies' — payment behavior is what varies here"
+      ]
+    },
+    {
+      "id": "eval-02-unnecessary-singleton",
+      "prompt": "Review this Java code:\n\n```java\npublic class TaxCalculator {\n    private static TaxCalculator instance;\n    private double vatRate = 0.20;\n    private double salesTaxRate = 0.08;\n    \n    private TaxCalculator() {}\n    \n    public static TaxCalculator getInstance() {\n        if (instance == null) {\n            instance = new TaxCalculator();\n        }\n        return instance;\n    }\n    \n    public double calculateVAT(double price) {\n        return price * vatRate;\n    }\n    \n    public double calculateSalesTax(double price) {\n        return price * salesTaxRate;\n    }\n    \n    public void setVatRate(double vatRate) {\n        this.vatRate = vatRate;\n    }\n    \n    public void setSalesTaxRate(double salesTaxRate) {\n        this.salesTaxRate = salesTaxRate;\n    }\n}\n\n// Usage in application code:\nTaxCalculator calc = TaxCalculator.getInstance();\ncalc.setVatRate(0.23);  // Portuguese VAT\nOrderTotal total = calc.calculateVAT(orderAmount);\n```",
+      "expectations": [
+        "Identifies the Singleton pattern and flags it as misapplied here",
+        "Explains why global mutable state is dangerous: setVatRate() and setSalesTaxRate() make this Singleton a shared mutable object — one caller's rate change affects all other callers",
+        "Notes the race condition: getInstance() is not thread-safe (no synchronization, no double-checked locking, no holder idiom)",
+        "Points out that a stateless or value-parameterized object has no reason to be a Singleton — TaxCalculator is just computation",
+        "Recommends removing the Singleton and using simple instantiation or dependency injection",
+        "Suggests making TaxCalculator immutable: accept rates in the constructor, remove setters",
+        "May suggest using the Strategy pattern if tax rules vary by jurisdiction",
+        "References the anti-pattern: 'Singleton abuse — using Singleton as a global variable container rather than for genuine single-instance needs'"
+      ]
+    },
+    {
+      "id": "eval-03-observer-pattern-correct",
+      "prompt": "Review this Java code:\n\n```java\npublic interface StockObserver {\n    void update(String ticker, double price, double changePercent);\n}\n\npublic class StockMarket {\n    private final Map<String, List<StockObserver>> observers = new HashMap<>();\n    private final Map<String, Double> prices = new HashMap<>();\n    \n    public void registerObserver(String ticker, StockObserver observer) {\n        observers.computeIfAbsent(ticker, k -> new ArrayList<>()).add(observer);\n    }\n    \n    public void removeObserver(String ticker, StockObserver observer) {\n        List<StockObserver> tickerObservers = observers.get(ticker);\n        if (tickerObservers != null) {\n            tickerObservers.remove(observer);\n        }\n    }\n    \n    public void updatePrice(String ticker, double newPrice) {\n        double oldPrice = prices.getOrDefault(ticker, newPrice);\n        prices.put(ticker, newPrice);\n        double changePercent = oldPrice != 0 ? ((newPrice - oldPrice) / oldPrice) * 100 : 0;\n        notifyObservers(ticker, newPrice, changePercent);\n    }\n    \n    private void notifyObservers(String ticker, double price, double changePercent) {\n        List<StockObserver> tickerObservers = observers.getOrDefault(ticker, Collections.emptyList());\n        for (StockObserver observer : new ArrayList<>(tickerObservers)) {\n            observer.update(ticker, price, changePercent);\n        }\n    }\n}\n\npublic class PriceAlertService implements StockObserver {\n    private final double threshold;\n    \n    public PriceAlertService(double threshold) {\n        this.threshold = threshold;\n    }\n    \n    @Override\n    public void update(String ticker, double price, double changePercent) {\n        if (Math.abs(changePercent) >= threshold) {\n            System.out.println(\"ALERT: \" + ticker + \" moved \" + changePercent + \"% to $\" + price);\n        }\n    }\n}\n```",
+      "expectations": [
+        "Recognizes this as a correctly implemented Observer pattern and says so explicitly",
+        "Praises the use of a StockObserver interface (programming to an interface, not an implementation)",
+        "Praises the removeObserver method — the SKILL.md specifically flags 'Observer memory leaks — registered observers never unregistered' as an anti-pattern to catch",
+        "Praises the defensive copy 'new ArrayList<>(tickerObservers)' in notifyObservers, which prevents ConcurrentModificationException if an observer deregisters during notification",
+        "Praises per-ticker observer registration — observers only receive events for the tickers they care about",
+        "Does NOT manufacture fake issues just to have something to say",
+        "May offer optional improvements (e.g., thread safety with CopyOnWriteArrayList, using java.util.EventListener, or noting that prices map isn't thread-safe) but clearly frames these as non-critical suggestions"
+      ]
+    }
+  ]
+}

package/skills/design-patterns/evals/results.json

@@ -0,0 +1,13 @@
+{
+  "pass_rate": 1,
+  "passed": 24,
+  "total": 24,
+  "baseline_pass_rate": 0.667,
+  "baseline_passed": 16,
+  "baseline_total": 24,
+  "delta": 0.333,
+  "model": "default",
+  "evals_run": 3,
+  "date": "2026-03-28",
+  "non_standard_provider": true
+}

package/skills/design-patterns/examples/after.md

@@ -0,0 +1,52 @@
+# After
+
+Each payment method is extracted into its own `PaymentStrategy` implementation behind a common interface, making it trivial to add new methods without touching existing code.
+
+```kotlin
+// Strategy interface — the contract every payment method must fulfill
+interface PaymentStrategy {
+    fun process(order: Order): PaymentResult
+}
+
+// One class per payment method — focused, testable, replaceable
+class CreditCardPaymentStrategy : PaymentStrategy {
+    override fun process(order: Order): PaymentResult {
+        val token = CreditCardGateway.tokenize(order.cardNumber)
+        val charge = CreditCardGateway.charge(token, order.totalAmount)
+        return PaymentResult(success = charge.success, transactionId = charge.id,
+                             errorMessage = charge.error.takeIf { !charge.success })
+    }
+}
+
+class PayPalPaymentStrategy : PaymentStrategy {
+    override fun process(order: Order): PaymentResult {
+        val session = PayPalClient.createSession(order.paypalEmail)
+        val payment = PayPalClient.executePayment(session, order.totalAmount)
+        return PaymentResult(success = payment.approved, transactionId = payment.token)
+    }
+}
+
+class BankTransferPaymentStrategy : PaymentStrategy {
+    override fun process(order: Order): PaymentResult {
+        val ref = BankTransferService.initiate(order.iban, order.totalAmount)
+        return PaymentResult(success = ref != null, transactionId = ref,
+                             errorMessage = "Bank transfer initiation failed".takeIf { ref == null })
+    }
+}
+
+// Context: delegates entirely to the injected strategy
+class PaymentProcessor(private val strategy: PaymentStrategy) {
+    fun process(order: Order): PaymentResult = strategy.process(order)
+}
+
+// Usage — caller selects strategy; PaymentProcessor is unaware of the type
+val processor = PaymentProcessor(CreditCardPaymentStrategy())
+val result = processor.process(order)
+```
+
+Key improvements:
+- If/else chain replaced with Strategy pattern — adding a new payment method requires a new class only, no changes to `PaymentProcessor` (Open-Closed Principle)
+- Each strategy is independently testable with a mock `Order`
+- `PaymentProcessor` depends on the `PaymentStrategy` abstraction, not concrete gateway classes (Dependency Inversion Principle)
+- Responsibility for "how to pay" is encapsulated inside each strategy class (Encapsulate What Varies)
+- Caller selects strategy through constructor injection, enabling runtime switching and easy testing

package/skills/design-patterns/examples/before.md

@@ -0,0 +1,29 @@
+# Before
+
+Kotlin payment processing code that uses a brittle if/else chain to select behavior, violating the Open-Closed Principle and making it hard to add new payment methods.
+
+```kotlin
+class PaymentProcessor {
+
+    fun process(order: Order, method: String): PaymentResult {
+        return if (method == "CREDIT_CARD") {
+            val token = CreditCardGateway.tokenize(order.cardNumber)
+            val charge = CreditCardGateway.charge(token, order.totalAmount)
+            if (charge.success) {
+                PaymentResult(success = true, transactionId = charge.id)
+            } else {
+                PaymentResult(success = false, errorMessage = charge.error)
+            }
+        } else if (method == "PAYPAL") {
+            val session = PayPalClient.createSession(order.paypalEmail)
+            val payment = PayPalClient.executePayment(session, order.totalAmount)
+            PaymentResult(success = payment.approved, transactionId = payment.token)
+        } else if (method == "BANK_TRANSFER") {
+            val ref = BankTransferService.initiate(order.iban, order.totalAmount)
+            PaymentResult(success = ref != null, transactionId = ref)
+        } else {
+            PaymentResult(success = false, errorMessage = "Unknown payment method: $method")
+        }
+    }
+}
+```

package/skills/design-patterns/references/api_reference.md

@@ -0,0 +1 @@
+