3 ms·

One thing I hate though, in a language like Java, is when I see "utility" classes with static methods which take objects as parameters, then perform some calcul

One thing I hate though, in a language like Java, is when I see "utility" classes with static methods which take objects as parameters, then perform some calculation based entirely on the state of the passed in object. In my opinion, if the object can reason about its own state and return an answer based on that reasoning, that method/logic should be in the object, not elsewhere. Another one that bothers me are these transformation static methods which take type A and return type B based on nothing but the state of type A. The languages were talking about, C#/Java already provide a facility for this called a constructor. If the development approach is going to completely remove operational methods from data types then I'd think long and hard about using a language which supports this instead of a language, like Clojure, which does not.

TravHatesMe 7y ago
I think you made a good point: it is easy to shoot yourself in the foot with OOP. It is difficult to shoot yourself in the foot with FP. But when OOP is done correctly it offers useful features.
zozbot234 7y ago
> that method/logic should be in the object, not elsewhere Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later. > The languages were talking about, C#/Java already provide a facility for this called a constructor. There are sensible reasons to avoid using constructors for this, at least in the general case.
- lazulicurio 7y ago
  > Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later. I've been pondering this thread all day, and I think this is the crux of the issue. Ideally, classes would only encapsulate state and you'd use namespaces/modules to encapsulate functionality. But most Java/C# OOP examples use classes to encapsulate both state and functionality, which gets you stuck in the morass that the article discusses.
jayd16 7y ago
What you ask for is mostly impossible because you might not know about every possible object you'll be getting your construction params from....and besides that's horribly coupled. What about circular dependencies? C# helps you to some degree with extension methods so you get the same instance.Method() syntax.

TravHatesMe 7y ago

I think you made a good point: it is easy to shoot yourself in the foot with OOP. It is difficult to shoot yourself in the foot with FP. But when OOP is done correctly it offers useful features.

zozbot234 7y ago

> that method/logic should be in the object, not elsewhere Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later. > The languages were talking about, C#/Java already provide a facility for this called a constructor. There are sensible reasons to avoid using constructors for this, at least in the general case.

lazulicurio 7y ago
> Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later. I've been pondering this thread all day, and I think this is the crux of the issue. Ideally, classes would only encapsulate state and you'd use namespaces/modules to encapsulate functionality. But most Java/C# OOP examples use classes to encapsulate both state and functionality, which gets you stuck in the morass that the article discusses.

jayd16 7y ago

What you ask for is mostly impossible because you might not know about every possible object you'll be getting your construction params from....and besides that's horribly coupled. What about circular dependencies? C# helps you to some degree with extension methods so you get the same instance.Method() syntax.