Existe-t-il un moyen plus intelligent de le faire en plus d'une longue chaîne d'instructions if ou de changement?

J'implémente un bot IRC qui reçoit un message et je vérifie ce message pour déterminer les fonctions à appeler. Existe-t-il une manière plus intelligente de procéder? Il semble que cela deviendrait rapidement incontrôlable après que je me sois levé pour aimer 20 commandes.

Peut-être y a-t-il une meilleure façon d'abstraire cela?

 public void onMessage(String channel, String sender, String login, String hostname, String message){

        if (message.equalsIgnoreCase(".np")){
//            TODO: Use Last.fm API to find the now playing
        } else if (message.toLowerCase().startsWith(".register")) {
                cmd.registerLastNick(channel, sender, message);
        } else if (message.toLowerCase().startsWith("give us a countdown")) {
                cmd.countdown(channel, message);
        } else if (message.toLowerCase().startsWith("remember am routine")) {
                cmd.updateAmRoutine(channel, message, sender);
        }
    }

Utilisez une table de répartition . Il s'agit d'un tableau contenant des paires ("partie message", pointer-to-function). Le répartiteur ressemblera alors à ceci (en pseudo code):

for each (row in dispatchTable)
{
    if(message.toLowerCase().startsWith(row.messagePart))
    {
         row.theFunction(message);
         break;
    }
}

(le equalsIgnoreCasepeut être traité comme un cas spécial quelque part auparavant, ou si vous avez plusieurs de ces tests, avec une deuxième table de répartition).

Bien sûr, ce pointer-to-functionà quoi cela doit ressembler dépend de votre langage de programmation. Voici un exemple en C ou C ++. En Java ou en C #, vous utiliserez probablement des expressions lambda à cet effet, ou vous simulez des "pointeurs vers des fonctions" en utilisant le modèle de commande. Le livre en ligne gratuit " Higher Order Perl " contient un chapitre complet sur les tables de répartition utilisant Perl.

Je ferais probablement quelque chose comme ça:

public interface Command {
  boolean matches(String message);

  void execute(String channel, String sender, String login,
               String hostname, String message);
}

Ensuite, vous pouvez demander à chaque commande d'implémenter cette interface et de renvoyer true lorsqu'elle correspond au message.

List<Command> activeCommands = new ArrayList<>();
activeCommands.add(new LastFMCommand());
activeCommands.add(new RegisterLastNickCommand());
// etc.

for (Command command : activeCommands) {
    if (command.matches(message)) {
        command.execute(channel, sender, login, hostname, message);
        break; // handle the first matching command only
    }
}

Vous utilisez Java - alors rendez-le beau ;-)

Je le ferais probablement en utilisant des annotations:

1. Créer une annotation de méthode personnalisée

   @IRCCommand( String command, boolean perfectmatch = false )

2. Ajoutez l'annotation à toutes les méthodes pertinentes de la classe, par exemple

   @IRCCommand( command = ".np", perfectmatch = true )
   doNP( ... )

