Do nového roku jako lepší programátoři? Znovu otevíráme večerní školu programování. Nette framework, návrhové vzory, testování nebo vůbec poprvé kurzy ASP.NET dostupné odkudkoli v republice.

8. díl - Aréna s mágem (dědičnost a polymorfismus)

Java Objektově orientované programování Aréna s mágem (dědičnost a polymorfismus)

ONEbit hosting Unicorn College Tento obsah je dostupný zdarma v rámci projektu IT lidem. Vydávání, hosting a aktualizace umožňují jeho sponzoři.

V minulém dílu tutoriálů o Javě jsme si vysvětlili dědičnost a polymorfismus. Dnes máme slíbeno, že si je vyzkoušíme v praxi. Bude to opět na naší aréně, kde z bojovníka oddědíme mága. Tento tutoriál již patří k těm náročnějším a bude tomu tak i u dalších. Proto si průběžně procvičujte práci s objekty, zkoušejte si naše cvičení a také vymýšlejte nějaké své aplikace, abyste si zažili základní věci. To, že je tu přítomen celý seriál neznamená, že ho celý najednou přečtete a pochopíte :) Snažte se programovat průběžně.

Mág

Než začneme něco psát, shodněme se na tom, co by měl mág umět. Mág bude fungovat stejně, jako bojovník. Kromě života bude mít však i manu. Zpočátku bude mana plná. V případě plné many může mág vykonat magický útok, který bude mít pravděpodobně vyšší damage, než útok normální (ale samozřejmě záleží na tom, jak si ho nastavíme). Tento útok manu vybije na 0. Každé kolo se bude mana zvyšovat o 10 a mág bude podnikat jen běžný útok. Jakmile se mana zcela doplní, opět bude moci magický útok použít. Mana bude zobrazena grafickým ukazatelem, stejně jako život.

Vytvoříme tedy třídu Mag.java, zdědíme ji z Bojovnik a dodáme ji atributy, které chceme oproti bojovníkovi navíc. Bude tedy vypadat takto (opět si ji okomentujte):

class Mag extends Bojovnik
{
        private int mana;
        private int maxMana;
        private int magickyUtok;
}

V mágovi nemáme zatím přístup ke všem proměnným, protože jsou v bojovníkovi nastavené jako privátní. Musíme třídu Bojovnik lehce upravit. Změníme modifikátory private u atributů na protected. Budeme potřebovat jen kostka a jmeno, ale klidně nastavíme jako protected všechny atributy charakteru, protože se v budoucnu mohou hodit, kdybychom se rozhodli oddědit další typy bojovníků. Naopak atribut zprava není vhodné nastavovat jako protected, protože nesouvisí s bojovníkem, ale s nějakou vnitřní logikou třídy. Třída tedy bude vypadat nějak takto:

protected String jmeno;
protected int zivot;
protected int maxZivot;
protected int utok;
protected int obrana;
protected Kostka kostka;
private String zprava;

...

Přejděme ke konstruktoru.

Konstruktor potomka

Java nedědí konstruktory! Je to pravděpodobně z toho důvodu, že předpokládá, že potomek bude mít navíc nějaké atributy a původní konstruktor by u něj byl na škodu. To je i náš případ, protože konstruktor mága bude brát oproti tomu z bojovníka navíc 2 parametry (mana a magický útok).

Definujeme si tedy konstruktor v potomkovi, který bere parametry potřebné pro vytvoření bojovníka a několik parametrů navíc pro mága.

O potomků je nutné vždy volat konstruktor předka. Je to z toho důvodu, že bez volání konstruktoru nemusí být instance správně inicializovaná. Konstruktor předka nevoláme pouze v případě, že žádný nemá. Náš konstruktor musí mít samozřejmě všechny parametry potřebné pro předka plus ty nové, co má navíc potomek. Některé potom předáme předkovi a některé si zpracujeme sami. Konstruktor předka se vykoná před naším konstruktorem.

V Javě existuje klíčové slovo super, které je podobné námi již známému this. Na rozdíl od this, které odkazuje na konkrétní instanci třídy, super odkazuje na předka. My tedy můžeme zavolat konstruktor předka s danými parametry a poté vykonat navíc inicializaci pro mága.

Konstruktor mága bude tedy vypadat takto:

