OOP PHP - Începător

Cum adica ai vrea anticipat? Nu are de ce sa anticipe nimic. AI trebuie doar sa se uite la starea momentana a hartii, si sa iti spuna unde vrea sa puna simbolul, daca ar fi randul sau.

Game ia aceasta dorinta de la fiecare strategie in ordinea corecta, si decide ce face. Adevarata decizie finala tot de Game a luata. Asta inseamna ca "Game arbitreaza".

Nu vad unde ar fi loc de erase sau orice alt artificiu.

PS: pentru AI, incepe cu o strategie simpla: o clasa RandomNextMoveProvider: se uita la Map actual, si alege aleatoriu una dintre coordonatele libere ca "urmatoarea mutare".

Edited by OriginalCopy, 24 September 2018 - 13:42.

Strategia pentru AI, ca sa determine cea mai buna mutare (nu e chiar cea mai buna, e doar o mutare destul de buna pentru a face un joc cu AI jucabil ... adica are gameplay )  se uita pe harta si zice asa: daca pun aici, playerul celalalt va pune aici iar eu pun aici iar player-ul celalalt va pune aici. Hmm, nu-i bine. Ia sa incerc urmatoarea optiune. Si tot asa.

Va privi in viitor cate mutari ii setez eu sa se uite. Si pentru a face asta, AI-ul simuleaza jucarea jocului, fara a-l implica pe Game si fara sa duplice functionalitatea din game. Doar va calcula ceva.

De asta are nevoie de o harta a lui pe care sa experimenteze. As putea sa iau din $map un array cu mutarile si sa lucrez intern pe el. Dar va insemna sa duplic functionalitate care deja exista in Map, precum isEmpty samd.

Deci NextMoveProviderAI nu ia decizia finala, care e a lui Game. Decide doar unde vrea sa mute si ii paseaza asta player-ului AI. Iar player-ul face cererea de mutare lui Game. Asta asa ramane in continuare, nu stric aici nimic.

As putea sa fac si asa, cu alegere aleatorie prima data, dar am gasit deja idee de implementat un AI pe bune. Ah, imi veni alta idee. Va avea si functionalitatea cu alegere aleatorie. Pentru ca jocul sa poata fi jucat pe nivele diferite  de dificultate

wolfenste, on 24 septembrie 2018 - 15:21, said:

Eu zic sa incepi usor, si asta e doar cu strategia de aleatoriu.

Iar cealalta problema cu simularea: creaza-ti o Map interna strategiei respective pe care poti face orice te taie capul.

Map-ul strategiei e un detaliu de implementare si nu are nimic de-a face cu Map-ul lui Game (cel care conteaza).

Asta voiam si eu, in sfarsit vreau si eu ce trebuie. O sa fac un $map intern dintr-o clasa ce mosteneste pe Map. Imi trebuie cateva metode in Map de care doar AI ar avea nevoie, pe langa erase () si o metoda ce reda un array cu mutarile ramase disponibile. Deocamdata.

Cum sa bati la tictactoe un calculator care muta pe prima pozitie disponibila? Pui doar pe a doua coloana. Sau pe ultima. Sau pe a doua diagonala. Indiferent cine muta primul.

Mai trebuie test de constructie pentru clasele extinse de vreme ce mosteneste si constructorul?

wolfenste, on 27 septembrie 2018 - 11:52, said:

Nu vrei sa ai coverage dublu pentru ca nu are sens.

Phpunit nu e perfect, sau poate ca are niste setari pentru care eu inca nu am optat, sa zicem. Am facut o eroare fatala pe care nu a raportat-o. Testul nu trecea dar nu spunea ca e o eroare fatala pe acolo, adica o eroare pe care PHP o raporteaza.

De mai multa vreme am o dilema in legatura cu testele. In general, daca nu stiu inca de la inceput, pun membrele clasei ca private by default. Apoi schimb daca se iveste necesitatea. Cand spun necesitate, ma refer la necesitatea din codul de baza, cel testabil.

Dar a mai aparut un alt tip de necesitate, anume in codul ce testeaza (cel care lucreaza cu phpunit). Acolo am nevoie de unele metode aflate in codul testabil sa fie accesibile in codul ce tesetaza, adica sa fie publice. Numai acolo.

