The problem with Java's everything-must-be-a-class OO fundamentalism is that a computer is actually has data AND executable code. Java forces everything into a noun (class/data), but some things are actually verbs. You can these because they have awkward names, like Runnable.
Oh sure. Java should have had function pointers sooner. The functional interfaces are just ok. C#'s actions and delegates are a bit better, imo.
But the parent went so far as to say that scoping functions to a class name is bad and I just don't see it. I think a pure global scope would make Java worse.
You've never seen Java (or C#) code where a bunch of unrelated functions belong to some meaningless class like "Utility"?
I do think both languages would benefit from allowing/ encouraging namespace-level functions (C# comes close with static classes but that's pretty clearly an abuse of any logical definition of the word "class"). However I probably wouldn't use them for implementing "controllers" in web applications - while I tend to agree it's not a good use of OOP, having key information about the current request/response available via properties of the current controller (and hence kept separate from function-level parameters that represent semantics specific to the endpoint being handled) plus various built-in functionality at the framework-supplied "controller" level isn't something I'd see a benefit in giving up.
But I'll admit there are few cases where a single controller class with methods for various CRUD like operations on a particular resource type makes any sense from an OOP perspective. I did think for C# what might actually work is to be able to define extension methods on the framework Controller class and have an automatic routing mechanism based on convention (e.g. if you defined an extension function "Get_Widget" then GET requests to /widgets would be automatically routed to it. Or it could be based on the namespace). But in general it would likely make the code more verbose (lack of implicit "this") for questionable gain.
> You've never seen Java (or C#) code where a bunch of unrelated functions belong to some meaningless class like "Utility"?
Is that worse than the global scope as the dumping ground?
One other benefit of forcing classes is that there's a logical place for private functions and fields. Private state is an anti-pattern to some but it's more consistent design for Java, I think.
> Is that worse than the global scope as the dumping ground?
I wouldn't have a problem with requiring everything to at least be in a namespace, though it needn't be enforced at the language level (vs a linter rule).
I don't have any problem with it not being OOP, but I do have a problem with the abuse of the concept of a "class". I also think it's rarely the ideal way to organise your code (even if the .NET core framework has examples of it - WebUtility/HttpUtility etc., and the JRE may well do too, though I can't see any obvious examples in the java.util namespace).
The entire java.util namespace is the example here.
Using static methods on a class seems perfectly fine to me; that's what they're there for. If you have a handy utility class to work around problems in the standard library, then that's an issue with the standard library; Java has this but has gotten better over the years.
Might be heresy to come in to an OOP-bashing thread and say this, but the noun thing fits my mental model perfectly. IMHO, verbs aren't 'done' by nothing and data rarely exists without belonging to something, so it feels fine to me. I always find these discussions interesting though because clearly a lot of people feel differently (and very strongly in some cases).
(Please don't take this comment as an endorsement of OOP as practiced in the corporate world or that traumatic memory you have of an OOP codebase.)
Inform7 Actions and Rules system made me reconsider the centrality of the notion of Object when it comes to dispatching (note: Inform7 reads like english). Inform7 takes a verb-centric stance, then consider the subject (i.e. "this", in OOP), then the object (i.e. the arguments to a method). You can inject more specific behaviors in an action (i.e. something akin to a multimethod in CLOS), by adding an adjective to a verb/method complement/arguments. You can even use adjectives on the verb/sentence. All of this is gathered within a rulebook associated with the verb that exists aside of the actual source code: you can write code linearly, following the natural order of a given user story from the domain you model, using multiple verbs in succession, but can still display all a verb's rule, encompassing many user stories. Most importantly, it is truely extensible because you can't add code to an action's rulebook without doing so through a rule, which has the same role as a junction-point in aspect oriented programming or even subject-oriented-programming.
My obtuse point is that though sorting your source code files into various directories offers no functional benefit*, some folk find it useful from an organisational perspective. Maybe there's an element of that in housing functions an object.
*bear with me - admittedly there are languages/technologies where directory structures are required, but hopefully you get my point.
You didn't really address the question. Because a static method on a static class is a verb, even in the kingdom of nouns. It's just namespaced. So what's the issue? From a practical point of view.
Personally issue with it (besides the pointless noise of having to make a private constructor and such) is that you can't alias them like you can with actual namespaces/modules in most languages, which becomes a pain when eg. you need functions from both Apache's StringUtils and your own StringUtils in the same file.
Generally it goes with unnecessary boilerplate that gets copied around without any thought to whether it's necessary.
People who have been harmed by too much oop won't just define a function and call it. They'll define a class solely to contain that function and then call it more verbosely.
On the face of it it's not that bad but once you start tolerating a habit for doing things because that's how they're done and not because you actually think it's the right way you end up picking up all of these fragments from places where they do belong and forcing them into places where they don't.
Or at least, that's what I struggled with when I was new and insecure and wanted people to look at my code and think that I knew what I was doing because I showed evidence of knowing the dogmatic patterns, and I've seen it in others too.
Classes are basically namespaces, and trivial code doesn't need them, but quickly you do.
A lot of the criticisms being leveled here at oop actually me question their programming experience. There are many valid criticisms, but not a lot levelled here.
If all you're doing is using classes as superfluous namespacing, we'll that's hardly a threat. It's when they start having superfluous constructors that you're on a dark path. I once knew a guy who had a when-in-doubt-make-it-a-singleton habit, it was maddening to write tests anywhere near him.
Obviously that's an amateur move (and being an amateur myself I didn't have the confidence to show him a better way). But then it's never the skilled practitioners that make something look bad anyway.