public Mag(String jmeno, int zivot, int utok, int obrana, Kostka kostka, int mana, int magickyUtok)
{
        super(jmeno, zivot, utok, obrana, kostka);
        this.mana = mana;
        this.maxMana = mana;
        this.magickyUtok = magickyUtok;
}

Pozn. stejně můžeme volat i jiný konstruktor v té samé třídě (ne předka), jen místo super použijeme this.

Přesuňme se nyní do Arena.java a druhého bojovníka (Shadow) změňme na mága, např. takto:

Bojovnik gandalf = new Mag("Gandalf", 60, 15, 12, kostka, 30, 45);

Změnu samozřejmě musíme udělat i v řádku, kde bojovníka do arény vkládáme. Všimněte si, že mága ukládáme do proměnné typu Bojovnik. Nic nám v tom nebrání, protože bojovník je jeho předek. Stejně tak si můžeme typ proměnné změnit na Mag. Když aplikaci nyní spustíme, bude fungovat úplně stejně, jako předtím. Mág vše dědí z bojovníka a zatím tedy funguje jako bojovník.

Polymorfismus a přepisování metod

Bylo by výhodné, kdyby objekt Arena mohl s mágem pracovat stejným způsobem jako s bojovníkem. My již víme, že takovémuto mechanismu říkáme polymorfismus. Aréna zavolá na objektu metodu utoc() se soupeřem v parametru. Nestará se o to, jestli bude útok vykonávat bojovník nebo mág, bude s nimi pracovat stejně. U mága si tedy přepíšeme metodu utoc() z předka. Přepíšeme zděděnou metodu tak, aby útok pracoval s manou, hlavička metody však zůstane stejná.

Když jsme u metod, budeme v Bojovnik.java ještě jistě používat metodu nastavZpravu(), ta je však privátní. Označme ji jako protected:

protected void nastavZpravu(string zprava)

Pozn. Při návrhu bojovníka jsme samozřejmě měli myslet na to, že se z něj bude dědit a již označit vhodné atributy a metody jako protected. V tutoriálu k bojovníkovi jsem vás tím však nechtěl zbytečně zatěžovat, proto musíme modifikátory změnit až teď, kdy jim rozumíme :)

Pojďme přepsat utoc() bojovníka v mágovi. Metodu normálně definujeme v Mag.java tak, jak jsme zvyklí, pouze ji označíme @Override:

@Override
public void utoc(Bojovnik souper)

Podobně jsme přepisovali metodu toString() u našich objektů, každý objekt v Javě je totiž odděděný od java.lang.Object, který obsahuje několik defaultních metod a jedna z nich je i toString(). Při její implementaci bychom tedy měli označit, že se jedná o přepsanou metodu.

Chování metody utoc() nebude nijak složité. Podle hodnoty many buď provedeme běžný útok nebo útok magický. Hodnotu many potom buď zvýšíme o 10 nebo naopak snížíme na 0 v případě magického útoku.

@Override
public void utoc(Bojovnik souper)
{
        int uder = 0;
        // Mana není naplněna
        if (mana < maxMana)
        {
                mana += 10;
                if (mana > maxMana)
                        mana = maxMana;
                uder = utok + kostka.hod();
                nastavZpravu(String.format("%s útočí s úderem za %s hp", jmeno, uder));
        }
        else // Magický útok
        {
                uder = magickyUtok + kostka.hod();
                nastavZpravu(String.format("%s použil magii za %s hp", jmeno, uder));
                mana = 0;
        }
        souper.branSe(uder);
}

Kód je asi srozumitelný. Všimněte si omezení many na maxMana, může se nám totiž stát, že tuto hodnotu přesáhneme, když ji zvyšujeme o 10. Když se nad kódem zamyslíme, tak útok výše v podstatě vykonává původní metoda utoc(). Jistě by bylo přínosné zavolat podobu metody na předkovi místo toho, abychom chování opisovali. K tomu opět použijeme super:

@Override
public void utoc(Bojovnik souper)
{
        // Mana není naplněna
        if (mana < maxMana)
        {
                mana += 10;
                if (mana > maxMana)
                        mana = maxMana;
                super.utoc(souper);
        }
        else // Magický útok
        {
                int uder = magickyUtok + kostka.hod();
                nastavZpravu(String.Format("%s použil magii za %s hp", jmeno, uder));
                souper.branSe(uder);
                mana = 0;
        }
}

