The definition of "refactoring" is not as standard as you would think. On the very strict end of things, refactoring is an internal job — something you would do to a function or class which is transparent to consumers of the function or class. Callers do not need to change.

On the other hand, you can step back and look at your application from a bigger picture; does the application still function the same afterwards from the end user's perspective? I've seen people take this perspective with "refactoring."

Be careful that you don't mean redesign here, instead. It's ok to redesign your application, but refactoring usually implies changes that have minimal impact on the rest of the system.

My question is how should I separate BattleSystem into smaller manageable classes?

This sounds like a redesign to me, not refactoring. That's perfectly ok, especially as you are learning. Writing working code, and then rewriting that code to a more optimal design is a laborious but fantastic learning exercise.

When approaching a refactoring job or redesign, have a clear goal in mind. In my experience, a clear goal should:

• Describe the problem with your current design, including the primary and any secondary pain points you can think of.
• Clearly articulate your optimal design.
• Provide you (as the person doing the refactoring) enough information to judge when you are done.

You'll find that decomposing a refactoring job into smaller tasks helps you keep that end goal in mind. You will quickly fall into an iterative rhythm, which is a good thing, but be careful; this rhythm can become an endless loop. The end of each small task is an opportunity to evaluate your progress, and if you have working code with a better structure, you can decide you are done; thus breaking that loop.

The definition of "refactoring" is not as standard as you would think. On the very strict end of things, refactoring is an internal job — something you would do to a function or class which is transparent to consumers; callers do not need to change.

On the other hand, you can step back and look at your application from a bigger picture; does the application still function the same afterwards from the end user's perspective? I've seen people take this perspective with "refactoring."

Be careful that you don't mean redesign here, instead. It's ok to redesign your application, but refactoring usually implies changes that have minimal impact on the rest of the system.

The distinction between refactor and redesign is semantic when its your own toy project, but becomes more meaningful in real systems that require extensive testing after changes are made. This distinction is even more apparent when you build code libraries for others to use. A refactoring job for a code library should not require dependent code to be rewritten or adjusted. For your specific case:

My question is how should I separate BattleSystem into smaller manageable classes?

This sounds like a redesign to me, not refactoring. That's perfectly ok, especially as you are learning. Writing working code, and then rewriting that code to a more optimal design is a laborious but fantastic learning exercise.

When approaching a refactoring job or redesign, have a clear goal in mind. In my experience, a clear goal should:

• Describe the problem with your current design, including the primary and any secondary pain points you can think of.
• Clearly articulate your optimal design.
• Provide you (as the person doing the refactoring) enough information to judge when you are done.

You'll find that decomposing a refactoring job into smaller tasks helps you keep that end goal in mind. You will quickly fall into an iterative rhythm, which is a good thing, but be careful; this rhythm can become an endless loop. The end of each small task is an opportunity to evaluate your progress, and if you have working code with a better structure, you can decide you are done; thus breaking that loop.

The definition of "refactoring" is not as standard as you would think. On the very strict end of things, refactoring is an internal job — something you would do to a function or class which is transparent to consumers of the function or class. Callers do not need to change.

On the other hand, you can step back and look at your application from a bigger picture; does the application still function the same afterwards from the end user's perspective? I've seen people take this perspective with "refactoring."

Be careful that you don't mean redesign here, instead. It's ok to redesign your application, but refactoring usually implies changes that have minimal impact on the rest of the system.

My question is how should I separate BattleSystem into smaller manageable classes?

This sounds like a redesign to me, not refactoring. That's perfectly ok, especially as you are learning. Writing working code, and then rewriting that code to a more optimal design is a laborious but fantastic learning exercise.

When approaching a refactoring job or redesign, have a clear goal in mind. In my experience, a clear goal should:

• Describe the problem with your current design, including the primary and any secondary pain points you can think of.
• Clearly articulate your optimal design.
• Provide you (as the person doing the refactoring) enough information to judge when you are done.

The act of rewriting or refactoring suboptimal code can be a never ending endeavor; deciding on a narrow focus helps mitigate this.

The definition of "refactoring" is not as standard as you would think. On the very strict end of things, refactoring is an internal job — something you would do to a function or class which is transparent to consumers of the function or class. Callers do not need to change.

On the other hand, you can step back and look at your application from a bigger picture; does the application still function the same afterwards from the end user's perspective? I've seen people take this perspective with "refactoring."

Be careful that you don't mean redesign here, instead. It's ok to redesign your application, but refactoring usually implies changes that have minimal impact on the rest of the system.

My question is how should I separate BattleSystem into smaller manageable classes?

This sounds like a redesign to me, not refactoring. That's perfectly ok, especially as you are learning. Writing working code, and then rewriting that code to a more optimal design is a laborious but fantastic learning exercise.

When approaching a refactoring job or redesign, have a clear goal in mind. In my experience, a clear goal should:

• Describe the problem with your current design, including the primary and any secondary pain points you can think of.
• Clearly articulate your optimal design.
• Provide you (as the person doing the refactoring) enough information to judge when you are done.

You'll find that decomposing a refactoring job into smaller tasks helps you keep that end goal in mind. You will quickly fall into an iterative rhythm, which is a good thing, but be careful; this rhythm can become an endless loop. The end of each small task is an opportunity to evaluate your progress, and if you have working code with a better structure, you can decide you are done; thus breaking that loop.