And... Action!

Krok 1: Similarity (not) entirely coincidental

Kadet! Nepochybuj o tom, že pôvod kladiva Mjolnir je jednoznačne extraterestriálny, a hoci oplýva nadľudskou mocou, chtiac-nechtiac má nejaké spoločné črty s hasiacim prístrojom: dá sa použiť a časom sa zničí. Túto podobnosť môžeš v implementácii premietnuť do využitia dedičnosti, čo ti aj pomôže zredukovať opakujúci sa kód.

Zovšeobecnená implementácia nástroja, ktorý sa môže opotrebovať, zahŕňa sledovanie počtu ostávajúcich použití (stav) a aktualizovanie tohto počtu pri samotnom použití nástroja (správanie). Preto v triede BreakableTool vytvorte:

• Členskú premennú remainingUses pre počet zostávajúcich použití nástroja, ktorú je potrebné sprístupniť zvonku triedy len na čítanie a inicializovať použitím parametrického konštruktora.
• Metódu use() na odrátavanie použití nástroja a na jeho odstránenie zo scény, keď počet ostávajúcich použití klesne na 0 (nástroj sa opotreboval a zlomil).

Upravte konštruktory týchto tried. Teraz, keď rodičovská trieda obsahuje len parametrický konštruktor, musíte ho vhodne zavolať pomocou kľúčového slova super.

Nezabudnite na zámer, kvôli ktorému sme vytvorili zovšeobecnenie v podobe rodičovskej triedy BreakableTool a upravte implementácie tried Hammer a FireExtinguisher tak, aby čo najviac využívali zdedenú funkcionalitu.

V projekte sa už zväčšuje počet tried. Aby ste si v nich zachovali poriadok a zoskupili spolu súvisiace triedy, vytvorte pre nástroje nový balík tools v balíku sk.tuke.kpi.oop.game a presuňte tam triedu BreakableTool, ako aj Hammer, Mjolnir a FireExtinguisher.

Krok 2: Self-exploding reactor

Doteraz ste mohli s reaktorom pracovať výlučne manuálne - vedeli ste ho zapnúť a vypnúť a vedeli ste mu zvýšiť a znížiť teplotu volaním vhodných metód pomocou Inšpektora. V tomto kroku však vykonáte potrebné úpravy na to, aby vedel reaktor pracovať automatizovane. Využijete na to systém akcií, ktoré budú reprezentovať činnosť alebo správanie aktéra v hernej scéne.

Ako je možné vidieť aj z diagramu tried uvedenom vyššie, nová trieda akcie PerpetualReactorHeating má dediť od triedy AbstractAction. Trieda AbstractAction je dostupná v balíku knižnice sk.tuke.kpi.gamelib.framework.actions.

Trieda AbstractAction používa typový parameter A, ktorým je definovaný typ aktéra, s ktorým sa môže akcia vykonávať. Keďže má akcia zvyšovať teplotu reaktora, dosaďte jej typový argument Reactor:

public class PerpetualReactorHeating extends AbstractAction<Reactor> {

}

public abstract class AbstractAction<A extends Actor> implements Action<A> {
    private A actor;

    @Override
    public A getActor() { return actor; }

    @Override
    public void setActor(A actor) { this.actor = actor; }

    /* ... zbytok triedy ... */
}

Pri implementovaní metódy execute() získajte referenciu na aktéra, s ktorým sa akcia vykonáva (bude to nejaký konkrétny reaktor) a zvýšte jeho teplotu o hodnotu danú parametrom konštruktora akcie.

Keďže pre naplánovanie akcie potrebuje aktér poznať scénu, do ktorej patrí, vhodným miestom pre naplánovanie akcie môže byť metóda addedToScene() zdedená od triedy AbstractActor, ktorá v parametri dostane referenciu na scénu (typ Scene) a je zavolaná po tom, čo bol aktér do danej scény pridaný. Metódu addedToScene() je teda potrebné prekryť. Nezabudnite však na to, že stále potrebujeme, aby sa pôvodná implementácia metódy addedToScene() z triedy AbstractActor vykonala, a teda využite kľúčové slovo super na zavolanie zdedenej implementácie!

Scéna definuje metódu scheduleAction(), ktorá akceptuje akciu a aktéra, s ktorým má akciu neskôr vykonávať. Naplánovanie vykonávania akcie v metóde reaktora môže preto vyzerať nasledovne:

// v metode addedToScene triedy Reactor
scene.scheduleAction(new PerpetualReactorHeating(1), this);