Opět vidíme, jak můžeme znovupoužívat kód. S dědičností je spojeno opravdu mnoho technik, jak si ušetřit práci. V našem případě to ušetří několik řádků, ale u většího projektu by to mohlo mít obrovský význam.

Aplikace nyní funguje tak, jak má.

Tahová hra aréna s mágem v Javě

Arena nás však neinformuje o maně mága, pojďme to napravit. Přidáme mágovi veřejnou metodu grafickaMana(), která bude obdobně jako u života vracet String s grafickým ukazatelem many.

Abychom nemuseli logiku se složením ukazatele psát dvakrát, upravíme metodu grafickyZivot() v Bojovnik.java. Připomeňme si, jak vypadá:

public String grafickyZivot()
{
        String s = "[";
        int celkem = 20;
        double pocet = Math.round(((double)zivot / maxZivot) * celkem);
        if ((pocet == 0) && (nazivu()))
                pocet = 1;
        for (int i = 0; i < pocet; i++)
                s += "#";
        s = String.format("%1$-" + (celkem + 1) + "s", s);
        s += "]";
        return s;
}

Vidíme, že není kromě proměnných zivot a maxZivot na životě nijak závislá. Metodu přejmenujeme na grafickyUkazatel a dáme ji 2 parametry: aktuální hodnotu a maximální hodnotu. zivot a maxZivot v těle metody poté nahradíme za aktualni a maximalni. Modifikátor bude protected, abychom metodu mohli v potomkovi použít:

protected String grafickyUkazatel(int aktualni, int maximalni)
{
        String s = "[";
        int celkem = 20;
        double pocet = Math.round(((double)aktualni / maximalni) * celkem);
        if ((pocet == 0) && (nazivu()))
                pocet = 1;
        for (int i = 0; i < pocet; i++)
                s += "#";
        s = String.format("%1$-" + (celkem + 1) + "s", s);
        s += "]";
        return s;
}

Metodu grafickyZivot() v Bojovnik.java naimplementujeme znovu, bude nám v ní stačit jediný řádek a to zavolání metody grafickyUkazatel() s příslušnými parametry:

public String grafickyZivot()
{
        return grafickyUkazatel(zivot, maxZivot);
}

Určitě jsem mohl v tutoriálu s bojovníkem udělat metodu grafickyUkazatel() rovnou. Chtěl jsem však, abychom si ukázali, jak se řeší případy, kdy potřebujeme vykonat podobnou funkčnost vícekrát. S takovouto parametrizací se v praxi budete setkávat často, protože nikdy přesně nevíme, co budeme v budoucnu od našeho programu požadovat.

Nyní můžeme vykreslovat ukazatel tak, jak se nám to hodí. Přesuňme se do Mag.java a naimplementujme metodu grafickaMana():

public String grafickaMana()
{
        return grafickyUkazatel(mana, maxMana);
}

Jednoduché, že? Nyní je mág hotový, zbývá jen naučit arénu zobrazovat manu v případě, že je bojovník mág. Přesuňme se tedy do Arena.

Rozpoznání typu objektu

Jelikož se nám nyní vykreslení bojovníka zkomplikovalo, uděláme si na něj samostatnou metodu vypisBojovnika(), jejím parametrem bude daná instance bojovníka:

private void vypisBojovnika(Bojovnik b)
{
        System.out.println(b);
        System.out.print("Zivot: ");
        System.out.println(b.grafickyZivot());
}

Nyní pojďme reagovat na to, jestli je bojovník mág. Minule jsme si řekli, že k tomu slouží operátor instanceof:

private void vypisBojovnika(Bojovnik b)
{
        System.out.println(b);
        System.out.print("Zivot: ");
        System.out.println(b.grafickyZivot());
        if (b instanceof Mag)
        {
                System.out.print("Mana:  ");
                System.out.println(((Mag)b).grafickaMana());
        }
}

Bojovníka jsme museli na mága přetypovat, abychom se k metodě grafickaMana() dostali. Samotný Bojovnik ji totiž nemá. To bychom měli, vypisBojovnika budeme volat v metodě vykresli(), která bude vypadat takto:

private void vykresli()
{
        System.out.println("-------------- Aréna -------------- \n");
        System.out.println("Bojovníci: \n");
        vypisBojovnika(bojovnik1);
        System.out.println();
        vypisBojovnika(bojovnik2);
        System.out.println();
}

Hotovo :)

Tahová hra aréna s mágem v Javě

