Read on Twitter
You know, we all considered "data class" to be a code smell (if not an antipattern) for a long time.
Generally, I still see it as being a flaw, but the world has changed a bit.
XML docs are essentially data classes.
JSON docs too.
JSON docs too.
Someone in the Java camp decided it's easier to have dumb data classes for Hibernate & the like to work well, so people have gotten used to having dumb data classes and separate methods - just like old "structured BASIC" code.
And, of course, non-OO languages tend to separate code and data anyway and sometimes that is helpful and good.
It still looks like a code smell in the Java case and in cases not covered here (XML/HTML/JSON, db queries, etc). Most of the time having one class with three variables and no methods, and another with methods and no variables ... it's def not OO.
But you know, at the interfaces (again, JSON, etc) it is useful to have documents instead of full-blown objects, and I'm not sure all us OO people ever said anything about it.
But then smells are heuristics, and not certainties of malfeasance. Having a code smell can be different than having a design problem.
