Aiemman blogikirjoituksen kommenteissa on käyty kiihkeää keskustelua, joka on kilpistynyt osittain siihen, onko staattisesta tyypityksestä haittaa koodaamisessa vai ei. Apo argumentoi eräänä vaihtoehtona, että tekemällä oman DOM-APIa muistuttavan rajapinnan voidaan ohittaa tiettyjä staattisen tyypityksen ongelmia.
Vedän tähän kuitenkin yhteen syitä, miksi ohjelmointikielen natiivit, dynaamiset datatyypit ovat parempia kuin omatekoinen DOM-malli. Käytän esimerkkinä alkuperäistä caseani eli tekstimuotoisten JSON-objektien muuntamista ohjelmallisesti käsiteltävään muotoon ja takaisin tekstimuotoon. Samalla kuitenkin tarkastelen ongelmaa yleisessä tapauksessa, eli muutenkin kuin pelkkien JSON-objektien käsittelyssä.
1. Yhtenäisyyden puute
Oman rajapinnan tekeminen JSON-objektien käsittelyyn tarkoittaa, että jokaisen ohjelmakoodiin koskevan pitää opiskella kyseinen proprietaarinen rajapinta. Rajapinta täytyy myös erikseen lisätä jokaiseen projektiin, joka käsittelee JSON-objekteja.
Hyvässä tapauksessa ohjelmointikielelle löytyy valmis kirjasto yksittäiseen asiaan (kuten JSONin käsittelyyn), mutta sekään ei ratkaise ongelmaa yleisessä tapauksessa. Jokainen case vaatii oman kirjastonsa ja oman APInsa, joilla staattisen tyypityksen rajoituksia kierretään tapauskohtaisesti.
Esimerkiksi Javassa JSON-objekteja käsitellään yhdellä tavalla, JDBC-datarivejä toisella tavalla, ja niin edelleen. Dynaamisesti tyypitetyissä kielissä näitä eri API-rajapintoja ei tarvitse keksiä jokaiseen tarkoitukseen uudelleen, vaan kieli itsessään taipuu minkä tahansa datan mallintamiseen ja tarjoaa sen "yhden oikean tavan". Silloin ohjelmoinnissa tarvitaan vähemmän luokkia, vähemmän koodia ja vähemmän opiskelua.
2. Käytön helppous ja luontevuus
Vahvasti JSON-rakenteisiin nojaavan sovelluksen pitää voida käsitellä dataobjekteja läpinäkyvästi. Ohjelmoijaa ei pidä vaivata sillä, onko dataobjekti peräisin ajaxilla lähetetystä JSON-stringistä vai onko se luotu paikallisesti ohjelmointikielen omalla syntaksilla. Muunnokset tehdään verkkorajapinnoissa, kun tekstimuotoista dataa luetaan tai lähetetään, mutta muuten dataobjektien pitää toimia ohjelmointikielelle luonnollisella tavalla.
Anti-esimerkiksi sopii JSONObject. Se enkapsuloi JSON-objektin sisältämät kentät siten, että ohjelmoijan pitää joka kerta kutsua getDouble()-, getInt()-, getString()-, getJSONArray()-, getJSONObject()- jne. metodeja datatyypistä riippuen. Käytännössä siis muuttujat joudutaan joka kerta typecastaamaan. Tämä ei ole yhtä läpinäkyvää ja luontevaa, kuin tavallisten muuttujien käyttäminen.
3. Suorituskyky
Jos JSON-objekteja käsitellään DOM-tyyppisillä enkapsuloivilla rajapinnoilla, täytyy miettiä myös suorituskykyä. Mikäli oletetaan, että lähes kaikki sovelluksen käsittelemä data muodostuu dataobjekteista, niin käsittelyrajapinnan suorituskyky on suorastaan kriittistä. Esimerkiksi Apon ehdottaman XPath-tyyppisen merkkijonon parsiminen ja evaluoiminen jokaisen property-viittauksen kohdalla ei voi mitenkään vastata natiivin dictionary/HashMap-datatyypin suorituskykyä. Olen melko varma, että mikä tahansa suorituskykyinen rajapinta päätyy natiivien container-luokkien käyttöön ja typecastaukseen.
PS. Suuret kiitokset aiemmille kommentoijille pitkästä ja mielenkiintoisesta keskustelusta. Välillä väittely käy kuumana, mutta varmaan lopputuloksena kukin osapuoli saa hiukan ajattelemisen aihetta omaan näkökulmaansa. Ja eihän kukaan voisikaan olla oikea softa-arkkitehti, ellei uskoisi omien näkemyksien ja ratkaisujen olevan juuri niitä oikeita. :-)