Aplikaci ještě můžeme dodat hezčí vzhled, vložil jsem ASCIIart nadpis Aréna, který jsem vytvořil touto aplikací: http://patorjk.com/software/taag . Metodu k vykreslení ukazatele jsem upravil tak, aby vykreslovala plný obdelník místo # (ten napíšete pomocí Alt + 219). Výsledek může vypadat takto:

Tahová hra aréna s mágem v Javě

Kód máte v příloze. Pokud jste něčemu nerozuměli, zkuste si článek přečíst vícekrát nebo pomaleji, jsou to důležité praktiky. Příště si vysvětlíme pojem statika.


 

Stáhnout

Staženo 819x (31.13 kB)
Aplikace je včetně zdrojových kódů v jazyce java

 

  Aktivity (3)

Článek pro vás napsal David Čápka
Avatar
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (16 hlasů) :
4.8754.8754.8754.8754.875


 


Miniatura
Předchozí článek
Dědičnost a polymorfismus

 

 

Komentáře
Zobrazit starší komentáře (33)

Avatar
Lubor Pešek
Člen
Avatar
Lubor Pešek:

Ve vzorových řešení máš malou hovadinu v Kostka.java. V přetíženém kostruktoru jednou implementuješ náhodonost včetně stěn, tak proč to potom porušuješ? Navíc ti chybí volání přetíženého konstruktoru.

public Kostka(){
        this.Kostka(6);                 //<-- zbytečná implementace
        random = new Random();  //<-- zbytečná implementace
        this(6);                                //<-- volání přetíženého konstruktoru, které zde chybí
}

public Kostka(int pocetSten){
        this.pocetSten = pocetStem();
        random = new Random();
}

Další - metoda hod(), podle této implementace může hodit i 7:) je tam jedna jednička navíc (otázka za jednoho bludišťáka: kterápak to asi bude?)

Ve třídě Bojovnik.java a Mag.java zase nemáš návratové metody pro atributy třídy - zivot a mana. Zase porušuješ zapouzdření.

Odpovědět 13.1.2016 13:08
Existují dva způsoby, jak vyřešit problém. Za prvé vyhoďte počítač z okna. Za druhé vyhoďte okna z počítače.
Avatar
svizensky
Člen
Avatar
 
Odpovědět 26.4.2016 13:38
Avatar
Avev Frger
Člen
Avatar
Avev Frger:

V tele metody grafickyUkazatel ma podmienka

if ((pocet == 0) && (nazivu()))
  pocet = 1;

vyzerat nejako inak lebo pri zobrazovani many je ukazatel many zobrazeny pri malom mnozstve many nespravne ak mag zije.

 
Odpovědět 23.7.2016 17:41
Avatar
Avev Frger
Člen
Avatar
Odpovídá na Avev Frger
Avev Frger:

presnejsie po vycerpani many po utoku je zvysena o 1

Editováno 23.7.2016 17:57
 
Odpovědět 23.7.2016 17:55
Avatar
Jan Kunágl
Člen
Avatar
Jan Kunágl:

Zdravím, prosil bych o radu (pokročilejším se omlouvám, pro ty to bude prkotina). Celý projekt Tahovy boj je mi jakžtakž jasný, až na jednu maličkost. Jde mi o použití příkazu "return".
Vím, že když se volá nějaká metoda, aby např. vypočítala nějakou hodnotu, vrací se tato hodnota z této metody pomocí příkazu return.
Potom je další případ, že nějaká metoda volá jinou metodu, aby něco vykonala, což se v tomto tutorialu celkem běžně dělalo bez příkazu return ve volané metodě.
Další použití volání metody metodou v tomto tutorialu už mi právě jasné není. Jde o případ, že se volá nějaká metoda, která vykoná jenom to, že zavolá jinou metodu a předá jí nějaké parametry. Např.:

/*
    Metoda pro grafické ukázání stavu many mága */
    public String grafickaMana(){
        return grafickyUkazatel(mana, maxMana);//Volá M pro grafický výpis dodaných parametrů mateřské T Bojovník
    }

