Every time you add a feature, you touch the same 4 classes.
That's not "extensibility", that's a smell.
Here's the scenario every .NET dev knows:
You have a clean document model.
TextElement, ImageElement, TableElement, CodeBlockElement.
Then the product asks for HTML export.
Then PDF export.
Then the word count.
Then accessibility checks.
Then SEO scoring.
So you start adding methods to every element class.
TextElement now knows about HTML, PDF, accessibility rules, and SEO.
A class that should only know how to be text.
This is exactly what the Visitor Pattern was designed to fix.
Instead of stuffing operations into your data classes:
→ Each operation becomes its own visitor class
→ Elements just "accept" a visitor and let it do the work
→ New behaviors = new files, not modified files
The result:
✅ HtmlExportVisitor only contains HTML logic
✅ AccessibilityVisitor only contains a11y rules
✅ Element classes stay focused on being elements
✅ Adding PdfExportVisitor doesn't touch a single existing class
Open/Closed Principle, but actually applied.
I wrote a full breakdown with real C# examples, document export, accessibility checks, and a shopping cart pricing calculator using visitors:
🔗
thecodeman.net/posts/visitor…
When was the last time you reached for the Visitor pattern in .NET?
__
1️⃣ If design patterns still feel abstract, start with Design Patterns Simplified, plain English, no academic fluff:
thecodeman.net/design-patter…
2️⃣ Already comfortable? Level up with Design Patterns That Deliver, 5 production-ready patterns in C# with real code you'll actually ship:
thecodeman.net/design-patter…