A line of OOP vs. line of thought

The programming paradigm of OOP has become intrinsicly popular in the recent decades of software development, and the most popular PL’s of our days have OOP libraries containing thousands of lines of code, and us developers seem to have grown pretty acustomed to the idea. The part where it all goes wrong though, is when we start believing that this object oriented model has something in common with the human line of thought.

Although it might at first seem logical that we have some aspects like a car, a car can have different properties like a color and a type, thereafter it can be driven, painted, tolled, and so on. Once we instanciate a given car(imagine it or see it), it somehow magically aquires this or that property. I hope you get the idea, and it does seem a bit elegant at first, but partially absurd at the second.

Here are a few clear differences between OOP and thought:

 

1. OOP is strictly structured, like a tree, everything inherits from a root. Well, what determines by which property determines the placement of a class in this tree? This is like sorting books in a library. There are about an ∞ number of ways to sort the books, but we most likely sort it by the alphabet, since it is the most widespread way of sorting. However our brain can sort books by name, author, genre, number of pages, amount of imagery, complexity of the language, countless ways of sorting. Which one we choose depends on the context of the sorting.
2. The amount of properties and functions in a regular OOP class is static, although we can at any given time imagine what it would be like to throw a car, or eat steel. Objects don’t have static functions or properties, there are lists of functions and properties, which are somehow binded to an object, and allow us to imagine or see something unusual, which on a regular (OOP bases) wouldn’t be there.
3. Then there is the element of reusage of code, or rather, reusage of function, which pretty much derrives from point 2. So if there are 2 objects performing a relatively same function, chance is that it is the same function(perhaps slightly altered), and not rewritten again, which you usually would result to in tree-structured OOP. You might say that all you have to do is derrive on object from the other, but what if the functionality is in a sister node, rather than a parent? Like so:

I want the same function in child12 and child 1a1, one thing could be to put into the root, but thats absurd, since I don’t want it everywhere else. I could create a base class for the two classes, but then how do I implement both Child1 and Child1a functionality, and seperate it at the same time? Well as I see, there is no way to do this?? Unless the function lies outside the tree structure, so then, what is the point of the tree as whole?