i would make a distinction that data and state are two different things and argue that a lot of the mess people create with OOP is due to confusing the two. dat

i would make a distinction that data and state are two different things and argue that a lot of the mess people create with OOP is due to confusing the two. data is what exists externally to your program while state is strictly internal to your program. inputs and outputs of your program are data and not state by definition. applying OOP principles to data is an unmitigated disaster and is the source of most of the problems associated with bad OOP design. data should be modelled as plain structs and arrays. data should be trivially convertable to and from json. there should be no object/relational impedance mismatch because objects are not data. data should not be bundled with code. there should be no hidden information in data. there should be no inheritance in data (use composition instead). on the other hand, many of these principles are quite useful for encapsulating state in order to provide higher level abstractions. it makes sense to hide the internal implementation details of containers, synchronization constructs, database client libraries, and other abstractions, and to allow for multiple implementations of those abstractions which can be swapped out for different purposes. introducing a new abstraction should not be taken lightly and the vast majority of programs should not be introducing their own abstractions. if the abstraction isn't something you would put in a library and make use of in several other programs, it probably shouldn't exist. in this sense, i think it is fair to say that the article author's stance is that "OOP isn't bad but you probably shouldn't be using it", and that this is a perfectly reasonable statement to make. a lot of die-hard OOP fans would argue that this is not "real OOP" but ironically their dogmatism and inability to deal with ambiguity has done more to fuel the anti-OOP movement than anything else.