Encapsulation, immutability, and invariants
4 exercisesMake state ownership explicit, close mutation leaks, and encode invariants in types instead of relying on callers to behave.
Free C# design-principles practice in the browser
C# SOLID principles exercises that grade the design
Refactor working C# until the code is easier to change for a reason you can prove. Behavior tests protect the feature while 85 executable rules grade abstractions, immutability, interfaces, dependencies, and pattern structure across 14 focused exercises.
All exercises are available on every plan. No project setup or local SDK.
- design exercises
- 14
- executable rules
- 85
- available free
- 14/14
Beyond naming the acronym
Make the principle survive a workaround
Reading that high-level code should depend on abstractions is easy. The useful judgment is recognizing when an interface still leaks a vendor DTO, a class accepts the interface but constructs the concrete anyway, or a service locator merely moves behind a readonly field.
Each kata starts with working code and one plausible design failure. You refactor several files, keep 50 catalog behavior tests green, and satisfy authored rules that inspect the submitted type structure. A cosmetic rename cannot clear a dependency rule.
Start with the dependency inversion guide or the value-object guide, then turn the idea into a graded refactor.
Your refactor
IPricingStrategy.cs
PricingCalculator.cs
CompositionRoot.cs
Working code is supplied. You change the design without changing the behavior.
Behavior suite
The feature still calculates every price correctly
Executable design rules
depends on abstraction
PricingCalculator → IPricingStrategy
no concrete dependency
PricingCalculator ↛ PremiumPricing
sealed policy owner
PricingCalculator is sealed
Four object-design skill families
Practice the pressure that makes each principle useful
The exercises are organized by the design decision they force, not by flashcard letters. That keeps Strategy, Decorator, value objects, and SOLID principles attached to the problems they actually solve.
Dependency inversion and clean ports
4 exercisesDepend on abstractions owned by the policy side, expose hidden dependencies, and keep vendor types outside application-facing contracts.
Interface segregation and low coupling
2 exercisesShrink roles to what each consumer actually needs and replace long object-navigation chains with intention-revealing boundaries.
Composition and behavioral patterns
4 exercisesUse policies, strategies, null objects, and decorators where inheritance, switches, nullable branches, and boolean flags resist change.
14 free C# SOLID and design-pattern exercises
Refactor every design in the browser
Start with one concrete dependency or train wreck, then move into value objects, interface segregation, composition, Strategy, Null Object, and Decorator. Every card opens the actual kata.
4 focused refactors
Encapsulation, immutability, and invariants
- Medium 3 tests + 5 rules
Freeze the Money
Turn a mutable Money-shaped DTO into a structurally immutable value object.
Refactor this design → - Medium 3 tests + 3 rules
Kill the Global Counter
Give mutable state one explicit owner and remove a process-wide static coupling.
Refactor this design → - Hard 3 tests + 6 rules
Make It a Value Object
Freeze a two-phase Reservation and stop its guest collection escaping through the API.
Refactor this design → - Hard 3 tests + 4 rules
Seal the Aggregate
Protect an Order invariant by sealing mutation paths and its backing collection.
Refactor this design →
4 focused refactors
Dependency inversion and clean ports
- Easy 3 tests + 5 rules
Ask for the Interface
Replace a hidden concrete dependency with an explicit abstraction-owned constructor seam.
Refactor this design → - Hard 3 tests + 5 rules
The Leaky Payment Port
Build a vendor-neutral payment port instead of leaking Stripe types through an interface.
Refactor this design → - Hard 3 tests + 4 rules
Program to the Abstraction
Make every payment method a conventionally named drop-in over one real abstraction.
Refactor this design → - Medium 4 tests + 5 rules
Retire the Service Locator
Expose a quote calculator's hidden global dependency through constructor injection.
Refactor this design →
2 focused refactors
Interface segregation and low coupling
- Medium 3 tests + 8 rules
Shrink the Machine Interface
Split a fat machine contract so printers and consumers depend only on roles they use.
Refactor this design → - Easy 3 tests + 5 rules
Stop the Train Wreck
Replace a multi-object navigation chain with one intention-revealing neighbor call.
Refactor this design →
4 focused refactors
Composition and behavioral patterns
- Hard 6 tests + 11 rules
Compose the Fees
Flatten a fee hierarchy into a sealed account composed with interchangeable policies.
Refactor this design → - Medium 3 tests + 5 rules
Null Object: No Branching
Replace repeated null checks with a substitutable NoDiscount supplied at composition.
Refactor this design → - Hard 5 tests + 5 rules
Strategy Over the Switch
Move plan-specific pricing behind strategies chosen outside the calculator.
Refactor this design → - Hard 5 tests + 14 rules
Wrap It, Don't Flag It
Replace multiplying boolean branches with stackable decorators over one announcer role.
Refactor this design →
The design-practice loop
Preserve the feature, change the reason it is easy to extend
01
Find the design pressure
Read working C# with one specific rigidity: a concrete dependency, fat interface, mutation leak, switch, flag, or global hiding the real seam.
02
Refactor the shape
Edit the multi-file project in the browser. Introduce the smallest abstraction, policy, wrapper, or invariant boundary that resolves the pressure.
03
Prove behavior and design
Submit against behavior tests and executable structural rules. The feature must still work, and the dependency or type shape must genuinely change.
The structural verdict is separate from correctness. Read how Katabench grades design rules and why a compiling implementation can still be the wrong shape.
C# SOLID principles exercise FAQ
Before you move the first dependency
What are C# SOLID principles exercises?
They are small working C# systems with one design pressure already present. Instead of answering a quiz about an acronym, you refactor the code and receive separate verdicts for preserved behavior and structural design rules such as abstraction use, interface segregation, immutability, sealing, and dependency direction.
Do these exercises cover all five SOLID principles?
The strongest direct coverage is Open/Closed, Interface Segregation, and Dependency Inversion. Related exercises train responsibility and state ownership, substitutable strategies and null objects, composition over inheritance, encapsulation, and value objects. It is a focused practice catalog, not a five-chapter theory course that forces every kata under one letter.
Which C# design patterns can I practice?
The catalog includes Strategy, Decorator, Null Object, Value Object, composition roots, constructor injection, anti-corruption ports, and composition over inheritance. Each pattern appears as a response to a concrete design problem rather than an isolated template to copy.
Are all 14 design-principles exercises free?
Yes. The complete Design Principles track is currently available on all plans. Daily graded-submission limits still depend on your plan, but none of these exercises is locked behind a specialized-track entitlement.
Do I need Visual Studio or the .NET SDK installed?
No. The multi-file editor, compiler, behavior tests, and design-rule grader run from the browser in disposable server-side sandboxes.
How are design-principles exercises different from architecture exercises?
Design-principles exercises focus on the internal shape and collaborators of a few types: immutability, interfaces, roles, dependencies, and patterns. Architecture exercises operate at the larger namespace, layer, module, and dependency-graph level.
Looking for broader practice? Browse all C# coding challenges across algorithms, data access, refactoring, architecture, security, testing, and design.
Make one dependency prove the principle
Start with Ask for the Interface: working notification code, one hidden concrete dependency, and five structural rules that reject the cosmetic fixes.
Try dependency inversion free