I'm not adverse to namespaces, but I don't think classes should serve that role. A class with a bunch of static methods just isn't a class. It confuses the purpose of the features.
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.
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.
Allowing global functions seems like you're just asking for namespace pollution. I'm not a fan of the idea.
I'm not adverse to namespaces, but I don't think classes should serve that role. A class with a bunch of static methods just isn't a class. It confuses the purpose of the features.
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
StringUtilsclass that provides methods for working withStrings and so on. If you want to see if you can perform a particular operation on aString, 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
Utilspattern really does fly in the face of OOP, doesn't it?Yes.
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.
Also, I wrote about globals being bad once. I got into a bit of detail. ;)