Sur PPCG, nous avons fréquemment des défis King of the Hill , qui opposent différents robots de code les uns aux autres. Nous n'aimons pas limiter ces défis à un seul langage, nous effectuons donc des communications multiplateformes sur des E / S standard.
Mon objectif est d'écrire un cadre que les rédacteurs de défis pourront utiliser pour faciliter la rédaction de ces défis. J'ai trouvé les conditions suivantes que j'aimerais remplir:
L'auteur du défi est capable de créer une classe où les méthodes représentent chacune des communications distinctes . Par exemple, sur notre défi Good vs Evil , l'écrivain ferait une
Player
classe qui a uneabstract boolean vote(List<List<Boolean>> history)
méthode dessus.Le contrôleur est en mesure de fournir des instances de la classe ci-dessus qui communiquent via des E / S standard lorsque les méthodes susmentionnées sont appelées . Cela dit, toutes les instances de la classe ci-dessus ne communiqueront pas nécessairement via les E / S standard. 3 des bots peuvent être des bots Java natifs (qui remplacent simplement la
Player
classe, où 2 autres sont dans une autre langue)Les méthodes n'auront pas toujours le même nombre d'arguments (elles n'auront pas toujours une valeur de retour)
J'aimerais que l'auteur du défi doive faire le moins de travail possible pour travailler avec mon framework.
Je ne suis pas contre l'utilisation de la réflexion pour résoudre ces problèmes. J'ai envisagé de demander à l'auteur du défi de faire quelque chose comme:
class PlayerComm extends Player {
private Communicator communicator;
public PlayerComm(Communicator communicator){
this.communicator = communicator;
}
@Override
boolean vote(List<List<Boolean>> history){
return (Boolean)communicator.sendMessage(history);
}
}
mais s'il existe plusieurs méthodes, cela peut devenir assez répétitif, et le casting constant n'est pas amusant. ( sendMessage
dans cet exemple, accepterait un nombre variable d' Object
arguments et renverrait un Object
)
Y a-t-il une meilleure manière de faire cela?
la source
PlayerComm extends Player
partie " ". Tous les entrants Java s'étendent-ilsPlayer
, et cettePlayerComm
classe est un adaptateur pour les entrants non Java?Réponses:
OK donc les choses ont dégénéré et je me suis retrouvé avec les dix classes suivantes ...
L'essentiel de cette méthode est que toute communication se fait en utilisant la
Message
classe, c'est-à-dire que le jeu n'appelle jamais directement les méthodes des joueurs, mais toujours en utilisant une classe communicative de votre framework. Il existe un communicateur basé sur la réflexion pour les classes Java natives, puis il doit y avoir un communicateur personnalisé pour tous les joueurs non Java.Message<Integer> message = new Message<>("say", Integer.class, "Hello");
initialiserait un message dans une méthode nomméesay
avec un paramètre"Hello"
renvoyant unInteger
. Celui-ci est ensuite transmis à un communicateur (généré à l'aide d'une usine basée sur le type de lecteur) qui exécute ensuite la commande.(PS D' autres mots - clés dans mon esprit que je ne peux pas tout à fait en rien affinez bien utile maintenant. Motif de commande , Motif visiteur , java.lang.reflect.ParameterizedType )
la source
Player
de l'écriture ne soitPlayerComm
obligée. Alors que les interfaces de communication communiquent automatiquement avec moi, je rencontrerais toujours le même problème d'avoir à écrire la mêmesendRequest()
fonction dans chaque méthode.