ITI0011:Säuts - koodijuhend

Kirjeldus

Siin lehel on kirjeldatud, kuidas koodi kirjutada 2. kodutöö "Säuts" jaoks. Ülesande kirjeldust loe siit (Säuts).

Kui tõmbate alla malli, siis see sisaldab päris mitut interface'i. Interface'id on antud ette seepärast, et meil oleks võimalik teie koodi testida. Teine variant oleks see, et oleksime andnud ette n-ö mallid (klassid), kus peate meetodite sisud ära kirjeldama. Interface on selle jaoks sobiv, kui tahame kokku leppida meetodite nimetuses ja struktuuris. Teie peate looma klassid, mis implementeerivad neid interface'e. Kui kogu ülesande lahendate ära, peaks teil arvatavasti 11 java faili tekkima (lisaks interface'i failidele). Esialgu on nõue, et interface'ide failid oleksid samas kaustas (paketis) kogu ülejäänud lahendusega. Võimalik, et jõuame tehniliselt valmis lahenduse, mis oskaks interface'e ka mujalt otsida.

Nagu selles juhendis näete, on ülesanne jagatud väga väikesteks osadeks. See ei pruugi alati praktiline olla. Kindlasti veendute ise, et selle ülesande lahendamise teeb liigne tükeldamine palju egamugavamaks ja võib-olla isegi ebaloogiliseks. Tükeldamine on aga hea testimise jaoks. Kui teil oleks vaid üks meetod "main", mis saab ette linna nime ja tagastab selles linnas viimased säutsud, siis me saaksime hinnata teie lahendust vaid meetodi väljundi põhjal. Kui te eksite ühe sammuga selles meetodis, on kogu tulemus vale. Automaatselt hinnates võiks tulemus olla 0. Kui me aga jagame ülesande väikesteks tükkideks, saame igat väikest tükki (ehk sammu) eraldi testida. Kui ülejäänud sammud töötavad, viga on ühes sammus, on võimalik kokku saada näiteks 95%. See number on suvaline, aga mõte on ehk arusaadav. Samamoodi on mõistlik päris projektides jagada mingi funktsionaalsus väiksemateks osadeks, et seda testida ning avastada võimalikke vigu.

Arhitektuur

Süsteemiarhitektuur on järgmine.

      main app           (external) service


                     /-- LocationSearch
                    /
TwitterApplication  ---- Cache
                    \
                     \-- TwitterSearch

Põhirakendus on TwitterApplication, selle küljes on erinevad teenused, teenused on eraldi klassid. Analoogselt võib mõelda, et TwitterApplication on nagu reisibüroo, kes vahendab mingeid teenuseid. Näiteks lennuinfot küsitakse mingilt väliselt teenusel mõne lennufirma käest. Hotellide kohta infot saab mõnest hotelliportallist jne. Antud ülesandes kasutatakse teenustena asukohaotsingut, puhverdamist ja säutsude otsimist (mõne boonusülesande korral võib veel selline teenus lisanduda). Kui programm tahab asukoha informatsiooni saada, pöördub see vastava teenuse poole, mis tegeleb konkreetselt sedatüüpi probleemidega.

Miks need teenused peavad selliselt eraldi olema? Kas need võiksid ka TwitterApplication'i sees meetoditena olla? Põhimõtteliselt küll. Programmis võib olla asukohapäringu jaoks üks meetod, puhverdamiseks eraldi meetodid jne. Me võime täpselt sama funktsionaalsuse saavutada. Küsimus on aga testimisest. Meetodi testimine on mõnevõrra keerulisem. Ülal näidatud arhitektuuri korral on võimalik testida igat teenust eraldi. Samuti on testimise ajal võimalik mõni teenus välja vahetada. LocationSearch'i asemele paneb testimootor näiteks FakeLocationSearch'i. Sellega saab testida, kas TwitterApplication'i suhtlemine asukohateenusega on korrektne. Kui meetodi korral saame kontrollida meetodi töötamist, siis väga keeruline on testida meetodi väljakutsumist. Eraldi teenuste (ehk siis eraldi klassid, mis on seotud põhiklassiga) puhul on võimalik testida ka klassidevahelist suhtlust.

