I think you miss the point. The behavior and state of an object in OOP is the aggregation of the code and state of its classes (including ancestors), mixins (if

I think you miss the point. The behavior and state of an object in OOP is the aggregation of the code and state of its classes (including ancestors), mixins (if applicable), and members. Some of those things still apply in non-OOP style programming, but OOP certainly has a larger cognitive load for many nontrivial applications. Keeping code and state more decoupled actually reduces cognitive load in many cases. In some of those, there is less encapsulation, but at least IMO OOP overshoots for how much encapsulation is productive. Now, I am not religious about this and regularly approve OOP designs in reviews. But my general approach is to prefer modules and packages of functions for behavior, plain structures for state, and only dip into OOP style encapsulation when it seems the extra encapsulation and bundling is worth it. A class modeling a mutex or other resource would qualify there.