Could you elaborate? In Java, at least, a common pattern is to make "Utils" classes, which are usually singleton or non-instantiable classes that just contain methods for working within a particular domain. Like a StringUtils class that provides methods for working with Strings and so on. If you want to see if you can perform a particular operation on a String, you just look for that source code.
If what you're saying is that you shouldn't just have one class that contains all of your static methods, then I totally agree. Grouping by functionality is important.
First, let me agree that in Java, and C#, a class with static methods is the correct approach.
What I lament is that the language forces you to do this. They have packages/namespaces which should be used for this purpose. A class is meant to represent an instantiable type, if you have only statics in it it violates this definition. That is, I'm complaining the languages are creating confusion as to what a "class" is.
Ah I see. The Utils pattern really does fly in the face of OOP, doesn't it?
I understand that you see this as a problem, conceptually. In practice in Java, you could statically import the class and use the methods like functions. In that case, the class would ask more like a namespace than a „true“ OOP class.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.