This article and the associated comments reminded me of 'Object-Oriented Programming and Essential State'[1] which was posted on here about half a year ago. I'm

This article and the associated comments reminded me of 'Object-Oriented Programming and Essential State'[1] which was posted on here about half a year ago. I'm just going to copy from a thread that I felt got to the crux of the matter with OOP. ---- 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. ---- > 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. ---- > 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. ---- [1] https://news.ycombinator.com/item?id=21238802 https://news.ycombinator.com/item?id=21238802