3. Dans votre constructeur, utilisez Reflections pour créer un HashMap de méthodes à partir de toutes les méthodes annotées de votre classe:

   ...
   for (Method m : getDeclaredMethods()) {
   if ( isAnnotationPresent... ) {
       commandList.put(m.getAnnotation(...), m);
       ...

4. Dans votre onMessageméthode, il suffit de faire une boucle pour commandListessayer de faire correspondre la chaîne sur chacun et d'appeler method.invoke()où elle se situe.

   for ( @IRCCommand a : commanMap.keyList() ) {
       if ( cmd.equalsIgnoreCase( a.command )
            || ( cmd.startsWith( a.command ) && !a.perfectMatch ) {
           commandMap.get( a ).invoke( this, cmd );

Que se passe-t-il si vous définissez une interface, disons IChatBehaviourlaquelle a une méthode appelée Executequi prend un messageet un cmdobjet:

public Interface IChatBehaviour
{
    public void execute(String message, CMD cmd);
}

Dans votre code, vous implémentez ensuite cette interface et définissez les comportements que vous souhaitez:

public class RegisterLastNick implements IChatBehaviour
{
    public void execute(String message, CMD cmd)
    {
        if (message.toLowerCase().startsWith(".register"))
        {
            cmd.registerLastNick(channel, sender, message);
        }
    }
}

Et ainsi de suite pour le reste.

Dans votre classe principale, vous avez alors une liste de comportements ( List<IChatBehaviour>) que votre bot IRC implémente. Vous pouvez ensuite remplacer vos ifdéclarations par quelque chose comme ceci:

for(IChatBehaviour behaviour : this.behaviours)
{
    behaviour.execute(message, cmd);
}

Ce qui précède devrait réduire la quantité de code dont vous disposez. L'approche ci-dessus vous permettrait également de fournir des comportements supplémentaires à votre classe de bot sans modifier la classe de bot elle-même (selon le Strategy Design Pattern).

Si vous souhaitez qu'un seul comportement se déclenche à la fois, vous pouvez modifier la signature de la executeméthode pour produire true(le comportement s'est déclenché) ou false(le comportement ne s'est pas déclenché) et remplacer la boucle ci-dessus par quelque chose comme ceci:

for(IChatBehaviour behaviour : this.behaviours)
{
    if(behaviour.execute(message, cmd))
    { 
         break;
    }
}

Ce qui précède serait plus fastidieux à mettre en œuvre et à initialiser car vous devez créer et passer toutes les classes supplémentaires, cependant, cela devrait rendre votre bot facilement extensible et modifiable car toutes vos classes de comportement seront encapsulées et, espérons-le, indépendantes les unes des autres.

"Intelligent" peut être (au moins) trois choses:

Des performances supérieures

La suggestion du tableau de répartition (et de ses équivalents) est bonne. Une telle table s'appelait "CADET" dans les années passées pour "Impossible d'ajouter; N'essaye même pas." Cependant, considérez un commentaire pour aider un mainteneur novice à savoir comment gérer ladite table.

Maintenabilité

"Make it beautiful" n'est pas un avertissement inutile.

et, souvent négligé ...

Élasticité

L'utilisation de toLowerCase présente des pièges dans la mesure où certains textes dans certaines langues doivent subir une restructuration douloureuse lors du passage entre magiscule et minuscule. Malheureusement, les mêmes pièges existent pour toUpperCase. Soyez juste conscient.

Vous pourriez avoir toutes les commandes implémenter la même interface. Un analyseur de messages pourrait alors vous renvoyer la commande appropriée que vous n'exécuterez que.

public interface Command {
    public void execute(String channel, String message, String sender) throws Exception;
}

public class MessageParser {
    public Command parseCommandFromMessage(String message) {
        // TODO Put your if/switch or something more clever here
        // e.g. return new CountdownCommand();
    }
}

public class Whatever {
    public void onMessage(String channel, String sender, String login, String hostname, String message) {
        Command c = new MessageParser().parseCommandFromMessage(message);
        c.execute(channel, message, sender);
    }
}

Il ressemble à juste plus de code. Oui, vous devez toujours analyser le message afin de savoir quelle commande exécuter, mais maintenant elle est à un point correctement défini. Il peut être réutilisé ailleurs. (Vous voudrez peut-être injecter le MessageParser mais c'est une autre question. En outre, le modèle Flyweight peut être une bonne idée pour les commandes, selon le nombre que vous prévoyez d'être créé.)

Ce que je ferais c'est ceci:

1. Regroupez les commandes que vous avez en groupes. (vous en avez au moins 20 en ce moment)
2. Au premier niveau, catégorisez par groupe, de sorte que vous ayez une commande liée au nom d'utilisateur, des commandes de morceau, des commandes de comptage, etc.
3. Ensuite, vous allez dans la méthode de chaque groupe, cette fois, vous obtiendrez la commande d'origine.

Cela rendra cela plus gérable. Plus d'avantages lorsque le nombre de «sinon si» augmente trop.

Bien sûr, avoir parfois ces «sinon» ne serait pas un gros problème. Je ne pense pas que 20 est si mauvais.