I plan to have an isometric world, which can be freely roam around. However, I desire the system to instantly apply the grid onto isometric world for battling system on any random encounter. Therefore, from what I expect, I should have a class of character that can generally switch between free-roaming and battle system. However, because I am still new to game programming, I do not know how should I approach this. If I make my character class such that I could abruptly derived it into either Free-roaming or Battle system, it may sound convenient, but I will have to implement this feature for all other class too (enemy, object, etc.). If I use Interface, then I won't have flexibility to add extra function to certain special class of object (maybe boss?). Or should I have a set of hierarchy of interface to tackle this problem? If so, it would be too complicated. Therefore, any suggestion?
Two "philosophical" points:
I say "philosophical", because you will need to ignore the above and learn it yourself through experience, so here's my suggestion:
Use a state machine to switch your game object's behaviours
Your game has two states: free-roam and grid-battle. So make those two into sub-states of the "playing the game" state. See http://create.msdn.com/en-US/education/catalog/sample/game_state_management for an XNA-oriented approach. In free-roam you use a camera that's attached to the player character, in grid-battle you render a hex-grid and lock the camera in a fixed position for an overview of the battlefield.
For your game objects, you can reference the State design pattern, which is a more generic variant of the previous link. It enables you to change an object's behaviour depending on its state. Whenever your game's sub-state switches (from free-roam to grid-battle or vice versa), you will need to switch the relevant game objects states as well.
A possible class hierarchy is this:
Expanding on this could have a MovingObject and a MovingObjectState, from which PlayerObject/EnemyObject and PlayerObjectState/EnemyObjectState inherit, maybe in that case EnemyObject gains a doAI() method, but the move() method from MovingObject (and MovingObjectState) is shared between PlayerObject and EnemyObject.