interfacet

Interfacet - niitä moni ainakin yrittää tarjota ratkaisuksi - ja joihinkin asioihin ne sopivatkin, omasta tapauksestani en ole ihan vakuuttunut.

Eli siis...

Tarkoituksenani on koodata luokkakirjasto http -yhteyksien käsittelyyn, ja säikeessä tehtynä, jotta ohjelman käyttöliittymä ei jumiudu jos lataus netistä hidastelee.

Mutta: haluan http -lataajaluokkani toimivan sekä j2se että j2me -ympäristössä.

Valitettavasti http:n toteutus j2me:ssä ja j2se:ssä on erilainen. Oman luokkani tulisi siis toimia silti oikein molemmissa.

Helpoin ratkaisu olisi ifdef - mutta sehän Javasta kielenä puuttuu kokonaan, ja NetBeansissä se on vain rajoitetusti, eli omassa tarpeessani käyttökelvoton. Netbeansissähän siis VOI tehdä näin:

//#ifdef Nokia

//#endif

//#ifdef SonyEricsson

//#endif

//#ifdef Samsung

//#endif

mutta valitettavasti EI voi tehdä näin:

//#ifdef j2me

//#endif


//#ifdef j2se

//#endif


Tuohon on ehdotettu ratkaisuksi interfaceja.

Eli niin, että teen 2 minimaalista luokkaa, jotka toinen hoitaa matalan tason funktiokutsut http -yhteyden käsittelemiseksij2me -ympäristössä, toinen taas j2se -ympäristössä, ja molemmat toteuttaisivat saman interfacen, jotta voin sitten pääohjelmasta (joka aina on tehty vain joko j2me tai j2se -ympäristöön, eikä sen tarvitse olla siirrettävänäiden välillä) käsin luoda ilmentymän jommastakummasta näistä 2 luokasta, ja sitten välittääsen interfacena varsinaiselle http -työluokalle, joka tekee varsinaisen työn, nuo 2 apuluokkaa siis vain pyrkii yhtenäistämään http -toteutuksen j2me:n ja j2se:n välillä.

itse en ole tuosta täysin vakuuttunut, ja tulipa mieleen kokeilla muita keinoja. Koska ajan NetBeansiä linuxissa, voin toki hyödyntää linuxin "tiedostolinkki" -käsitettä:

ln -s todellinentiedosto luotavanLinkinNimi

Yritin tuota jo hakemistotasolla mutta se johti vain ongelmiin.

Sensijaan en ainakaan heti keksi, miksei sama idea toimisi, jos poistan tekemäni hakemistolinkit, koska ne eivät toimi halutulla tavalla (Vika on siis NetBeansin, ei linuxin), ja korvaan ne tiedostotason linkeillä.

Linkkejä tulee näin enemmän, mutta ainakin pystyn silloin yksityiskohtaisesti hallitsemaan tilanteen.

Ongelmana hakemistotason linkeissä on se, että NetBeans ottaa väkisin java -projektiin mukaan kaikki .java -tiedostot projektin src -hakemistosta JA sen kaikista alihakemistoista, vaikka joihinkin tiedostoihin ei olisi mitään import -määrettä !

Kuten todettua, itse ei huvittaisi lähteä interfaceilla ihan muuten vaan, vaan käyttää niitä vain todelliseen tarpeeseen.

Yksi asia, missä interfacet ovat hyviä:

Oletetaanpa, että ollaan koodaamassa automaattista puhelinpalvelujärjestelmää (APJ), tunnetaan myös nimellä IVR (Interactive Voice Response).

Entä, jos halutaan, että sama ohjelmarunko toimii useammalla erilaisella laitteella ?

Windowsissa näitä asioita perinteisesti yritetään ratkoa laiteajureilla, jotta sovellusohjelmissa ei tarvitsisi miettiä eri laitteiden eroja.

Yritys tähän suuntaan on Microsoftin TAPI (Telephony Application Programming Interface).

Valitettavasti TAPI on yksi huonoimmin suunnitelluista ja sekavimmista API:sta mihin olen ikinä törmännyt.

Yksi mahdollisuus onkin käyttää laitevalmistajien omia ajureita JA ohjelmointirajapintoja, ja jättää tuo TAPI kokonaan hyödyntämättä.

Näppärä ratkaisu, jolla vältetään TAPIn sekavuus ja huono suunnittelu.

Mutta: nyt sitten pitää itse ottaa huomioon eri laitteiden erot.

Yksi hyvä vaihtoehto: määritellä itse juuri sellainen Interface kuin haluaa APJ:n laiterajapinnan toteutukseen, ja käyttää ohjelman logiikkapuolella tätä Interfacea.

Sitten täytyy tietenkin kirjoittaa kutakin laitetyyppiä kohden luokka, joka toteuttaa kyseisen interfacen, ja keskusetelee suoraan kyseisen laitteen kanssa.

Itse tosin kirjoittaisin moisen Delphillä, josta myös löytyy Interfacet, ja periytymisen säännötkin ovat samat kuin Javassa:

Kukin luokka voi periytyä vain yhdestä kantaluokasta (=EI C -tyylistä moinperintää, josta on usein enemmän haittaa kuin hyötyä), mutta kukin luokka voi toteuttaa mielivaltaisen määrän interfaceja. Delphissä on myös mahdollisuus delegoida interfacen toteuttaminen toiselle luokalle, Javan osalta en tiedä, onko myös Javassa sama mahdollisuus.

Ainakin Delphi on Javaa joustavampi ohjelmointiväline, Javan rajoitukset näköjään tulevat hyvinkin pian vastaan.

Omana tarkoituksenani onkin käyttää Javaa nimenomaan j2me -ohjelmointiin, sillä kännyköihin ohjelmoitaessa Javalle ei ole vaihtoehtoja.

Sensijaan esim. Windows -sovellusten tekoon Delphi on joustavampi ja tehokkaampi väline kuin java.

Pidän kuitenkin j2se -sovellusta helpommin debugattavana kuin j2me. Ja juuri siksi haluankin rakentaa omat Java -luokkani niin, että ne toimivat molemmissa: silloin voin testata ja debugata ne huolellisesti j2se -sovelluksen osana, ja vasta kun olen havainnut sen virheettömästi toimivaksi, siirtää sen osaksi j2me -sovellusta.

Uskoisin tällaisella strategialla päästävän parempaan ohjelmiston laatuun.

Ite tein joskus oman classloaderin ni siinä tein omille luokille interfacen.
Aikasta harvoin noita tulee käytettyä mut on hyvää tietää et sellanen on olemas jos tarvetta tulee:)

Jos interfacet ei ole tulleet tutuksi Javassa eikä niitä ole joutunut käyttämään niin mielestäni silloin kannattaisi kyllä opetella olio-ohjelmointia, suunnittelumalleja ja muita yleisiä, hyviä ohjelmointikäytäntöjä.