I am currently in a planning phase of game development, just dabbling into the realm of creation. I need some tips for handling battling on a technical level. What is the best way to go about a battle.. Should I have a battle object that takes in objects of the player and enemy? Kind of an overseer that controls the flow in a way?

Without knowing what type of game you're making: typically players and enemies will have multiple combat options, not just one. It might be simpler to have separate objects (or even just functions) for each combat type, which take relevant data from the originator of the combat event, does some math, and then applies damage (and displacement and whatever else is needed) to the target.

I was planning on making a turn based RPG, looking at your reply this is what I'm thinking I could take a Combat instance that takes the function from the objects into a function? So just as an example say we label the combat function processTurn() where it takes in attack(), magic(), defend(), item(), run() from both the monster and player or would it be easier to bundle those all into say action()? I am probably overthinking this xD, if I'm even making sense.

Are you familiar with game states? That's a prerequisite you need to learn.

I agree with Servant here, you would benefit from having game states to separate the combat game state from the "running around" game state.
And assuming you have graphics (this isn't text based) and aren't going super basic - like Dragon Quest combat basic - you're also going to want your player characters and enemies to be finite state machines for sanity's sake. You wouldn't want an enemy to launch its own attack before it's recovered from being knocked back by a player's attack, would you? (assuming this doesn't lead to some weird bug, it just winds up looking wrong).

I was planning on making a turn based RPG, looking at your reply this is what I'm thinking I could take a Combat instance that takes the function from the objects into a function? So just as an example say we label the combat function processTurn() where it takes in attack(), magic(), defend(), item(), run() from both the monster and player or would it be easier to bundle those all into say action()? I am probably overthinking this xD, if I'm even making sense.

Presumably you'll have a list of spells here, not just one, right? So a single magic() function doesn't work like it does for attack/defend/run. You have lots of options - you can add a function for each spell, you can try to pack spells into a "universal format" of some sort as a struct or class and pass that into a magic() function, which uses that data to do the math. Or you can do magic(spell id) - which then calls the function for that spell by lookup. I definitely recommend you do that last one for items.
If you have limited options to begin with, it doesn't make any sense to multiplex them into a single function just to demultiplex again within that function. Let the input handler / enemy AI figure out which function to call for this turn, and then call it at the appropriate time.

how combat works should dictate the design and organization of the code.

example:

Caveman 3.0 has 5 types of attacks: PC hand, PC missile, NPC hand, NPC missile, and monster.

missile attacks create projectile game objects. PC and NPC projectile collisions are resolved separately.

PC hand , NPC hand and monster attacks are also resolved separately.

so input or the AI triggers an attack. and one of 5 different subroutines resolves the attack when it lands. there is a delay between beginning a melee attack and when the attack is resolved (typically about 1/3rd of a second). its where your impact point is at the time of resolution that matters. so there are 5 trigger attack routines, and 5 resolve attack routines. trigger routines are called by input or AI. resolving attacks is either part of projectile movement, which is part of update, or part of updating an entity, or perhaps a stand alone call in update to resolve all PC or NPC/monster attacks. can't recall off hand if Caveman resolves hand attacks as part of entity update or as a separate pass. its 125,000 lines of game specific code. hard to keep it all in my head at all times.

best thing to do is write down all the rules for combat, just like you were writing the rules for a table top game.

from there it should be pretty obvious what types of things you'll need. data to store this, and code to do that, and so on. make a list of the variables and subroutines you'll need.. don't worry about sorting them into classes or whatever until your done. once you have all your variables and subroutines listed, it should be pretty obvious which ones go in the same class / module / whatever.

and remember that variables and data structures which are only used as members of other classes don't need to be classes. IE "a list class will do, and you don't need a list entry class" kind of idea. and "entry" is just a member var of a "list", and methods that operate on an entry are list usually more properly "list" methods, not "entry" methods. in short: don't over-abstract stuff.

Thank you everyone, this will definitely help me understand where I need to go from here.

in short: don't over-abstract stuff.

I think this is one of my biggest problems.