4.3 Implementace p´ arov´ an´ı kol
V t´eto ˇc´asti pop´ıˇsi implementaci p´arov´an´ı kol. Pop´ıˇsi pouze turnaj jednotlivc˚u, protoˇze pro turnaj druˇzstev, je implementace obdobn´a. Implementaci jsem provedl pˇresnˇe podle navrˇzen´e architektury aplikace. Poˇzadavek na p´arov´an´ı je zachycen instanc´ı tˇr´ıdy PlayerRoundView. Ta bez jak´ehokoli zpracov´an´ı pˇred´a tento poˇzadavek sv´emu prezenterovi. Jedn´a se o instanci tˇr´ıdy PlayerRoun-dPresenter. Ta poˇz´ad´a o p´arov´an´ı rozhran´ı PlayerRound, kter´e jiˇz patˇr´ı do business vrstvy. T´ım se poˇzadavek pˇresunul z prezentaˇcn´ı vrstvy do business vrstvy. Prezenter pak oˇcek´av´a vr´acen´ı seznamu s p´arov´an´ım. Je ovˇsem tak´e pˇripraven na vyhozen´ı v´yjimky ApplicationLogicException, kter´e by v tomto pˇr´ıpadˇe znamenalo neoˇcek´avanou intern´ı chybu aplikace. Pokud vˇsak prezen-ter ´uspˇeˇsnˇe obdrˇz´ı p´arov´an´ı, pˇriprav´ı z´ıskan´a data pro sv˚uj pohled a pˇrik´aˇze mu ho zobrazit. T´ım je role prezenteru ukonˇcena a pohled je nyn´ı zodpovˇedn´y za dan´e zobrazen´ı. Pot´e jiˇz uˇzivatel aplikace vid´ı proveden´e p´arov´an´ı v GUI.
Nyn´ı pop´ıˇsi co se odehr´av´a v business vrstvˇe. Jak jiˇz bylo zm´ınˇeno, prezentaˇcn´ı vrstva vol´a metodu deklarovanou v rozhran´ı PlayerRound. Pod t´ımto rozhran´ı se mohou nach´azet r˚uzn´e implementace. V souˇcasn´e dobˇe je pouze jedin´a implementace tohoto rozhran´ı, jelikoˇz plnˇe dostaˇcuje. V bu-doucnu se vˇsak m˚uˇze uvaˇzovat o zmˇenˇe t´eto implementace. Dan´e rozhran´ı je implementov´ano tˇr´ıdou StdPlayerRound. Jej´ı instance obdrˇz´ı poˇzadavek na p´arov´an´ı pomoc´ı vol´an´ı metody doPairing. Provede nezbytn´e kontroly tohoto poˇzadavku a poˇz´ad´a p´arovac´ı engine o proveden´ı p´arov´an´ı. Pokud p´arov´an´ı probˇehne bez probl´emu, zaktualizuje sv˚uj stav a poˇz´ad´a instanci tˇr´ıdy StdPla-yerTournament o uloˇzen´ı sv´eho stavu do perzistentn´ıho prostˇred´ı. Jelikoˇz je jej´ı souˇc´ast´ı, mus´ı instance tˇr´ıdy StdPlayerTournament tak´e aktualizovat sv˚uj stav. N´aslednˇe poˇz´ad´a rozhran´ı TournamentManager o perzistentn´ı uloˇzen´ı.
Rozhran´ı TournamentManager je implementov´ano tˇr´ıdou StdTournamentMa-nager a pˇredstavuje jedin´aˇcka. Je to z toho d˚uvodu, ˇze je potˇreba pouze jedin´a instance t´eto tˇr´ıdy. Tato tˇr´ıda poˇz´ad´a rozhran´ı EntityDao o perzistetn´ı uloˇzen´ı.
Toto rozhran´ı patˇr´ı do datov´e vrstvy. Implementace tohoto rozhran´ı StdEnti-tyDao pak pomoc´ı tˇr´ıdy EntityManager uloˇz´ı entitu PlayerTournamentEntity do datab´aze.
Nyn´ı se vr´at´ım k p´arovac´ım enginu. Ten obdrˇz´ı poˇzadavek na p´arov´an´ı a provede ho podle zvolen´eho turnajov´eho syst´emu. Algoritmus se liˇs´ı podle zvolen´eho turnajov´eho typu, syst´emu a enginu. Pop´ıˇsi nyn´ı algoritmus pro jednotliv´e syst´emy, kter´e aplikace podporuje. Opˇet zanedb´am turnajov´y typ a pop´ıˇsi jen turnaj jednotlivc˚u, jelikoˇz pro turnaj druˇzstev je to obdobn´e.
4.3.1 Holandsk´a varianta ˇsv´ycarsk´eho syst´emu
Tento syst´em je implementov´an extern´ım enginem JaVaFo. Vlastn´ı algorit-mus je tedy skryt. M´ym ´ukolem bylo pouze pˇripravit vstupy a zpracovat jeho v´ystupy. Tento engine podporuje v´ıce vstup˚u. Byl vybr´an TRF form´at.
4. Implementace
4.3.2 Baku akcelerace holandsk´e varianty ˇsv´ycarsk´eho syst´em Tento syst´em je opˇet implementov´an pomoc´ı enginu JaVaFo. Plat´ı vˇse, co bylo zm´ınˇeno v pˇredchoz´ı ˇc´asti. Rozd´ıl byl pouze v zavol´an´ı jin´eho k´odu v dan´e metodˇe. Pomoc´ı tohoto k´odu totiˇz rozliˇs´ı o jakou variantu syst´emu se jedn´a.
Pro klasickou holandskou variantu je definovan´ym k´odem 1000, zat´ımco pro jej´ı Baku akceleraci je definovan´ym k´odem 1001.
4.3.3 Jednokolov´y syst´em kaˇzd´y s kaˇzd´ym
Tento syst´em je implementov´an vlastn´ım enginem aplikace. Jako algoritmus byly zvoleny Bergerovy tabulky, kter´e byly pops´any v kapitole 1. Pokud je lich´y poˇcet hr´aˇc˚u, je pˇrid´an pro p´arovac´ı ´uˇcely hr´aˇc, kter´y pˇredstavuje bye. Na n´asleduj´ıc´ı uk´azce k´odu m˚uˇzeme vidˇet metodu gerRoundRobinMatches, zod-povˇednou za p´arov´an´ı. Tato metoda oˇcek´av´a seznam hr´aˇc˚u se sud´ym poˇctem, ˇcehoˇz se doc´ıl´ı jiˇz zm´ınˇen´ym postupem. D´ale pak oˇcek´av´a skuteˇcn´y poˇcet hr´aˇc˚u, ˇc´ıslo kola a parametr, kter´y je pro jednokolovou verzi kaˇzd´y s kaˇzd´ym vˇzdy false. V metodˇe se vol´a metoda roundRobinAddition, kter´a je zodpovˇedn´a za vypoˇcten´ı indexu hr´aˇce v dan´em seznamu hr´aˇc˚u.
Metoda pro generov´an´ı p´arov´an´ı v syst´emu kaˇzd´y s kaˇzd´ym /**
* Generates a pairing
* Berger tables method is used.
* @param players all players in the tournament, must be even
* @param playersCount actual players count
* @param roundNum number of the round
* @param secondHalfDoubleRoundRobin if pairing is for second half, for single round robin it is always false
* @return list of matches (ie. the pairing)
*/
private List<MatchEntity> getRoundRobinMatches(List<PlayerEntity>
players, int playersCount, int roundNum, boolean secondHalfDoubleRoundRobin) {
4.3. Implementace p´arov´an´ı kol players.size() - i - 1, roundNum));
}
MatchEntity match = new MatchEntity(whitePlayer, blackPlayer);
if (secondHalfDoubleRoundRobin && i != 0) { PlayerEntity temp = match.getWhite();
Tento syst´em je opˇet implementov´an vlastn´ım enginem aplikace. Algoritmus je v podstatˇe stejn´y jako pro jednokolovou verzi. Dokonce je vyuˇzita stejn´a metoda. Hlavn´ı rozd´ıl je pouze v tom, ˇze pˇri jej´ım vol´an´ı z´aleˇz´ı na tom, zda je turnaj v prvn´ı nebo druh´e polovinˇe. Pokud v prvn´ı, tak vol´an´ı je totoˇzn´e jako pro jednokolovou verzi a parametr secondHalfDoubleRoundRobin je false.
Naopak v druh´e polovinˇe turnaje je true. Co se t´yˇce samotn´eho algoritmu, tak se liˇs´ı pouze t´ım, ˇze pokud je turnaj v druh´e polovinˇe, tak se prohod´ı barvy hr´aˇc˚u kaˇzd´e partie. Neboli hr´aˇc, kter´y by mˇel v prvn´ı polovinˇe turnaje v dan´e partii b´ıl´e figury, bude m´ıt ˇcern´e a naopak.
4.3.5 Vyˇrazovac´ı syst´em
Tento syst´em je tak´e implementov´an vlastn´ım enginem aplikace. Pˇri jeho im-plementaci jsem neuvaˇzoval, kdo s k´ym m´a b´yt p´arov´an. Dan´e p´arov´an´ı je pseudon´ahodn´e. Na n´asleduj´ıc´ı uk´azce k´odu m˚uˇzeme vidˇet metodu doElimi-nationPairing, kter´a je zodpovˇedn´a za vlastn´ı p´arov´an´ı. Metoda je relativnˇe jednoduch´a. Vytvoˇr´ı mˇelkou kopii seznamu hr´aˇc˚u, kter´y obdrˇz´ı jako parametr.
Pot´e zkontroluje, zda nen´ı v dan´e kopii seznamu lich´y poˇcet hr´aˇc˚u. Pokud ano, pak do n´ı jednoduˇse pˇrid´a dalˇs´ı poloˇzku. Pˇresnˇeji ˇreˇceno hodnotu null.
Hodnota null totiˇz pˇredstavuje bye. D´ale pak v cyklu pseudon´ahodnˇe vyb´ır´a dva hr´aˇce a odstran´ı je z kopie seznamu a vytvoˇr´ı jejich z´apas. Tento z´apas jednoduˇse pˇrid´a do seznamu z´apas˚u. Po skonˇcen´ı cyklu jsou jiˇz vˇsichni hr´aˇci
4. Implementace
sp´arov´ani a metoda vrac´ı seznam z´apas˚u. Opˇet zde seznam z´apas˚u pˇredstavuje p´arov´an´ı dan´eho kola.
Metoda pro generov´an´ı p´arov´an´ı ve vyˇrazovac´ım syst´emu /**
* Generates a pairing
* @param tour player tournament
* @param playerList list of players to pairing
* @return list of matches (ie. the pairing)
*/
final int iterations = players.size() / 2;
for (int i = 0; i < iterations; i++) {
MatchEntity match = new MatchEntity(white, black);
matches.add(match);
}
return matches;
}