Náš taktický a strategický tím však navrhol aj doplnkovú metódu scheduleFor() dostupnú priamo na akcii, ktorá akceptuje aktéra a zabezpečí to isté, ako metóda scheduleAction() na scéne, len s o niečo prehľadnejším zápisom:

// v metode addedToScene triedy Reactor
new PerpetualReactorHeating(1).scheduleFor(this);

Disposable scheduleFor(A actor) {
    return actor.getScene().scheduleAction(this, actor);
}

Ak ste postupovali správne, zapnutému reaktoru sa bude postupom času zvyšovať teplota, čo si viete overiť pomocou inšpektora.

Krok 3: How cool is cool enough?

Teraz, keď máme prvý krok k vytvoreniu samočinného aktéra za sebou, určite neuniklo vašej pozornosti, že v podstate len na volanie jednej metódy reaktora bola vytvorená celá nová trieda. Tento nedostatok prvotného riešenia sa pokúsime postupne riešiť.

Úprava reaktora z predchádzajúceho kroku má však jeden háčik - tým, že necháte reaktor pracovať samostatne, bude sa systematicky prehrievať. A prehrievanie, ako vieme už od roku 1986, bude nevyhnutne viesť k jeho trvalému poškodeniu. Aby sme sa vyhli takejto situácii, namiesto kladív vytvoríte chladič, ktorý bude reaktor systematicky ochladzovať.

Správanie chladiča a jeho vzťah s reaktorom opisuje nasledujúci diagram tried:

Ako animáciu chladiča použite súbor fan. Keď bude chladič vypnutý, tak prehrávanie jeho animácie pozastavte. Keď chladič naopak zapnete, jeho animáciu spustite. Na objekte animácie nájdete vhodné metódy na jej ovládanie.

Metódu pomenujte napríklad coolReactor(). Pri jej zavolaní sa vždy (teda - ak je chladič zapnutý) zníži teplota pripojeného reaktora o jeden stupeň.

Pre zavolanie metódy v rámci akcie nie je potrebné vytvárať celú triedu akcie, ktorá potom slúži len na jednu, veľmi špecifickú funkciu. Namiesto implementácie novej triedy využijeme akciu Invoke (dostupnú v knižnici GameLib), ktorou môžeme definovať činnosť akcie (to, čo sa vykoná v metóde execute()) aj referenciou na metódu implementujúcu požadované správanie.

Akciu a jej naplánovanie teda zapíšeme takto:

// v metode addedToScene triedy Cooler
new Invoke<>(this::coolReactor).scheduleFor(this);

Takáto akcia však celkom nesplní to, čo od nej čakáme: metódu coolReactor() zavolá iba raz a potom je považovaná za skončenú (isDone() vráti true). Opakované vykonávanie akcie vieme docieliť kompozíciou s akciou Loop (dostupná v GameLib), ktorá volá inú akciu danú ako argument jej konštruktora a nikdy nie je považovaná za skončenú (isDone() akcie Loop stále vráti false):

// v metode addedToScene triedy Cooler
new Loop<>(new Invoke<>(this::coolReactor)).scheduleFor(this);

Čím viac chladičov pripojíte, tým skôr bude reaktor ochladený. Pozor však na to, že reaktor nie je možné chladiť do mínusových teplôt.

Krok 4: Defective Light

Náš analytický tím zadefinoval pokazené svetlo, ako svetlo, ktoré je pokazené. A keďže môžeme predpokladať, že pokazené svetlo bolo najprv v poriadku, jeho správanie odvodíme od dobrého svetla. V našom prípade sa bude pokazenosť prejavovať blikaním svetla v nepravidelných intervaloch.

Pre dosiahnutie efektu pokazeného svetla môžete použiť ľubovoľný postup. Jeden z nich môže vyzerať napr. tak, že vygenerujete náhodné číslo od 0 do 20 a ak bude vygenerované číslo 1, zmeníte stav svetla (zo zhasnutého na zasvietené a opačne).

Nezabudnite, že typ parametra metódy addLight() v triede Reactor netreba meniť. Je tu využitá vlastnosť polymorfizmu: DefectiveLight, ako potomok triedy Light, sa dá použiť všade tam, kde je akceptovaný typ Light.

Krok 5: Repository

Zdrojový kód nahrajte aj v prípade, ak ste nestihli dokončiť všetky úlohy. Rozpracované časti, ktoré by mohli spôsobiť kompilačné chyby, odporúčame zakomentovať.