> It’s nothing. There’s no way to describe it without sounding like a blowhard. It’s not “a controller for some URL space”, because that’s what the class is. An

> It’s nothing. There’s no way to describe it without sounding like a blowhard. It’s not “a controller for some URL space”, because that’s what the class is. An instance of it is utterly meaningless! IMO, this is being almost willfully obtuse and pointlessly pedantic. For one thing, the instance, not the class, is the thing most clearly described as the controller in this case. It's true that there's no need to have instances for this static logic, but it's also true that some routing behaviors have their own dynamic data (like caches or database connections, etc.) So a point of just always using instances is that you don't need to know or care externally or ahead of time whether or not such data exists (and to provide something better than singletons or worse things to manage it when it does.) I'm not a big fan of this form, BTW, though it's not on OO grounds. It's a code and logic organization thing. When I've seen this in real life it turns into spaghetti code of little objects connected in a tangle. I think it goes down like this: people start by encapsulating little steps of processing, I guess because they image they are independent. At this point it's OK -- a sequence of objects connected in a chain of references matching the processing steps. Then they realize they aren't independent, but instead of unwinding the chain, they add more objects -- to hold bits of common context -- and connect them here and there. The spaghetti is starting to tangle. (Mistakes are always made at this point -- e.g. there's ends up no coherent way to update this common data as things change.) The thing grows 10x and these kinds of things are repeated ten times and you have a big ball of spaghetti. Oh, and someone introduced a DI framework to solve these, which helps a little, but also introduces its own complications.