Intrebarea e daca sa fac metodele din codul testabil publice doar ca sa poata fi accesate in codul ce testeaza. In codul de baza, repet, nu au nevoie sa fie publice.

Nu.

Acele metode pe care ai vrea să le faci publice sunt folosite altundeva.

E suficient (ba chiar recomandat) să testezi doar acele metode.

Raționament: de la o suită de teste te interesează să îți dea siguranța că dacă zice verde, atunci codul e bun de pus în producție.

Code coverage e o măsurătoare interesantă și de multe ori utilă, dar nicidecum un scop în sine.

PS: acele "alte metode" le testezi în teste de integrare.

PPS: există situații și situații în care acea testare are sens. De exemplu când metoda respectivă implementează un algoritm mai complicat. Totuși, aceste situații sunt judecate după caz.

Vino cu un caz concret dacă vrei un sfat concret.

Am vazut ca metode private sunt testate indirect, unele fiind testate in foarte multe teste. Stiam ca nu e nevoie sau chiar nu trebuie sa testez metode private sau protected.

Dar am de exemplu

mapIndexToCoordinates () din clasa Map, care e protected

si aveam nevoie de ea intr-un test, nu ca sa o testez pe ea ci ca sa scriu testul pentru altceva, pentru alta metoda din alta clasa. Fiind protected, nu o puteam folosi acolo, in test.

Nu am mai folosit-o, am rescris testul. Dar m-am mai lovit de situatia asta, fiind mult mai simplu daca as fi avut la dispozitie mai multe metode ca publice. Numai ca in afara de accesul din clasele de test, nu aveau de ce sa fie publice. Nu mi se pare in regula sa le fac publice doar de dragul testelor, dar daca totusi ar fi permis ?! Si eu ma chinui asa fara ele ... De asta am intrebat.

Vesti proaste; proaspete am vrut sa zic. Imi trebuie inca doi parametri in NextMoveProviderAI, unul ce va indica nivelul de dificultate cu care se joaca si unul care sa indice faptul ca in tura respectiva acel player de tip AI sta pe tusa (ca sa nu mai calculeze degeaba). Ar cam trebui pentru ca va fi vorba de o metoda cu recursivitate deci cu ceva stres in ce priveste performanta.

Pentru player-ul uman am considerat ca daca optiunea sa (mutarea) este null inseamna ca nu este randul sau la mutare.

Deci inapoi la medificat testele pe ici pe colo. E deja rutina sa fac asta.

Pentru diferite nivele, ai diferiti algoritmi, deci vei avea si clase NextMoveProvider diferite.

Nu inghesui tot AI-ul in spatele lui NextMoveProviderAI.

Cat despre ordine, nu inteleg problema, X face mereu prima mutare. Ca X poate fi AI sau uman, aia e decis de providerul corespunzator.

"NextMoveProviderAI" e un nume gresit, ar trebui sa ai NextMoveProviderAIBeginner, NextMoveProviderAIAdvanced, ...

Ok, schimb. Dar doua din cele trei strategii sunt constituite din o metoda cu una sau doua linii de cod. A treia strategie va avea probabil trei metode mai mari in rest fiind cod comun; deci ar trebui ca aceste clase sa mosteneasca de la o clasa de baza NextMoveProviderAI.

Despre ordine, daca am doi jucatori umani care joaca mai multe runde pastrandu-si simbolul si unul din ei vrea sa mute si el primul? Sau daca as avea o regula: castigatorul rundei precedente muta primul? Parca scrisesem ceva in rules.md despre un scor - ce presupune mai multe runde intre aceiasi jucatori. Dar nu mai stiu pe unde m-am referit la cine muta primul.

wolfenste, on 02 octombrie 2018 - 09:44, said:

Fa o clasa abstracta comuna sau un trait.

wolfenste, on 02 octombrie 2018 - 09:44, said:

Aici discuti despre ceva ce implica un nou concept.

Pana acum era vorba despre un singur joc.

Vorbesti insa despre reguli ce implica mai multe jocuri (consecutive).

Pentru asta trebuie sa introduci o noua clasa.