Improvement and refactor

[EpiCanard]

Quelques idées d'amélioration en vrac :

• EventType.JOIN_SERVER_GROUP n'est pas appelé de dehors des tests et a le même comportement que QueryType.HAS_PLAYED_BEFOREz
• Packet.params peut être typé en Map<ParamsKey, String> et des méthodes utilitaires peuvent être ajouté pour éviter à faire getParams partout
• A expérimenter de faire en sorte qu'une méthode getParam puis retourner un type différent en fonction du ParamsKey
• Pourquoi ne pas utiliser les params pour faire transiter les data ? comme ça on sait qu'est-ce qu'on a comme data.

[G-Lauz]

• Redondance de EvenType.JOIN_SERVER_GROUP et QueryType.HAS_PLAYED_BEFORE: Les méthodes onPlayerJoin et onQueryHasPlayedBefore de spigot.MessageManger sont identique. Pour enlever de l'ambiguité entre les event et les query QueryType.HAS_PLAYED_BEFORE pourrait être retiré et remplacé par EvenType.JOIN_SERVER_GROUP dans bungee.MessageManager. De cette manière on peut retirer la méthodes onQueryHasPlayedBefore. Une autre nomenclature devrait aussi être envisagé pour faciliter la compréhension.
• Refactor de Packet.params: l'appel: packet.getParams().get(ParamsKey.SERVER_GROUP.getValue()) est utilisé à plusieurs reprise et peut-être simplifié. La création d'une classe ParameterManager qui gèrerait un Map<ParamsKey, String> on pourrait alors utilisé la méthode comme suit: packet.getParam(ParamKey.SERVER_GROUP). Le même genre de modification est applicapable pour les méthodes set de la classe core.protocol.Packet.
• Data en temps que paramètres: À première vue je ne vois pas de problème à seulement utilisé les paramètre pour distribuer de l'information ça simplifierait la construction et l'extraction des paquets. Je crois que l'intention de conception initial était d'offrir la possibilité de modifier les données avec une fonction de cryptographie par exemple ou de donner l'options d'utiliser une trame/paquet plus complexe pour l'utilisateur par dessus la méthode déjà existente. L'implémentation présente est surement trop complexe pour le cas d'utilisation actuelle.

[EpiCanard]

• A l'initialisation du plugin, on désactive le plugin si la config settings.bungeecord ( PlayerJoinGroup.java ).
  • Afin de garder une cohérence avec le fait qu'on passe en mode local le plugin quand on n'arrive pas à se connecter à la socket
  • Faire de même et passer en mode local en affichant un warning
  • L'initialisation de MessagesManager et SocketConnectedListener peuvent ainsi être évité

[G-Lauz]

• A l'initialisation du plugin, on désactive le plugin si la config settings.bungeecord ( PlayerJoinGroup.java ).

  * Afin de garder une cohérence avec le fait qu'on passe en mode local le plugin quand on n'arrive pas à se connecter à la socket
  * Faire de même et passer en mode local en affichant un warning
  * L'initialisation  de MessagesManager et SocketConnectedListener peuvent ainsi être évité
  

Le commit 9791d64 applique ces changements. Ce dernier vient également ajouté un meilleur contrôle sur les boucles des différents fils d'exécution de manière à s'assurer qu'ils se termine tous lorsque nécessaire.