A plain function has a uniform interface too: just calling it.

So the idea is that eventually real work will be done, likely by adding more functions. The class provides a nice encapsulation for that future work.

True, but that doesn't help you with encapsulation or the other (potential) benefits of using classes like inheritance.

Local variables inside a function are very much encapsulated.

Unless you need to keep state between two distinct actions on the same object, but in that case a single run() entry point will not be sufficient anyway.

Inheritance can be replaced by just calling a common function.

There are many “what if” here, which will likely never happen and until they do it’s premature abstraction. Most likely some other abstraction is needed by the time script grows.

"Lots of times people think they might need something later. You don't. Or you can just do it later if it comes up."

https://youtu.be/o9pEzgHorH0?t=339

For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.

It's important to remember that YAGNI is a guideline not a rule. If someone spends 10-minutes thinking about the future instead of writing code immediately, and they realize a need that introduces some extra upfront effort but reduces longterm maintenance (fewer changes in the future because it already matches the desired structure), then YAGNI doesn't apply. For standard work, this is a pretty common situation to find yourself in: Recognizing that you've done X before and it led to a particular structure, so when doing X' start with the final structure instead of insisting on 100 extra refactors along the way.

Some great discussion and insights here thanks everyone.

My continued thoughts: since this is a framework for trying to reduce cognitive load, I'm now thinking a pragmatic approach would be to try it out a few times, either as a set of function steps or a set of class steps and see whether one approach falls out as a preferable pattern to default too.

Thinking about it, I can see why classes might be a reasonable default, if you don't need the state, it doesn't matter, if you do, you might be tempted to refactor the script which I think detracts from the goal of this framework.

If anyone is using this, in python, would be interesting to hear their experience.