Not sure where I sit on the issue, but I wanted to add this:
By putting the functions in the class definition, they become locked into that class. Other data structures could potentially make use of the function, but now they don't own it. I would say the alternative is a namespace, which you don't instantiate.
Armstrong's grief is the idea that the functionality for classes can then only come from direct lineage. As I understand it, though, the OO-heavy languages (Java, C#, probably others) lean much more heavily on interfaces now to mix in behavior, which gets away from that specific problem.
[EDIT] I forgot that interfaces don't give implementation, so the mixing is pretty limited.
Not sure what I think of the state issue, though. Too green on the functional stuff to say how else it should work. I would point out, though, that programs hide state from each other; couldn't objects just be the same thing on a smaller scale? (That is, an opaque interface with a few access points.) It really comes down to how well it's made in both cases.
Java doesn't have multiple inheritance, so if you want to avoid writing the same behavior twice you instead get to write several interfaces describing the ability to do the behaviors and write several functions in each class that implements such an interface (but does not contain the implementation) calling the functions defined in the interface on its pet InterfaceImpl.
This is probably a worthwhile tradeoff, but checking in hundreds of lines of code that do literally nothing is still a bad place to be.
This was running through my head as well, and means that your software design is bad. If you have such a useful function that you can translate it among classes, it should sit in some sort of static Util class. Think of it as the Swiss Army Knife you carry in your regular toolbox, a go-to tool, when you know you don't need anything specialized.
A lot of static methods on a Util object strikes me as a smell in the context of this discussion. In OO-land it's not a smell per se because often you have no alternative. But functionally your class is a glorified namespace.
Not necessarily. Of course defining classes is tricky, and there's no such thing as a rule of thumb, and that's more what I was trying to relay with my comment. And I agree with others who are saying that a piece of software where objects are crammed with tons of static classes is bad OOP.
By putting the functions in the class definition, they become locked into that class. Other data structures could potentially make use of the function, but now they don't own it. I would say the alternative is a namespace, which you don't instantiate.
Armstrong's grief is the idea that the functionality for classes can then only come from direct lineage. As I understand it, though, the OO-heavy languages (Java, C#, probably others) lean much more heavily on interfaces now to mix in behavior, which gets away from that specific problem.
[EDIT] I forgot that interfaces don't give implementation, so the mixing is pretty limited.
Not sure what I think of the state issue, though. Too green on the functional stuff to say how else it should work. I would point out, though, that programs hide state from each other; couldn't objects just be the same thing on a smaller scale? (That is, an opaque interface with a few access points.) It really comes down to how well it's made in both cases.