> The basic idea of OO is that data and functions are bundled together, which is an idea that Armstrong seems to hold a grudge against (objection 1). But he gives no arguments as to why this is a bad idea.
Code reuse. Functions that are tied to a data type are less likely to be reused, and if you find that you want to reuse one it will, a lot of the time, require major refactoring (perhaps you have to move the function to a parent class, or create an entirely new class that represents the thing that is common between this data type's use and other data types' use of the function).
Whereas if your data and function are never coupled you actually wind up writing more generic functions that don't care about the type they are operating on.
Utility classes are code smell (paradigm smell, even). They exist where the OO model breaks down and you want to get-shit-done rather than spend an hour thinking about where you can stick function X so that it's useable by class Y and Z. Same goes for verb classes; you know, those does-the-thing classes that you create which are just objects wrapped around a single function called execute(), run(), create(), etc. etc.
Utility classes serve merely as organization purpose. It has nothing to do with OO. It's like putting related files in a directory, or putting related Python functions in a module.
I don't get how "stick function X so that it's useable by class Y and Z" is relevant for consideration. As the name suggested, utility classes are function libraries that can be used by all.
The problem is that what you "really" want when you're doing this is a plain old namespace. In some languages, objects necessarily come with a bunch of baggage and implications you don't want without some way to opt out.
Yeah it works fine most of the time, but it's a bit like the opposite of primitive obsession. You wouldn't use an Integer class for an index in a for loop.
In Java you have little choice but to dump it all in one place. Contrariwise, Python offers you more options; you can just make a module and put a bunch of top-level methods in there if you want. Go has some notion of "objects" but you can have methods or top-level functions in a given package. And so on.
No, the problem is not to use a namespace. The problem is I want to organize related functions as a group. Namespace is just one way to do it. There are other ways. Package, class, namespace, or module serve the same function in term of organizing functions.
What are the bunch of baggage and implication to use class as a way to organize functions?
I don't see the difference in usage you mentioned with Python module. Putting a bunch of "top-level" methods in a module is the same as putting a bunch of static methods in a class.
It is possible to do separate functions form data in OO languages.
It is less convenient than it is on other languages, where the wrapper class is not needed.
Separating functions from data is not the natural initial solution in an OO language, and is done as a refinement. It is not promoted as a default solution.
At some point the language is getting in the way and it better to go with something that supports what you are doing.
Code reuse. Functions that are tied to a data type are less likely to be reused, and if you find that you want to reuse one it will, a lot of the time, require major refactoring (perhaps you have to move the function to a parent class, or create an entirely new class that represents the thing that is common between this data type's use and other data types' use of the function).
Whereas if your data and function are never coupled you actually wind up writing more generic functions that don't care about the type they are operating on.