Class hierarchy of game objects

The structure of game object classes is something I'm going to rewrite, maybe before source code release. The problem was that I believed the "common" knowledge that you should avoid inheritance and especially multiple inheritance in C++, and use components, not only as in component based approach but as datatypes inside the class. But if you are using classes and OOP, then what is the point of that? There is no point and not only that it has made the game object tree quite difficult to maintain.

But what about things like the dreaded diamond? It is a silly thing to dread, because any advanced programmer can't make that kind of simple mistake in inheritance. The real difficult thing is the class hierarchy itself, because you need to make independent branches that don't rely on some base class data if the class is not inherited from "main" branch.

How you split classes is part of the hierarchy problem. For example if you have fountains should they be a separate class that has water contain ability or should they be a part of some more generic container type class? The way objects behave is I think a good way to split, but even then some features are more generic than others. It's not easy to create a well behaving class hierarchy, but it's certainly not impossible or something you should avoid.

I think when people go for solutions like component based design it's a solution to problem that never existed. The way OOP works is just one way to do things, that's it. If you want to do something else, that's ok, but it's irresponsible to create assumptions about OOP that are not true.