When using an object-oriented design, I use objects to represent stateful entities in my code. I usually take advantage of the object system provided by the language (C# supports object-oriented programming through classes, for instance), and don't make any particular effort to manage objects (of course, if the language is not garbage-collected, I set up ownership policies for any references, but C# is garbage-collected).

Usually, you try to design a hierarchy of objects starting from the most general (a scene), to the most specific (a single joint in the animation skeleton of a single character inside the scene, for example). If you do it this way, it is much easier to add code in very specific modules.

This keeps you from having to worry too much about how different systems will interact, and get bogged down in details. If the animation system is independent from the graphics system, which is independent from the game system, etc., you can focus on a single aspect of the engine until you are 100% satisfied with it, then move on to the next thing. That way you don't have to repeatedly change focus during development, which costs time.

I would go with an Entity class which Extends a logic class and owns a graphics and a physics-mesh class as members. This is because usually:
1) The logic data or "state" of the entity will probably be different for every entity (structures like position, orientation, current animation).This means that we will want a different copy fpr every entity.
2) Graphics and Physics-mesh classes tend to have data that you do not want to duplicate, like meshes and animation heirerchies. Since many entities in the game usually share the same mesh duplicating mesh's for every entity (for example 100 soldiers) is a waste. So I would go with pointers to preloded meshes.