🧱 Builder Design Pattern — Zero to Hero (EDA Focus)

Creational Pattern • Cadence / Siemens / Synopsys style

---

📌 Clickable Index

1. Why Builder exists (intuition)
2. Why Factory is NOT enough
3. The Core Idea (one sentence)
4. Mental Model (lock this in brain)
5. Naive C++ approach (what goes wrong)
6. Builder Pattern – anatomy
7. Step-by-step minimal implementation
8. Real EDA / Xcelium-style example
9. Thread-safety & immutability (EDA reality)
10. Interview framing (how to explain)

---

1️⃣ Why Builder exists (intuition)

Builder exists because some objects are too complex to be created in one shot.

In EDA:

• Simulation kernels
• Waveform dump configs
• Scheduler policies
• Netlist elaboration options

👉 These objects have:

• many optional parameters
• constraints between parameters
• invalid combinations
• defaults that matter

You cannot safely say:

That’s how silent bugs are born.

---

2️⃣ Why Factory is NOT enough

Factory chooses what to create. Builder controls how it is built.

👉 In EDA, correctness greater than brevity → Builder wins.

---

3️⃣ The Core Idea (one sentence)

You:

1. Collect configuration
2. Validate rules
3. Freeze object
4. Use it safely forever

---

4️⃣ Mental Model (burn this in memory)

❌ Bad

“Create object now, fix fields later”

✅ Good (Builder)

“Accumulate intent → validate → build once → immutable”

Think:

• Configuration phase
• Finalization phase

EDA tools love determinism → Builder enforces it.

---

5️⃣ Naive C++ approach (what goes wrong)

Telescoping constructor hell

Problems:

• Call sites unreadable
• Parameter order bugs
• Impossible to enforce rules

Example bug:

---

6️⃣ Builder Pattern — anatomy

Three actors

1. Product – final object (immutable)
2. Builder – mutable configurator
3. build() – validates & creates product

---

7️⃣ Step-by-step minimal implementation

🧩 Step 1: Product (final, immutable)

🔒 No setters. Once created → cannot be invalidated.

---

🧩 Step 2: Builder (defaults + fluent API)

Notice:

• Fluent chaining
• Readable intent
• Order does not matter

---

🧩 Step 3: Validation + build()

🔥 This is where EDA correctness lives.

---

🧩 Step 4: Usage (clean call site)

Readable. Safe. Self-documenting.

---

8️⃣ Real Xcelium-style example (simulation kernel)

Imagine configuring event scheduler:

Constraints:

• Delta cycles optional
• Parallel execution optional
• Some flags incompatible

Builder

Usage inside kernel init

💡 This is exactly how real EDA kernels are protected from bad configs.

---

9️⃣ Thread-safety & immutability (EDA reality)

• Builder → not thread-safe
• Product → thread-safe by design

Pattern:

• Build during init (single-thread)
• Share immutable product across threads

EDA rule:

Configuration happens once. Execution happens forever.

---

🔟 Interview framing (Cadence / Siemens)

When asked:

“When would you use Builder over Factory?”

Answer:

When object construction is complex, has optional parameters, or requires validation before use. Builder improves readability, enforces invariants, and creates immutable objects—critical in EDA systems.

Bonus line (principal-level):

Builder localizes correctness rules at construction time instead of spreading them across runtime code paths.

---

✅ Brain Lock Summary

Builder = Safe configuration + deterministic construction

• Factory → choose type
• Builder → enforce correctness
• EDA → Builder everywhere

---