Dart 3.1 and a retrospective on functional style programming in Dart
I&#x27;m all for ADTs but the reasons the article gives are all wrong, and in fact I think it makes the code a lot worse as a result.<p>Object programming doesn&#x27;t mean &quot;inheritance trees&quot;, that&#x27;s just the (IMHO overly simplified) flavor of object programming that we call &quot;OOP&quot;. (I&#x27;m omitting a full rant from here, which I ought to put on an article at some point.) Object programming is all about state and behavior, just like functional programming; it only differs in how it lays out the behavior namespace (object programming uses inheritance of behavior through lookup chains, which puts the object in focus; functional programming inverts that and uses the structure of the object to dispatch, putting the function in focus).<p>Grouping behavior together in a single function like the article suggests is, IMO, an anti-pattern and one that I consider to be one of the great disadvantages of a functional programming style. Bundling behavior together means the behavior is out of the control of the object; the object&#x27;s identity now becomes a critical part of the operation being performed. IMO, putting the focus on behavior is the wrong approach here.<p>Don&#x27;t get me wrong, I&#x27;m all for some features in functional programming; immutability is great for being able to make assumptions about program state and re-entrancy, for example. But I think the tendency to &quot;lock&quot; behavior into functions and not letting objects define their own behavior is a major shortcoming.