Proč je tam, když se z metody grafickaMana(), volá metoda grafickyUkazatel(), předtím to slovo return? Nejde přeci o to, aby poslední volaná metoda vrátila nějakou hodnotu, se kterou volající bude potom nějak pracovat, ale jde o vykonání celé posloupnosti příkazů ve volané metodě. Já chápu, že sama metoda grafickaMana() je taky volaná zase jinou metodou. Jde o to, že první volající metodě předá tato metoda tu poslední volanou metodu? A není v tom potom trochu zmatek? Nefungovalo by to i bez toho return (samozřejmě bych dal do hlavičky M potom slovo "void")? Já si myslím, že potom může být při psaní kódu docela zmatek v tom, kdy když z nějaké metody volám jinou metodu (což je, jak pozoruji, jedna z hlavních činností programu v javě), tak tam mám/nemám to "return" použít...

 
Odpovědět 23.8.2016 15:42
Avatar
pocitac770
Redaktor
Avatar
Odpovídá na Jan Kunágl
pocitac770:

Obecně my chceme metodami typu grafickyUkazatel -> grafickyZivot/gra­fickaMana získat String, který bude obsahovat grafické zobrazení našeho počtu životů/many. Představ si tuto konstrukci jako dědičnost (s trochou abstrakce, o tom se dovíš později). Máš jednu metodu (grafickyUkazatel), která slouží jako základ pro další metody (grafickyZivot, grafickaMana). Ty vždy pracují s jinými atributy, jednou se životem, jednou s manou, ale princip vykreslování přes trojčlenku (jestli si dobře pamatuju z dob, když jsem se to učil, teď jsem se na to nekoukal :D) je pokaždé stejný.
Trochu přimhouřím oči od své původní myšlenky, a přirovnám to k něčemu jinému. Třída-instance. Představ si třídu "Ukazatel", od které si vytvoříš 2 instance, jednu, která bude pracovat s životy, a jednu, která bude pracovat s manou, dejme tomu, že by jsme přes boxing průběžně předávali jejich hodnoty (ach ty pozdní znalosti, ignoruj mě :D), a pak by jsme nějak vraceli metodou String, který by samotný ukazatel "vykresloval". Když tak o tom přemýšlím, je to mnohem ladnější řešení, než to zdejší, ale to se stav na nedostatku znalostí.
K tomu return. Rád bych řekl TLDR, ale spíš musím říct, že jsem nepochopil, kde je problém. Return obecně ukončuje metodu a umožní metodu vrátit nějaký datový typ. Pokud metoda něco vrací (není void), tak si můžeme v kódě představit, jako by tam nebyla metoda, ale nějaký String, to jde například reálně použít při debugu, když chceš jenom otestovat třeba zarovnání a ještě nemáš hotovou logiku ukazatele, tak tam doplníš třeba

/*
    Metoda pro grafické ukázání stavu many mága */
    public String grafickaMana(){
        String s = "testovací řádek";
        return s;
    }

metoda vrací nějaký String, tudíž to přesně tak funguje. a když to máš v metodě, která taktéž vrací String, tak proč to prostě nepředat dál? Trochu rozsáhlejší typ problematiky by mohl být, kdyby jsi připravoval v metodě nějak ty parametry, třeba....

/*
    Metoda pro grafické ukázání FALEŠNÉHO #thugLife stavu many mága */
    public String grafickaFakeMana(){
        int fakeMana = mana + 10;
        return grafickyUkazatel(fakeMana, maxMana);//Volá M pro grafický výpis dodaných parametrů mateřské T Bojovník
    }

Pořád by jsi chtěl akorát předat ten výsledek metody, ale jakoby si "nascriptit" to, co se bude používat jako parametry, případně jak se budou ty parametry upravovat (viz výše), asi bude kratší v tuto chvíli napsat do kódu

String s = grafickaMana();

než

String s = grafickyUkazatel(mana, maxMana);

Takhle se to zdá jenom jako lenost, ale představ si situaci, kdy to bude něco podobného jako ta moje grafickaFakeMana, ale zpracování dat by zabralo třeba 10 řádků. To by pak byl v kódu bordel... Zdejší tutoriály se snaží lidi naučit myslet co nejefektivněji, a ukazují to na jednoduchých příkladech, aby si to vstříbili již od počátku...
Pff, doufám, že touhle vyčerpávající odpovědí jsem ti odpověděl na všechny otázky, ale kdyby něco bylo stále nejasné, klidně napiš :)

Editováno 23.8.2016 18:45
 
Odpovědět  +1 23.8.2016 18:43
Avatar
Jan Kunágl
Člen
Avatar
Odpovídá na pocitac770
Jan Kunágl:

