Your class will end up being much bigger than that. The class would end up being a World Class in that case.
You have the world, and then you have things in the world. Those things can be sectioned off into different classes. You have the class of Humans and the class of Fish, and the class of trees. Each class is, in its own respect, is very detailed. You have so many different kinds of trees, with various unique properties.
I think this is bad advice.
I don't really enjoy extreme programming, but it has one principle I stick to: "You aren't gonna need it." http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
Basically, don't add features for the future. Add features and refactor for the present. This rock/tree thing is a great example. If I made a game, at the beginning, there's probably not really any difference between a rock and a tree. They're both just parts of the scenery - two immobile objects with different 3D representations but the same code. So why should I make a Rock class and a Tree class right at the beginning? Maybe I'll be able to mine rocks and chop down trees, but that could also just start out as different values in a couple of variables - which tool type works, what material comes out, etc. - exactly like the OP describes. We could argue about data types and minor details but the general idea is there. Why make two classes? It doesn't gain me anything for the present.
If it gets to the point where there are differences between rocks and trees, they can be refactored into two separate classes. There's not much point in doing it earlier.
Perhaps you want trees in your next game, but not rocks?
Maybe I want traffic cones and mailboxes in my next game, and the generic InteractiveObject would work for those just fine by itself.
