OCP Violation

[stikrobinson]

The current implementation of the Pokemon and Move classes violates the Open/Closed Principle (OCP). The evolution logic for each Pokémon species (e.g., Bulbasaur, Ivysaur, etc.) is embedded within the classes themselves, requiring modification whenever new evolutions or moves are introduced. This makes the code harder to extend and maintain. We propose the following changes to make the code adhere to OCP.

Suggested Changes:

Move Creation Refactor: The createMoves() method is hardcoding the assignment of specific moves based on the Pokémon's level. If new moves are introduced, the method would need to be modified, which violates OCP. Solution: Use a strategy or factory pattern to encapsulate move creation. Define an abstract Move class and concrete classes (e.g., TackleMove, SolarBeamMove) that handle move attributes. The createMoves() method should then utilize these concrete classes, making it easy to add new moves without altering the Pokémon class.

[stikrobinson]

Refactor Pokémon Class: The Pokemon class currently has hardcoded logic for setting base stats and moves, which could grow cumbersome as more species are added. Solution: Refactor the Pokemon class to use polymorphism. Create specific subclasses for each Pokémon (e.g., Bulbasaur, Charmander), each implementing their own stats, types, and moves. This way, new species can be added by simply extending the Pokemon class and overriding necessary methods (e.g., setBaseStats() and initializeMoves()).

[stikrobinson]

Refactor Evolution Logic: The evolution logic for each Pokémon species is tightly coupled to the individual species class, requiring changes to the class whenever new evolution conditions or new species are added. Solution: Introduce an abstract class Pokemon and implement concrete strategies for each evolutionary chain. This allows the evolution logic to be encapsulated and easily extended for new species without modifying existing code.