Design Problems that i found;
1- If we want to add new classes for our character in code we must change the whole player constructor block and this is way too much work for a basic change.
2- If we want to do maintenance on our game it could be a disaster cause of errors we get while correcting our other errors.
3- If we want to change any base player stats we must dig into player constructor and make changes from there it's editing the core code and we don't want it.
4- Any player from any class must contain all the stats even if it don't need it thats a huge fallback.
5- Anything needs its own function in the play() function is hardcoded in the play() so if we want to change any mechanic in game we need to find it in that spagetti code.
Design Problems that AI found (Google Gemini);
1- Open/Closed Principle Violation: The Player constructor is full of if-else chains. Adding a new character class requires modifying existing code instead of extending it. (Suggested Patterns: Factory Method or Abstract Factory).
2- Bloated State: Characters hold variables they will never use (e.g., an Archer having a shield or a Knight having leftArrow). This wastes memory and causes logical flaws. (Suggested Pattern: Decorator).
3- God Method: The play() method handles everything—calculating math, taking user inputs, and applying damage. (Suggested Patterns: Strategy or State).
AI vs. Me (Comparison):
Both the AI and I noticed the same fundamental issues. We both agreed that the play() function is too complex (I called it spaghetti code; the AI called it a "God Method") and that giving all stats to every class is a huge fallback (the AI called it "Bloated State"). The main difference is the terminology and the solutions: I focused on the practical pain points (like maintenance disasters and the difficulty of making changes), while the AI provided formal software engineering terms (like the Open/Closed Principle) and suggested specific Design Patterns (such as Factory, Decorator, and Strategy) to solve these exact problems.