4 ms·
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 s
by pfraze 14y ago
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.
- anonymoushn 14y agoJava 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.
- pfraze 14y agoAh, that's right-- interfaces don't give implementation. So yeah, Armstrong's criticism stands.
- UnFleshedOne 14y agoIn C++ they do. In C++ anything goes. <insane laughter>
- dclowd9901 14y agoThis 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.
- weavejester 14y agoYou can, but the better your standard library, the less you need specialized functions. For instance, instead of something like: response.setHeader("X-Foo", "Bar"); In a functional language we'd change the data structure directly: (assoc-in response [:headers "X-Foo"] "Bar") If, for instance, 90% of your application can be factored out into static methods, OOP starts to look like the wrong paradigm.
- wonderzombie 14y agoA 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.
- weavejester 14y agoWhat do you mean? I don't believe anyone is suggesting that if you have many static methods or functions, they should all be put in one namespace.
- Ralith 14y agoI think that's exactly what dclowd9901 was suggesting, though he may not have fully considered it.
- dclowd9901 14y agoNot 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.