Class.forName("it.polimi.ingsw.model.. MIsuse

[ingconti]

Please discuss WHY using such approach instead a more structured approach with methods by name.

[carmine-alberto]

In order to improve extensibility: while issues may arise using Reflection on the Client because of its dependence on the Server, no such issues can be present in the Model, ideally developed by a single group of work.

This means that the Model structure is well-known and well-defined among developers and adding new Predicates and Phases is as easy as creating a new Phase/Predicate class, making it extend TurnPhase/Predicate and placing it in the correct folder.

No need to edit switches, enums, etc... just follow a simple convention (i.e. "know your packages").

[ingconti]

you have to recompile in any case. you approach, as discussed is far for best practices. we will eventually discuss this point during exam

[carmine-alberto]

Not actually: as explained here, I would only need to compile the new class. As long as the destination folder matches the Reflection pathname, we're free to add any number of compiled new classes.

Compiling a single class and adding it to the project jar may be highly time-saving, even more if the process is automated by using a script (compile class, unzip, add to %path%, zip).

Examining the approach alone (Java is a tool after all): if the Model's folders structure is set in stone (as in our case - it's a reasonable assumption for an extendable Model), adding functionalities without having to modify the existing code is generally way better than its counterpart (or, at least, a solid point to take into consideration when evaluating trade-offs).

We could easily hardcode the classes into an Enum and add a switch, but I don't see any valid reason to do so (handling a default case is equivalent to handling the exception thrown by the Reflection catch).