Free C# design-principles practice in the browser
Refactor working C# until the code is easier to change for a reason you can prove. Behavior tests protect the feature while 244 executable rules grade abstractions, immutability, interfaces, dependencies, and pattern structure across 28 focused exercises.
All exercises are available on every plan. No project setup or local SDK.
Beyond naming the acronym
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 122 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
The exercises are organized by the design decision they force, not by flashcard letters. That keeps Result models, honest capability contracts, Observer, Strategy, Decorator, value objects, and SOLID principles attached to the problems they actually solve.
Make state ownership, resource lifetimes, and expected outcomes explicit, close mutation leaks, keep snapshots opaque, and encode invariants in types instead of relying on callers to behave.
Split a class along its reasons to change, depend on abstractions owned by the policy side, remove the ones nothing varies behind, expose hidden dependencies, and keep vendor types outside application-facing contracts.
Keep subtype contracts honest, shrink roles to what each consumer actually needs, separate queries from commands, and replace long object-navigation chains with intention-revealing boundaries.
Use observers, policies, strategies, null objects, decorators, composites, state objects, undoable commands, and visitors where fixed collaborators, inheritance, switches, type tests, nullable branches, boolean flags, and tagged trees resist change.
28 free C# SOLID and design-pattern exercises
Start with one concrete dependency or train wreck, then move into explicit outcomes, honest subtype contracts, value objects, composition, Observer, Strategy, Null Object, and Decorator. Every card opens the actual kata.
9 focused refactors
Give history immutable checkpoints it can restore repeatedly without seeing the editor's internals.
Refactor this design →Turn a mutable Money-shaped DTO into a structurally immutable value object.
Refactor this design →Give order and customer identifiers their own always-valid value types so a swapped argument stops compiling.
Refactor this design →Give mutable state one explicit owner and remove a process-wide static coupling.
Refactor this design →Replace a hidden throw/catch protocol with one sealed, immutable enrollment outcome.
Refactor this design →Model each parcel stage as an immutable type that carries only its own data and legal moves.
Refactor this design →Freeze a two-phase Reservation and stop its guest collection escaping through the API.
Refactor this design →Acquire and deterministically dispose a lease in one scope, exception paths included, from any lease factory.
Refactor this design →Protect an Order invariant by sealing mutation paths and its backing collection.
Refactor this design →6 focused refactors
Replace a hidden concrete dependency with an explicit abstraction-owned constructor seam.
Refactor this design →Remove the abstractions nothing varies behind and keep the one that does, without changing a single report card.
Refactor this design →Build a vendor-neutral payment port instead of leaking Stripe types through an interface.
Refactor this design →Split a payment importer so statement parsing, storage, and summary wording each change in one place.
Refactor this design →Make every payment method a conventionally named drop-in over one real abstraction.
Refactor this design →Expose a quote calculator's hidden global dependency through constructor injection.
Refactor this design →4 focused refactors
Split shared membership identity from renewal so lifetime members inherit no lying method.
Refactor this design →Hand queue observers a read-only preview and keep consumption behind an explicit command.
Refactor this design →Split a fat machine contract so printers and consumers depend only on roles they use.
Refactor this design →Replace a multi-object navigation chain with one intention-revealing neighbor call.
Refactor this design →9 focused refactors
Replace a tagged-tree evaluator with recursive rule objects that keep child order and short-circuit behavior.
Refactor this design →Flatten a fee hierarchy into a sealed account composed with interchangeable policies.
Refactor this design →Broadcast build completion through an open observer collection and prove every subscriber runs.
Refactor this design →Replace repeated null checks with a substitutable NoDiscount supplied at composition.
Refactor this design →Move plan-specific pricing behind strategies chosen outside the calculator.
Refactor this design →Move lifecycle decisions into state objects and adopt every successor they return across a whole sequence.
Refactor this design →Turn stock adjustments into commands that undo what really happened behind a history that knows no stock.
Refactor this design →Replace type switches and their silent defaults with visitors, so a new invoice line kind fails to compile.
Refactor this design →Replace multiplying boolean branches with stackable decorators over one announcer role.
Refactor this design →The design-practice loop
01
Read working C# with one specific rigidity: a concrete dependency, fat interface, mutation leak, switch, flag, or global hiding the real seam.
02
Edit the multi-file project in the browser. Introduce the smallest abstraction, policy, wrapper, or invariant boundary that resolves the pressure.
03
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
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.
The strongest direct coverage is Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, and one exercise splits a class along its reasons to change for Single Responsibility. Related exercises train state ownership, explicit outcomes, 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.
The catalog includes Strategy, Decorator, Observer, Composite, State, Memento, Command with undo, Visitor, Null Object, Value Object, strongly typed identifiers, one type per lifecycle stage, explicit Result models, command-query separation, composition roots, constructor injection, anti-corruption ports, composition over inheritance, and removing speculative abstractions. Each pattern appears as a response to a concrete design problem rather than an isolated template to copy.
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.
No. The multi-file editor, compiler, behavior tests, and design-rule grader run from the browser in disposable server-side sandboxes.
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.
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 freeA short note when fresh kata land, plus the C# and performance tricks behind the grading. No spam, unsubscribe anytime.