Na PPCG często mamy wyzwania King of the Hill , które rzucają przeciwko sobie różne boty kodu. Nie lubimy ograniczać tych wyzwań do jednego języka, dlatego prowadzimy komunikację między platformami w stosunku do standardowych operacji we / wy.
Moim celem jest napisanie frameworka, w którym autorzy wyzwań będą mogli ułatwić pisanie tych wyzwań. Wymyśliłem następujące wymagania, które chciałbym spełnić:
Autor wyzwania jest w stanie stworzyć klasę, w której metody reprezentują każdą z odrębnych komunikatów . Na przykład w naszym wyzwaniu Dobry kontra Zły pisarz stworzyłby
Player
klasę, która maabstract boolean vote(List<List<Boolean>> history)
metodę.Sterownik jest w stanie zapewnić instancje powyższej klasy, które komunikują się za pośrednictwem standardowych We / Wy, gdy wywoływane są wyżej wymienione metody . To powiedziawszy, nie wszystkie instancje powyższej klasy koniecznie będą komunikować się przez standardowe I / O. 3 boty mogą być natywnymi botami Java (które po prostu zastępują
Player
klasę, gdzie kolejne 2 są w innym języku)Metody nie zawsze będą miały taką samą liczbę argumentów (nie zawsze będą miały wartość zwracaną)
Chciałbym, aby twórca wyzwań musiał wykonać jak najmniej pracy, aby pracować z moim frameworkiem.
Nie jestem przeciwny używaniu refleksji do rozwiązania tych problemów. Zastanawiałem się, czy nie wymagać od autora zadania zrobienia czegoś takiego:
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);
}
}
ale jeśli istnieje kilka metod, może to być dość powtarzalne, a ciągłe rzucanie nie jest zabawne. ( sendMessage
w tym przykładzie zaakceptuje zmienną liczbę Object
argumentów i zwróci an Object
)
Czy jest na to lepszy sposób?
źródło
PlayerComm extends Player
”. Czy wszystkie komponenty Java są rozszerzonePlayer
, a taPlayerComm
klasa jest adapterem dla uczestników innych niż Java?Odpowiedzi:
OK, więc sprawy się eskalowały i skończyło się na następnych dziesięciu klasach
Najważniejsze w tej metodzie jest to, że cała komunikacja odbywa się przy użyciu
Message
klasy, tj. Gra nigdy nie wywołuje metod graczy bezpośrednio, ale zawsze używa klasy komunikatora z twojego frameworka. Istnieje komunikator oparty na odbiciu dla rodzimych klas Java, a następnie musi istnieć niestandardowy komunikator dla wszystkich odtwarzaczy innych niż Java.Message<Integer> message = new Message<>("say", Integer.class, "Hello");
zainicjuje komunikat do metody o nazwiesay
z parametrem"Hello"
zwracającymInteger
. Jest on następnie przekazywany do komunikatora (generowanego przy użyciu fabryki opartej na typie odtwarzacza), który następnie wykonuje polecenie.(PS Inne słowa kluczowe w moim umyśle, że nie mogę całkiem zawężają się coś użytecznego prawej teraz. Wzór poleceń , odwiedzający , java.lang.reflect.ParameterizedType )
źródło
Player
pisałaPlayerComm
w ogóle. Podczas gdy interfejsy komunikatora wykonują dla mnie automatyczne rzutowanie, nadal mam ten sam problem z koniecznością napisania tej samejsendRequest()
funkcji w każdej metodzie.