The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.
Conversely, objects should have a single responsibility [1] and so functions that are unrelated should go on different objects. An InvoiceFetcher is definitely unrelated to a PaymentApplier, unless one takes the argument that "Its about money", in which case you have to argue for a single giant class.
I dunno, I always thought objects were about managing state. If an object does nothing except provide a method, why can't the method just be a free function instead?
Because Java. At least I can use an interface to define the function's specification, and then use that in mocks. On the one hand, it seems very different to what I learned about OOP twenty odd years ago, but on the other, it makes for extremely well designed and easy to understand code.
