These sorts of questions are philosophic, so there often is no one answer. Personally, if I had to define OO programming well enough to see how far I can push it, I'd take a similar path as I took with semantic web data structures. They have objects and data, and choosing the right tool for this job is often quite nuanced.

The key property in the semantic web is the same one I think I see in OO programming. It's the idea that there are objects, and they have properties. Mind you in OO programming those properties are often "X has a function that does Y," but simplifying it to speaking about properties is effective enough.

I think a key attribute of OO programing is that objects always have the properties they need to have, rather than having a superset of properties. Vectors are a great example. Mathematical vectors in 3-space have several properties. They can be added. They have a magnitude. They can be scaled by a constant. Quite often we implement those vectors with "coordinate vectors," which are a tuple of real numbers with corresponding operations. Subtract two vectors? Implement it by subtracting the elements of each coordinate vector. Dot product? Multiply the value for each element in each vector and add the result.

The result of using coordinate vectors is that they can only work with coordinate vectors. This becomes really interesting when you start talking about transformations. There are some transformations which do not change the vector, but the components must change (such as changing bases). If you worked in coordinate vector land, you have no concept of the vector not changing. And, having taught a few people how these vectors work, I'll tell you it's really confusing.

But I think that's the guiding principle of object oriented programming. If your objects have their real properties, rather than supervening on some object with more properties, then your algorithm will work in more circumstances. You're less tied to the implementation.

Object Oriented programming seeks to approach this by leveraging one extremely powerful abstraction: the concept of a reference to an object. Everything you learn about OO is a way to take some procedural pattern and implement it using the language of references and properties/functions instead.

The edge of this paradigm would be the mathematical abstractions at the root of programming. Integers. Floating point numbers. Strings. These things don't need OO in the sense that they already are object oriented. Integers have just the set of properties that integers have. Strings have just the set of properties that strings have. Sure, you can make a new "Integer" class with a bunch of properties, but it really can't do more than rehash what an integer already is.

And, in the case of many of these primitive concepts, we find that it was worth people's time to embed this sort of logic into hardware. I think that's the pragmatic limit of OO programming. Once you get to these types that really are what they are, if the hardware has support for them then it makes very little sense to waste time building up a model ontop of more hardware things.

You can absolutely make an "Object Oriented Hash Table." The only problem is that the mathematical definition for a hash table is so close to what hardware is good at that the best you can do is make a slow hash table. You can retain the purity of OO, but lose out on pragmatism.

These sorts of questions are philosophic, so there often is no one answer. Personally, if I had to define OO programming well enough to see how far I can push it, I'd take a similar path as I took with semantic web data structures. They have objects and data, and choosing the right tool for this job is often quite nuanced.

The key property in the semantic web is the same one I think I see in OO programming. It's the idea that there are objects, and they have properties. Mind you in OO programming those properties are often "X has a function that does Y," but simplifying it to speaking about properties is effective enough.

I think a key attribute of OO programing is that objects always have the properties they need to have, rather than having a superset of properties. Vectors are a great example. Mathematical vectors in 3-space have several properties. They can be added. They have a magnitude. They can be scaled by a constant. Quite often we implement those vectors with "coordinate vectors," which are a tuple of real numbers with corresponding operations. Subtract two vectors? Implement it by subtracting the elements of each coordinate vector. Dot product? Multiply the value for each element in each vector and add the result.

The result of using coordinate vectors is that they can only work with coordinate vectors. This becomes really interesting when you start talking about transformations. There are some transformations which do not change the vector, but the components must change (such as changing bases). If you worked in coordinate vector land, you have no concept of the vector not changing. And, having taught a few people how these vectors work, I'll tell you it's really confusing.

But I think that's the guiding principle of object oriented programming. If your objects have their real properties, rather than supervening on some object with more properties, then your algorithm will work in more circumstances. You're less tied to the implementation. If you have a getter getPosition which returns the position as a coordinate vector, you have fallen short of the ideal of OO, because you have specified a coordinate vector in a frame when you could have returned a Vector object which has no frame (and instead just has the vector operations). It's not the fact that you had a getter, getPosition, that violated OO ideals, it's the fact that it returned a coordinate vector that specified implementation details not essential to the interface.

Object Oriented programming seeks to approach this by leveraging one extremely powerful abstraction: the concept of a reference to an object. Everything you learn about OO is a way to take some procedural pattern and implement it using the language of references and properties/functions instead.

The edge of this paradigm would be the mathematical abstractions at the root of programming. Integers. Floating point numbers. Strings. These things don't need OO in the sense that they already are object oriented. Integers have just the set of properties that integers have. Strings have just the set of properties that strings have. Sure, you can make a new "Integer" class with a bunch of properties, but it really can't do more than rehash what an integer already is.

And, in the case of many of these primitive concepts, we find that it was worth people's time to embed this sort of logic into hardware. I think that's the pragmatic limit of OO programming. Once you get to these types that really are what they are, if the hardware has support for them then it makes very little sense to waste time building up a model ontop of more hardware things.

You can absolutely make an "Object Oriented Hash Table." The only problem is that the mathematical definition for a hash table is so close to what hardware is good at that the best you can do is make a slow hash table. You can retain the purity of OO, but lose out on pragmatism.