Fapados RPG (act 1)

[Keelorath]

Kedzetben létrehoztunk 2 classt (warrior és mage) ami a specializációkat reprezentálja. Létrehoztunk egy interface-t amit implementáltunk mind a két classhoz. Végül egy combattal teszteltük őket.

[hegyhati]

No, hat Ti nem azt csinaltatok, amit kertem, hanem azt meg meg sok mindent. Az onszorgalmat ertekelem, csak ha elore megcsinaljatok a feladatokat, akkor kesobb nem lesznek, es ezzel pont bizonyos dolgok nem jonnek majd ugy ki. Pl ket parhuzamos szalon kell megcsinalni valamit, ami ugyanazt a kodreszletet turkalna, de ha Nektek mar eleve benne van az egyik, akkor nem lesz conflict, igy pont a lenyeg marad el. Szoval alapvetoen azt kernem / javasolnam, hogy ne dolgozzatok "elore", ha van egy specifikacio, akkor kb az legyen meg :-)

Node ettol fuggetlenul:

• Az Entity-ben en nem szeretnek setHealth-et latni. Nem akarnam meghagyni maganak a lehetoseget, hogy barhol a kodban veletlenul csak igy-ugy atallitgatodjon egy harcosnak a hp-je. Az csak ugy allitodhat, ha egy harcos megut egy masikat, mashogy kod szinten se legyen ra lehetoseg.
• Ha az isAlive meg van mar irva itt, akkor az attack is meg lehetne, bar ha a setHealth-et kivesszuk, akkor nem, szoval ezt majd talaljatok ki, hogy oldjatok fel :-)
• Mage konstruktorban mi ertelme van a fuggvenyt hivni a konkret implementacio hasznalata helyett?
• a Mage.attack kicsit "terjengos"
• EGy csomo kod duplikalva van Warrior es Mage kozott. Ez nem jo, tessek egy ososztalyba kiszedni, ami kozos, es csak a kulonbsegnek letrehozni gyereket.

Amguy mondom, szuper, meg csinaltatok koddokumentaciot is (ami szinten nem volt meg keres, kesobb lesz), git history is tetszik. En most "visszabutitanam" kicsit a programotokat, de ha megtartjatok, amiatt sem "akadekosokodok". Viszont a fentieket akkor tessek rendbetenni.

[Keelorath]

Köszönjük a visszajelzést! Én voltam az aki mondta hogy több spec legyen. Egy kicsit zavart, hogy egy "RPG"-ben csak 1 spec van, de akkor a jövőbe visszafogom magam :) . Amiket írtál rövidesen orvosoljuk.

[hegyhati]

Ha spoilerezni szeretnel, lesd meg nyugodtan, mik voltak Gyorben, hasonlo dolgok lesznek itt is. Meg annyi jutott eszembe, hogy bar a java final lenyegesen gyengebb valami, mint a c++ const-ja, de azert ahol lehet/indokolt,ott legyen ott a final.

[Keelorath]

Mondom, nem szándékoztam előre haladni és elrontani a poént. Csak az az egy dolog engem személyesen zavart és ennyi. Magamnak se szeretnék spoilereznia Győri csapat kódját figyelgetve.

[Keelorath]

A public setHealth problémát megoldottuk és a warriorból csináltunk egy "default" Entity-t. Nézd meg mégegyszer légyszives.

[hegyhati]

Az attack nagyon bloat. pl:

        var enemyDefense = other.getDefense();
        var ownAttack = getAttack();

        var damage = ownAttack - enemyDefense;

helyett pl

int damage = getAttack()-other.getDdefense();

Rule of thumb: ha egy valtozonak inicializalaskor erteket adsz, aztan egyszer hasznalod csak osszesen utana, akkor az inicializalo kodot odairhatnad, es olvashatobb lesz a kod, kevesebb a hibalehetoseg, stb.

A masik, hogy a var oke, type inference rendben van, de amikor egy int lenne a dolog, akkor igazabol begepelni ugyanannyi, csak az olvasonak nehezebb olvasni, meg nem latja azonnal, IDE-nek is nehezebb lekovetni. Amikor a tipus mondjuk egy Hashmap<String,List<Integer>> akkor ertheto, hogy jol jon a var. Ez csak minor megjegyzes.

A hp<0 logikat leellenorizni dontsetek el, kinek a felelossege? Ha a setHealth-nek, akkor O csinalja.Ha nem neki (akkor meg sok ertelme nincs hogy kulon fuggveny van ra), akkor onnet keruljon ki. De 1 helyen legyen ez a logika tesztelve.

[vadalf]

attack() metódusban a damage <= 0 feltétel azt nézi csak, hogy tudott-e sebezni, mert egy negatív szám az egy heal-nek számítana. Logikailag értelmetlen lenne, ha magas defense miatt kap egy heal-t támadás után egy egység.

[hegyhati]

[vadalf]

Remélhetőleg így most jobban néz ki a dolog:

• Beviteli érték validálás a konstruktorban történik meg az életpontokhoz.
• Az életpontok nem negatív értéktartományon belüli elhelyezkedésének feltételezése egy Math.max hívással van megőrizve a setHealth metódusban.
• attack() soványka lett.

[hegyhati]

wunderbar :-)