Tutorials Design Patterns in C#
When NOT to Use Design Patterns — Complete Guide
When NOT to Use Design Patterns — Complete Guide: free step-by-step lesson with examples, common mistakes, and interview tips — part of Design Patterns in C# on Toolliyo Academy.
On this page
Design Patterns in C# · Lesson 66 of 69
When NOT to Use Design Patterns
GoF Core ✓ → Enterprise ✓ → Cloud & Craft
Cloud & Craft · 3 — Microservices & interviews · ~10 min · Module 8: Interview & System Design
What is this?
Skip a pattern when a simpler language feature, library, or straightforward code solves the problem with less indirection.
Why should you care?
Over-patterned ShopNest code slows juniors and hides bugs.
See it live — copy this example
Paste into a C# console or class library project and run dotnet run.
Console.WriteLine("DON'T: AbstractFactory for one concrete notifier");
Console.WriteLine("DON'T: Event sourcing for a 3-field settings row");
Console.WriteLine("DO: plain DI + if/else until duplication hurts");What happened?
- Patterns have costs: files, indirection, onboarding.
- YAGNI applies.
- Prefer clarity for small scopes.
Practice next
- List three ShopNest places that are fine without patterns.
- Delete an unused factory.
- Prefer IEnumerable over custom Iterator.
- Rewrite a tiny Visitor as switch expressions.
- Keep a README of anti-goals.
Remember
Simplicity first. Patterns cost complexity. Use when pain is real.
ShopNest deletes ceremony
Team removes empty AbstractFactory.
Outcome: Fewer files; same behavior.
Interview prep for this lesson
Practice these questions aloud after reading—each links to a full structured answer.
Sign in to ask a question or upvote helpful answers.
No questions yet — be the first to ask!
