Refactoring Overview

The goal of this refactoring is to make the PlayerFactory more modular by splitting its responsibilities into two separate classes: PlayerFactory and LoadPlayer. By separating the concerns of configuration loading, entity creation, and component initialization, the code becomes easier to maintain, extend, and test.

The original PlayerFactory class handled both the loading of configuration files and the actual creation of the player entity, including setting up its components and loading assets. After refactoring, we will:

• Keep the responsibility of managing player configuration and loading within PlayerFactory.
• Move the actual player entity creation and component setup into a new class called LoadPlayer.

This separation of concerns allows each class to handle a more specific role, improving modularity and making it easier to test each part independently.

Refactoring Explanation:

1. PlayerFactory:

   • Now focuses solely on loading player configurations from JSON files.
   • The createPlayer() method retrieves the correct PlayerConfig and passes it to the LoadPlayer class for entity creation.
   • The class also handles loading file paths for assets (textures and atlases) but no longer handles entity creation directly.

2. LoadPlayer:

   • Now responsible for creating the player entity and setting up its components (like animations, weapons, health, etc.).
   • This class has methods to handle complex tasks such as adding components, weapons, and animations to the entity.

Testing Plan:

Since the class has been split, the testing will also be modular. Instead of testing the PlayerFactory and LoadPlayer together, each can be tested independently.

1. Testing PlayerFactory:

• Test that configuration files are loaded properly using the correct file paths.
• Verify that the correct player configurations are passed to the LoadPlayer class.

2. Testing LoadPlayer:

• Test individual functionalities such as:
  • Loading and adding components to the player (health, physics, input components, etc.).
  • Creating and equipping weapons (melee and ranged).
  • Adding animations and verifying that the correct animations are applied.
  • Test setting up correct player stats (health, weapons, etc.).

This refactoring and testing plan aim to make the code more modular, easier to test, and maintainable as the project evolves.

UML Diagram

Sequence Diagram

LoadPlayer sequence diag

ram

PlayerFactory sequence diagram