Ever wake up in the middle of the night thinking, “I love reading about design patterns, but do we really need more ways to pass data around?” No? Well, if you’re still here, you probably enjoy borderline masochistic discussions about code architecture as much as I do. Today, we’ll look at two seemingly unrelated design patterns—the Visitor pattern and the Pipe-and-Filter pattern—and figure out how to blend them together into something that’s, dare I say, elegantly over-engineered (in the best way possible, of course).
The (Relatable) Problem: We Need More Modularity
In the wonderful world of software development, we often face two contradictory imperatives:
- “I want to easily add new operations to my data model.”
- “I want to easily add new data types, too.”
Unfortunately, standard Visitor usage typically excels at number one, but it can be a pain for number two (the pattern is notoriously allergic to new data types). Meanwhile, a Pipe-and-Filter architecture is great at pulling data in one end, processing it in stages, and spitting it out the other end—without turning your application into a giant ball of spaghetti. However, pipe stages usually just expect a single format or a uniform contract.
So, what if we need multiple transformations (Visitor) across multiple data objects, all neatly chained in a pipeline (Pipe-and-Filter)? Believe it or not, combining these patterns can offer us the best of both worlds: flexible operations on stable data structures, plus a tidy pipeline for sequential or parallel processing. It’s like peanut butter and chocolate—except, you know, for enterprise software.
The Clever (and Surprisingly Practical) Solution
Step 1: Define the Visitable Hierarchy (Kotlin)
We’ll start by modeling our data types (a.k.a. the “documents”) with an interface that ensures each concrete type can accept a Visitor. This is the essence of double dispatch:
interface Visitable {
fun accept(visitor: DocumentVisitor)
}
data class TextDocument(val text: String) : Visitable {
override fun accept(visitor: DocumentVisitor) {
visitor.visit(this)
}
}
data class PdfDocument(val content: ByteArray) : Visitable {
override fun accept(visitor: DocumentVisitor) {
visitor.visit(this)
}
}
data class ImageDocument(val pixels: ByteArray) : Visitable {
override fun accept(visitor: DocumentVisitor) {
visitor.visit(this)
}
}
Key takeaway: By forcing each document to implement accept, we enable a Visitor to handle each type without requiring a million “if-else” statements or a harrowing type-checking spree.
Step 2: The Visitor Interface
Here’s our DocumentVisitor with overloaded methods for each concrete document type:
interface DocumentVisitor {
fun visit(textDocument: TextDocument)
fun visit(pdfDocument: PdfDocument)
fun visit(imageDocument: ImageDocument)
}
Step 3: Making Each Pipe Stage a Visitor
We can create a pipeline of visitors where each stage is responsible for a single transformation, validation, or processing step. Here are three example visitors:
class ValidationVisitor : DocumentVisitor {
override fun visit(textDocument: TextDocument) {
println("Validating TextDocument with length: ${textDocument.text.length}")
// ... Validation logic ...
}
override fun visit(pdfDocument: PdfDocument) {
println("Validating PdfDocument with size: ${pdfDocument.content.size}")
// ... Validation logic ...
}
override fun visit(imageDocument: ImageDocument) {
println("Validating ImageDocument with pixel data size: ${imageDocument.pixels.size}")
// ... Validation logic ...
}
}
class MetadataExtractionVisitor : DocumentVisitor {
override fun visit(textDocument: TextDocument) {
println("Extracting metadata from TextDocument. Word count = ${textDocument.text.split("\\s+".toRegex()).size}")
// ... Metadata extraction logic ...
}
override fun visit(pdfDocument: PdfDocument) {
println("Extracting metadata from PdfDocument. Byte array size = ${pdfDocument.content.size}")
// ... Metadata extraction logic ...
}
override fun visit(imageDocument: ImageDocument) {
println("Extracting metadata from ImageDocument. Pixel data size = ${imageDocument.pixels.size}")
// ... Metadata extraction logic ...
}
}
class ArchivalVisitor : DocumentVisitor {
override fun visit(textDocument: TextDocument) {
println("Archiving TextDocument...")
// ... Archival logic ...
}
override fun visit(pdfDocument: PdfDocument) {
println("Archiving PdfDocument...")
// ... Archival logic ...
}
override fun visit(imageDocument: ImageDocument) {
println("Archiving ImageDocument...")
// ... Archival logic ...
}
}
Step 4: The Pipe-and-Filter Sequence (Kotlin)
Think of the DocumentPipeline as the “pipe” that runs each “filter” (visitor) on our list of documents:
class DocumentPipeline(private val filters: List<DocumentVisitor>) {
fun execute(documents: List<Visitable>) {
// For each stage in the pipeline, run every document through it
filters.forEach { visitor ->
documents.forEach { doc ->
doc.accept(visitor)
}
}
}
}
And here’s a snippet to show how you’d wire it all together:
fun main() {
val documents = listOf(
TextDocument("Hello World from Kotlin"),
PdfDocument(ByteArray(1024)),
ImageDocument(ByteArray(2048))
)
val pipeline = DocumentPipeline(
listOf(
ValidationVisitor(),
MetadataExtractionVisitor(),
ArchivalVisitor()
)
)
pipeline.execute(documents)
}
When this runs, each visitor stage processes each document in turn—validating, extracting metadata, and finally archiving.
(Bonus) A Quick Java Version
For your Java colleagues who peek over your shoulder and ask, “Hey, can we do that in Java?”—well, yes, you can. Here’s a super-condensed example:
interface Visitable {
void accept(DocumentVisitor visitor);
}
class TextDocument implements Visitable {
private String text;
TextDocument(String text) { this.text = text; }
public String getText() { return text; }
@Override
public void accept(DocumentVisitor visitor) {
visitor.visit(this);
}
}
interface DocumentVisitor {
void visit(TextDocument doc);
}
class ValidationVisitor implements DocumentVisitor {
@Override
public void visit(TextDocument doc) {
System.out.println("Validating TextDocument: " + doc.getText().length());
}
}
class DocumentPipeline {
private final List<DocumentVisitor> filters;
DocumentPipeline(List<DocumentVisitor> filters) {
this.filters = filters;
}
void execute(List<Visitable> documents) {
for (DocumentVisitor visitor : filters) {
for (Visitable doc : documents) {
doc.accept(visitor);
}
}
}
}
// usage:
public class Demo {
public static void main(String[] args) {
List<Visitable> docs = List.of(new TextDocument("Hello Java!"));
DocumentPipeline pipeline = new DocumentPipeline(
List.of(new ValidationVisitor())
);
pipeline.execute(docs);
}
}
Yes, it’s verbose. Yes, it’s Java. But it gets the point across.
Why This Mashup is Pretty Great?
- Modular Operations: Each pipeline stage is self-contained. If you need more data processing or analytics steps, just add another visitor. Nothing else has to change.
- Cleaner Code: Because the pipeline manages the orchestration, you won’t be sprinkling your document classes with random “doSomethingCool” methods. Keep that logic in the visitors.
- Extensibility: New operations? Add a visitor. Done.
- Performance & Parallelism: Pipe-and-Filter architectures are relatively simple to parallelize. In a real system, you could easily run each pipeline stage in its own thread, or even distribute them, depending on how big your ambitions (or boss’s demands) get.
Of course, as always, there are trade-offs. Adding a new document type means you’ll update every single visitor. Also, debugging can become interesting: “Wait, which visitor stage is messing with my data?” But hey, it’s still better than trying to track down a rogue instanceof in 47 different classes.
Software design patterns are like a box of chocolates: you never know what you’re gonna get—until you carefully read the Gang of Four and Alan Kay. By merging a vintage 1994 OOP pattern with a good old 1970s Unix pipeline approach, you’ll get a design that’s both time-tested and refreshingly modern in its ability to handle multiple transformations.
So go forth, dear developer, and confidently combine patterns in ways that might raise an eyebrow or two but ultimately deliver a simpler, more maintainable system. And remember: life is short; write code that makes future you grin (or at least not groan) when you look at it again in six months =)