You can represent "network credentials permissions" or "car" naturally in non-OO too though. Non-OO-procedural programmers would probably create a struct repres

You can represent "network credentials permissions" or "car" naturally in non-OO too though. Non-OO-procedural programmers would probably create a struct representing the credentials and have a bunch of (hopefully namespaced) freestanding functions to operate on it, just like OO has a bunch of methods operating on the class. Functional programmers would similarly represent that as a data structure and a set of functions to operate on it. Furthermore, since the data structures used are usually the core language provided ones, you can use the full collection of the languages library of functions to operate on it to transform, filter or otherwise process the data. You can do that with OO too, of course, except that encapsulation means you typically do it in the class and if you want to do other transformations, you either need to amend the class, expose the internal data (directly or through getters/setters), or inherit from the class. In a functional or procedural language you can also provide encapsulation/data hiding if you wish. I don't think either approach is more natural than the other and they're both more or less equivalent, its just that different languages encourage different default approaches. Personally, after twenty years of programming, I find that I value immutable data over all in most cases (ie unless I'm writing performance-sensitive C++ code) and as long as I have that and a reasonable way of managing it, I don't really mind if I'm representing things as immutable objects or something else.