I’ve spent a lot of time over several years arguing with architects. It got me a job once – the stated goal of the position during the interview was “I need someone to go argue with the architecture group whenever they want us to do something stupid”.

You have my sword

The general argument was always the same. Someone thinks that every three line for loop needed to become eleven classes with names like “FizzBuzzOutputGenerationContextVisitorFactory”.

It was always Java, because of course it was.

I’ve always struggled to articulate why this kind of thing offends me as much as it does though. I’ve usually resorted to describing it as “taste”, which is an analogy that I think mostly works, but is wholly unsatisfying as actually explaining anything.

Maybe a better way of grounding that idea is that I think code that isn’t about the domain I’m working on is at best a necessary evil. Programming is still programming. There are certain realities that you can’t ignore when the goal is to use real physical machines to do something. I’m going to need to deal with files and databases and network connections. But I don’t want to write that code, I just have to.

Design patterns, by definition, are independent of context or domain. A decorator pattern describes a way to add behavior to an object without changing the object. It doesn’t matter if the object is a Customer or a DatabaseConnection. That falls squarely in the bucket of “things I don’t want to write”. Maybe, like the filesystem, I still have to write it, because it provides so much utility that it pays for the complexity, but until I’ve gotten myself to the point of accepting that, my default starting position is that I don’t want it.

You could maybe make a similar argument about data structures. Why does an abstract factory bother me, but not a stack? I think it’s mostly that data structures contain actual domain data, and as such they generally have some sort of interpretable meaning. A std::vector might contain customers who require a service call today. “Customers who require a service call today” is a meaningful semantic object, in a way that AbstractCustomerFactory is not. I can name that variable and reason about it in ways that make sense in my domain.