Ano, myslím, že to chápu.
V tomto případě vlastně chceme od metody (bez ohledu na to, že voláním jiné M) aby nám vrátila hodnotu - řetězec, proto to return, kterým si zároveň i tu metodu, ukončíme.
Způsob, jakým se tato metoda k výsledku dostane, tj. v tomto případě voláním další, obecnější metody, které předá "svoje" parametry, je jenom efektivnějším způsobem, jak nevyrábět další zbytečné metody pro něco, pro co už metoda je.
Ale stejně si to zkusím :-), co to udělá, když tam to return nedám a M grafickyUkazatel() v M grafickaMana() jen zavolám, bez toho return, jestli bude program fungovat, případně, že se M grafickyUkazatel() sice vykoná, ale program se tím předčasně ukončí. Každopádně dám vědět, jak to dopadlo.

Děkuji moc za tvojí reakci, která mi dala, kromě odpovědi i další podněty k přemýšlení :-)

 
Odpovědět 23.8.2016 21:38
Avatar
pocitac770
Redaktor
Avatar
Odpovídá na Jan Kunágl
pocitac770:

Vím, že na to určtě přijdeš sám, ale radši dám menší nápovědu, je to vlastně úplně to samé, jako napsat

int i = 2;
i + 5;

kompilátor ti to sice vyhodí jako chybu, tohle je totální nesmysl, ale jaksi by to tomu odpovídalo, jak by to fungovalo i v tomto případě (upřímně to sám nechápu, mě to zní jako docela logický statement). To, co popisuješ je používáno v různých frameworcích/kni­hovnách, které jsou pro programátory vytvořené, aby je sami nějakým svým způsobem použili. Dejme tomu, že existuje metoda .mkdir(), která vytváří složku. Vypadá to nějak takto.

mojeSlozka.mkdir();

Funguje to, úplně bezchybně, ALE! většinou je to používáno takto

if(!mojeSlozka.mkdir()){
        //nějaký další kód, viz další lekce ;)
}

Kde se z ničeho nic ta booleanová hodnota vzala? Ona tam byla i předtím, akorát jsme ji nijak nevyužili, nezajímala nás. V druhém příkladě jsme ji naopak kvůli něčemu potřebovali, tak jsme si ji zjistili, jaká vlastně je, a podle toho zareagovali, nějak jsme ji použili.

Editováno 23.8.2016 23:16
 
Odpovědět  +1 23.8.2016 23:13
Avatar
Jan Kunágl
Člen
Avatar
Jan Kunágl:

Takže jsem zkusil vynechat to return a metodu:

public String grafickaMana(){
    return grafickyUkazatel(mana, maxMana);//Volá M pro grafický výpis dodaných parametrů mateřské T Bojovník
}

upravil do této podoby:

public void grafickaMana(){
        grafickyUkazatel(mana, maxMana);//Volá M pro grafický výpis dodaných parametrů mateřské T Bojovník
    }

Kompilátor to vynechání return vyhodnotil jako chybu, ještě před spuštěním programu. Jako chybná byla označena ne M grafickaMana(), ale původní příkaz tuto metodu volající:

System.out.println(((Mag)b).grafickaMana());

Myslím, že to byla jenom moje základní chyba a neuvědomění si faktu, že příkaz System.out.prin­tln() prostě vyžaduje jako argument řetězec a ne vykonání nějaké metody, která volá další metodu, bez vrácení toho String pomocí return v té volající metodě:-)

Takže jestli jsem tě dobře pochopil, když máme např. nějaký výraz (metodu), může být rozdíl ve způsobu, jak jej použijeme a co z něj chceme dostat. A to je ten základní kámen úrazu - nemíchat potom hrušky a jablka.
No nic budu o tom ještě nějakou chvíli přemýšlet, snad se do toho nezamotám :-)

Děkuji moc za užitečné odpovědi!

 
Odpovědět 24.8.2016 14:23
Avatar
David
Člen
Avatar
Odpovídá na Avev Frger
David:

Já to vyřešil v rychlosti tak, že jsem podmínku odstranil a použil zaokrouhlení nahoru, nechtělo se mi s tím víc zdržovat.
Navíc jsem úplnej začátečník, takže se mi ani do ničeho složitějšího pouštět nechtělo. :)

 
Odpovědět 25.9.2016 22:48
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 10 zpráv z 43. Zobrazit vše