Konstruktor

Eraldi tuleb rääkida TwitterApplication konstruktorist (täpsemalt siis klassi, mis implementeerib TwitterApplication'it, konstruktorist). Nimelt tuleb selles valmis teha kõik teenuste objektid. Ehk siis asukohaotsing, säutsude otsing jne. Need tuleb salvestada objekti muutujasse, eelistatul läbi setX meetodi (setLocationSearch jne). Peale instantsieerimise (uue objekti loomise) ei tule midagi rohkem teha. Samuti kõik need teenuste objektid, mida te loote, ei tohiks loomise hetkel mingeid päringuid ega muud tegema hakata.

Kui konstruktoris on objektid loodud, siis hiljem pannakse programm käima run meetodiga. Selline jagamine annab testsüsteemil võimaluse näiteks mõni teenus välja vahetada testteenuse vastu. Samuti saab testsüsteem kontrollida mõnda teie teenust eraldi (kuna nüüd on see objekti küljes). Mõnda konkreetselt teenust saaks eraldi testida ka nii, et testsüsteem teeb uue objekti ja testib seda. Selle puhul on keeruline see, et klassi nimetused pole meil fikseeritud. Seega mugavam on lahendada asi nii, et me saame TwitterApplication.getLocationService() meetodiga juba kätte konkreetse instantsi (ehk meil pole vaja new MyLocationService() konstruktorit välja kutsuda, aga sellegipoolest on mul loodud objekt, mis peaks võimaldama päringuid teha).

Programmi käivitamine

Nagu juttu oli, peate looma TwitterApplication interface'i jaoks klassi, mille konstruktor loob teenuste objektid. Programm ise läheb käima selliselt, et loodud objektil kutsutakse välja meetodit run. run on kirjeldatud TwitterApplicationis ära koos sisuga. Vaikimisi (default) sisu teeb seda, et vastavalt etteantud argumentide kogusele käivitatakse kas runInteractive() või runWithArgs(args). Nende sisu tuleb juba teil ise kirjutada. Põhiosas piisab runWithArgs meetodid kirjeldamisest.

Meetodid ja nende sisu

runWithArgs(String[] args) meetod saab ette käsurea argumendid (peaksid olema muutmata kujul). See meetod peaks kasutama getActionsFromArguments(String[] args) meetodid selleks, et saada tegevuste (Action) nimekiri. Selleks tuleb viimatinimetatud meetodit käivitada, ette antakse jälle argumentide massiv (muutmata kujul args). Sellest, mida getActionsFromArguments meetod teeb, räägime allpool. runWithArgs meetodis, kus saime kätte tegevuste nimekirja, peaksime need tegevused nüüd käivitama. Selleks peaks kasutama meetodit executeActions(List<Action> actions), mis paneb tegelikult käsud käima. Sellega runWithArgs sisu ka lõppeb. Küll tasub täiendada sisendikontrolli jms.

getActionsFromArguments(String[] args) meetod saab ette käsurea argumendid ja peab neist tekitama nimekirja (List) tegevustest (Action). Seda infot te enam kuhu edasi ei saada - kogu loogika panete siia. Soovitatavalt tuleb siis kõik elemendid saadud args massiivis läbi käia ja vastavalt sisule teha erinevad Action alamobjektid. Iga alamobjekt tuleb lisada tegevuste listi, mis hiljem tagastatakse selle meetodi poolt. Võib juhtuda, et teil argumentidest on välja lugeda vaid üks tegevus. Ka sellisel juhul peate tegema listi, kuhu panete selle ühe elemendi. Veel märkuseks, et põhiosas teil pole eraldi print tegevust (nagu interaktiivses on). Te võite sellegipoolest kõige lihtsama päringu (ainult piirkonna otsin)jagada: query ja print tegevusteks. Muul juhul tehke lihtsalt query tegevus. Hiljem peate sellega arvestama ExecuteAction meetodis. Lisaks peaks tulemuse salvestama meetodiga setTweets, mis võtab ette nimekirja Tweet objektidest. See tuleks ka kindlasti põhiosas (ja ka teistes) ära teha, kuna sedasi on meil mugavam testida, mis tulemused te saite. Kui prindite lihtsalt välja, siis meil selle väljundi testimine on oluliselt ebatäpsem (kuna võite väga erinevalt väljaprinte teha).

executeActions(List<Ation> actions) on määratud sisuga meetod. See käib läbi kõik etteantud tegevused ja iga tegevuse kohta käivitab executeAction meetodi.

executeAction(Action action) võtab ühe tegevuse (action parameeter) ja teeb ära vastava tegevuse. Näiteks tuleb QueryAction tüüpi tegevus, siis otsite asukohta, (võib-olla kasutate cache'i), tehakse vastavalt piirkonnale twitteri päringu ja vastavalt vajadusele prinditakse kõik välja. Igat tüüpi tegevuse käivitamine toimub erinevalt.

Action.execute() - Action interface kirjeldab ära ühe tühja meetodi, mida võite kasutada selleks, et konkreetne action käivitada. Seega teil on valida, kas kirjutada QueryAction'i tegevus iga erinevat tüüpi objekti juurde või executeAction meetodisse, nagu eelnevas lõigus oli juttu.

Lisaks on vaja get ja set meetodid ära implementeerida. Need teevadki vaid seda, et salvestavad mingi väärtuse kohaliku objekti muutujasse ja vastupidi tagastavad objekti küljes oleva muutuja väärtuse.

Loogika põhiosa lahendamiseks:

1. Loo klass, mis implementeerib TwitterApplication'it.
2. Tee sinna sisse static main, mille sisu on:

   TwitterApplication t = new [siia sinu loodud klassi nimi]();

   t.run(args); <- main meetodisse antav String-massiiv

3. Loo klassid, mis implementeerivad järgmisi interface'e: LocationSearch, TwitterSearch, TwitterQuery, QueryAction, Tweet.
4. Sinu TwitterApplication (edaspidi nimetan klasse, mis implementeerivad mingit interface'i X järgmiselt: Sinu X) klassi konstruktoris loo uus instants Sinu LocationSearch klassist ja Sinu TwitterSearch klassist. Need tuleb ära salvestada Sinu TwitterApplicationi külge vastavalt setLocationSearch ja setTwitterSearch meetoditega.
5. Sinu TwitterApplication'is meetodisse runWithArgs kirjuta umbes selline kood:

   List<Action> actions = getActionsFromArguments(args);

   executeActions(actions);

6. Sinu TwitterApplication'is meetodisse getActionsFromArguments peaks minema käsurea argumentide töötlemine. Töötlemise tulemusel peaks tekkime nimekiri Action-tüüpi objektidest. Põhiosas on ainuke action QueryAction. Seega, kui päring on korrektne, loo uus instants Sinu QueryAction klassist ja pane see List'i. Selle listi tagastadki. Arvesta, et QueryAction'ile tuleb külge anda ka parameetrid (linn ja säutsude kogus).
7. Sinu TwitterApplication'is meetodisse executeAction (ainsuses) peaks minema kood, mis oskab etteantud action'it käivitada. See, kuidas sa selle lahendad, on sinu otsustada. Aga üldiselt võiks olla nii, et tingimuse

   if (action instanceof QueryAction)

   korral tehakse umbes järgmised sammud

   Sinu TwitterQuery twitterQuery = getLocationSearch().getQueryFromLocation([location action'i küljest]);

   List<Sinu Tweet> tweets = getTwitterSearch().getTweets(twitterQuery);