AOP vs aðgerðir

Aspekt-stilla forritun (AOP) er nokkuð vinsæl. Hvatning fyrir það er vel útskýrt í samsvarandi Wikipedia grein.

AOP er frábært tæki fyrir sannarlega alþjóðlegar hugtök eins og skógarhögg sem hafa ekki bein áhrif á rökfræði kóðans. Vandamál með AOP birtast hins vegar þegar það er notað fyrir fleiri viðskiptatengda hluti eins og heimild. Þessir þættir forritsins verða að vera vel sýnilegir í viðkomandi kóða svo að verktaki geti strax séð hvort þeim er útfært á réttan hátt við lestur samsvarandi frumkóða. Rammar sem byggjast á AOP leysa venjulega fyrir það með því að nota umsagnaraðferðir:

@RequireRole (Role.Admin) // greinilega sýnilegur þáttur
skemmtileg uppfærslaUserPermissions (…) {
    // rökfræði hér
}

Hins vegar, frá læsileika sjónarmiði, það er ekki mikið frábrugðið hagnýtur nálgun við sama vandamál með því að nota requiredRole aðgerð í stað @ RequireRole umsagnar:

skemmtileg uppfærslaUserPermissions (…) {
    demandRole (Role.Admin) // kastar SecurityException
    // rökfræði hér
}

Ennfremur hefur hagnýtur nálgunin þann kost að hún jafnast einnig upp í flóknari leyfisprófanir, eins og að greina aðferðareiningar áður en ákveðið er hvaða hlutverk notanda er krafist.

Sama er að segja um aðra þætti eins og viðskipti. Því miður er það fyrirferðarmikið og óþægilegt að tákna virkari flóknari hugtök í Java, sem skapar tilbúnar vinsældir fyrir AOP ramma í vistkerfi Java.

Það er þó ekki raunin með Kotlin. Í Kotlin, í stað Java-líknar við viðskipti með AOP og athugasemdir eins og þessa:

@ Transaction
skemmtileg uppfærslaUserPermissions (…) {
    // rökfræði hér
}

Það er jafn læsilegt og hreint útlit þegar það er endurskrifað á virkan hátt:

skemmtileg uppfærslaUserPermissions (…) = viðskipti {
    // rökfræði hér
}

Kosturinn við þessa hagnýtu nálgun er að þú getur alltaf Ctrl / Cmd + Smelltu á yfirlýsinguna um aðgerðaaðgerðina í IDE þínum og séð strax hvað það gerir nákvæmlega, sem er venjulega ekki mögulegt með neinu af AOP ramma sem oft eru notuð. Jafnvel þegar flakkað er að frumkóða þáttarins er til staðar af IDE viðbót, krefst það að skilja rökfræði þess þekkingu á sérstöku ríku API og / eða samningum.

Því miður er þessi hagnýta skipti fyrir AOP sem byggir á athugasemdum í Kotlin ekki strax að málinu þegar mörgum þáttum er beitt í sömu aðgerð og hrokkið axlabönd og inndráttur byrjar að hrannast upp:

skemmtileg uppfærslaUserPermissions (…) = innskráður {
    viðskipti {
        // rökfræði hér
    }
}

Vinnan er að búa til sameina hærri röð aðgerða til að halda notkunarsíðu margvíslegra þátta hreint útlit:

skemmtileg uppfærslaUserPermissions (…) = logTransactionional {
    // rökfræði hér
}

Annar ókostur við hagnýta nálgun er að þættir eins og skógarhögg þurfa aðgang að aðferðareiningum. Þeir eru venjulega fáanlegir í hefðbundnum AOP ramma með sérstökum API, en hlutirnir Kotlin virka hafa ekki greiðan aðgang að þeim. Svo til að raunverulega tákna raunverulegan skógarhöggsþátt á eingöngu hagnýtan hátt, verður maður samt að skrifa talsvert magn af ketilsplötukóða:

skemmtileg uppfærslaUserPermissions (params: Params) =
    skráður ("updateUserPermissions ($ params)") {
        // rökfræði hér
    }

Þetta tillit gerir AOP enn að vali tólar til skógarhöggs þegar þú þarft virkilega að hafa það á heimsvísu og stöðugt í umsókn þinni, en ég tel að notkun AOP fyrir þætti eins og heimild og viðskipti sé misnotkun miðað við ríkar hagnýtar ágrip sem eru fáanlegar í Kotlin . Aðgerðir takast á við þessa þætti betur og hreinni.

Til að draga þá ályktun myndi ég segja að frekari endurbætur á starfsháttum ágrips til að bjóða upp á enn betra skipti fyrir AOP gætu verið efnilegur vektor framtíðarþróunar fyrir Kotlin tungumál. Java-undirstaða AOP rammar eru venjulega JVM-sértækir og eru litnir sem einhver ógegnsæ töfrar, meðan Kotlin hagnýtur ágrip er í raun þverpallur og er gagnsær fyrir notandann.