Objective-C -ohjelmointikielestä

Vuosia sitten keskustelin itseäni fiksumman ohjelmistokehittäjän kanssa. No, siihen ei nyt paljon vaadita, mutta hän oli kauhistunut parista Objective-C -kielen ominaisuudesta. Olen kiinnostunut ohjelmointikielistä ja niiden ”maailmankuvasta”, joten otin asiasta selvää.

Ensimmäinen ominaisuus on inject eli olioluokan ajonaikainen laajentaminen. Objective-C käyttää dynaamista sidontaa, joka mahdollistaa metodien tai Objective-C:n tapauksessa viestienkäsittelimien (eng. message handler) – Objective-C:ssä ei ole metodeita – lisäämisen luokkaan ajonaikana, mikä minusta kuulostaa kovasti prototyyppiohjelmoinnilta. Kategorioiden (oma käännös, eng. category) avulla loogisesti yhteenkuuluvat käsittelimet voidaan ryhmittää yhteen, samaan tiedostoon. Katso Wikipedian esimerkkiä), jossa luokkaan lisätään kaksi kategoriaa. Jos kategorian avulla lisätyllä viestinkäsittelimellä on sama allekirjoitus kuin jollain aikaisemmalla, lisätty käsittelin korvaa aiemman. Minulle jäi epäselväksi, missä kategoriat määrittellään: alkuperäisessä luokassa vai laajentavan sovelluksen luokassa. Olettaisin, että jälkimmäisessä, koska muuten alkuperäinen luokka voidaan lukita, jolloin koko laajentaminen menettää merkityksensä. Koska käsittelimien korvaaminen toisilla muodostaa erittäin suuren turvariskin, oletan, että kategorian vaikutusalue rajoittuu laajentavaan sovellukseen, vaikkei Wikipedian artikkeli tätä mainitsekaan.

Toinen kauhistuttanut seikka oli poseeraminen (oma käännös, eng. posing), millä tarkoitetaan, että luokka ottaa toisen luokan paikan sovelluksessa. Tällöin poseerava luokka vastaa kaikkiin alkuperäiselle luokalle lähetettyihin viesteihin. Artikkelissa lueteltiin poseeramisen rajoitukset, jotka mielestäni tekevät poseeraamisesta turvallisen.

Ymmärsin kategorian avulla korvaamisen ja poseeramisen eron olevan, että kategorian avulla voi korvata vain viestienkäsittelimiä, ei ominaisuuksia, s.o. dataa, kun taas poseeraamalla kaikki on vaihdettavissa.

Huomaa, että Objective-C:ssä dynaaminen sidonta on toteutettu niin, että olion on käsiteltävä viesti, delegoitava se, s.o. lähetettävä edelleen tai käsiteltävä virhe. Muutoin syntyy ajonaikainen virhe. Tämä hieman hämmensi minua, sillä olen ymmärtänyt viestien välityksen niin, että viestin lähettänyt olio vastaa jatkotoimista ts. se päättää, onko syntynyt virhetilanne, jos viestin vastaanottanut olio ei kuittaa sitä käsitellyksi. Erityisen tärkeää tämä on silloin, kun käytetään yleislevitystä (eng. broadcasting). Toinen minua hämmentänyt seikka oli nimittäin, että artikkelissa selitettiin viestien delegoimista seikkaperäisesti, muttei maininnut sanallakaan yleislevitystä. Ilmeisesti se puuttuu Objective-C:stä, mikä herättää kysymyksen, miten sitten MVC-arkkitehtuuri toteutetaan. Täytyykö Objective-C:ssä rekisteröidä näkymät malliin kuten Javassa?