Typealias — یہ کیا ہے، نحو اور Kotlin میں استعمال

Typealias کیا ہے؟

Typealias (قسم کا عرفی نام) ایک اعلان ہے جو موجودہ قسم کے لیے ایک متبادل نام متعارف کراتا ہے۔ نحو: typealias نیا نام = موجودہ قسم۔ اعلان کے بعد، نیا نام وہاں استعمال کیا جا سکتا ہے جہاں موجودہ قسم کی توقع ہو — مرتب کرنے والا انہیں ایک ہی قسم سمجھتا ہے۔ بائٹ کوڈ کی سطح پر، typealias کوئی نشان نہیں چھوڑتا: تمام عرفی نام کی معلومات مرتب وقت پر مٹا دی جاتی ہے۔

Typealias کا بنیادی مقصد کوڈ پڑھنے کی اہلیت کو بہتر بنانا ہے۔ ایک لمبے دستخط fun process(callback: (Result) -> Unit) کے بجائے، آپ typealias Callback = (Result) -> Unit لکھ سکتے ہیں اور Callback کو پیرامیٹر کی قسم کے طور پر استعمال کر سکتے ہیں۔ یہ خاص طور پر مفید ہے جب ایک ہی فعلی قسم کوڈ میں کئی جگہوں پر دہرائی جائے: عرفی نام تعریف کے ایک نقطہ کے طور پر کام کرتا ہے اور قسم کے مقصد کو دستاویز کرتا ہے۔

Typealias ایک نئی قسم نہیں بناتا — یہ صرف ایک مترادف ہے۔ Callback اور (Result) -> Unit قسم کے متغیرات مکمل طور پر قابل تبادلہ ہیں۔ اگر Callback کی توقع رکھنے والے فنکشن میں براہ راست لیمبڈا بھیجا جائے تو مرتب کرنے والا غلطی نہیں دے گا۔ یہ typealias کو inline class (value class) سے ممتاز کرتا ہے، جو مرتب وقت کی جانچ کے ساتھ ایک نیا ریپر قسم بناتا ہے۔ Typealias نام بدلنا ہے، لپیٹنا نہیں۔

فعلی اقسام کے لیے Typealias

Kotlin میں typealias کا سب سے عام استعمال فعلی اقسام کے لیے ہے۔ (Int, String) -> Boolean یا (List) -> Result جیسے لمبے دستخط کوڈ کو پڑھنا مشکل بناتے ہیں۔ Typealias انہیں مختصر معنی خیز ناموں میں بدل دیتا ہے جو فنکشن کے مقصد کو دستاویز کرتے ہیں: typealias Validator = (String) -> Boolean بتاتا ہے کہ یہ ایک سٹرنگ توثیق کنندہ ہے۔

// Without typealias
fun findUsers(
    filter: (List<User>) -> List<User>
): List<User>

// With typealias
typealias UserFilter = (List<User>) -> List<User>

fun findUsers(filter: UserFilter): List<User>

// Usage in class
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

مثال میں، typealias UserFilter پیچیدہ فعلی قسم (List) -> List کو ایک مختصر نام کے پیچھے چھپا دیتا ہے۔ findUsers کا دستخط پڑھنے کے قابل ہو جاتا ہے: “UserFilter قبول کرتا ہے، List لوٹاتا ہے”۔ typealias OnClickListener کوڈ کو ایک انٹرفیس اعلان جیسا بناتا ہے لیکن علیحدہ انٹرفیس یا تجریدی کلاس بنانے کے بوجھ کے بغیر۔ دریں اثنا، لیمبڈا اور گمنام فنکشن معمول کے مطابق کام کرتے رہتے ہیں — typealias کو کال کرنے والے کوڈ میں تبدیلی کی ضرورت نہیں ہوتی۔

جنریکس کے ساتھ Typealias

Typealias عمومی پیرامیٹرز (جنریکس) کو سپورٹ کرتا ہے، جو اسے مزید لچکدار بناتا ہے۔ آپ typealias Mapper = (T) -> R کی وضاحت کر سکتے ہیں اور اسے کسی بھی قسم کے ساتھ استعمال کر سکتے ہیں۔ مرتب کرنے والا عرفی نام کے ہر استعمال پر پیرامیٹرز کی جگہ مخصوص اقسام رکھتا ہے، مکمل قسم کی حفاظت برقرار رکھتا ہے۔

// Generic typealias
typealias Mapper<T, R> = (T) -> R
typealias Provider<T> = () -> T
typealias ListTransformer<T> = (List<T>) -> List<T>

fun processNumbers(mapper: Mapper<Int, String>) {
    // mapper type is (Int) -> String
}

fun main() {
    val config: Provider<String> = { "default config" }
    val reverse: ListTransformer<Int> = { it.reversed() }
}

فہرست میں، Mapper T سے R میں کسی بھی تبدیلی کے لیے ایک عمومی عرفی نام ہے۔ Provider ایک قدر فراہم کنندہ ہے (بغیر دلائل کے ایک فیکٹری)۔ ListTransformer ایک فہرست تبدیلی کا فنکشن ہے۔ processNumbers(mapper: Mapper) کال کرتے وقت، مرتب کرنے والا عرفی نام کو (Int) -> String میں پھیلا دیتا ہے۔ جنریکس typealias کو ایک عالمگیر آلہ بناتے ہیں جو اعلانات کو نقل کیے بغیر کسی بھی سیاق و سباق کے لیے موزوں ہے۔

نیسٹڈ اور لمبے ناموں کے لیے Typealias

نیسٹڈ کلاسز اور لمبی پیرامیٹرائزڈ اقسام ایک اور شعبہ ہے جہاں typealias کوڈ کو نمایاں طور پر آسان بناتا ہے۔ اگر کوئی کلاس نیسٹنگ درجہ بندی (Outer.Inner.Nested) میں گہری ہو تو، پورے نام سے حوالہ دینا کوڈ کو بے ترتیب کر دیتا ہے۔ Typealias اس طرح کی رسائی کو مختصر کرتا ہے اور اسے مزید پڑھنے کے قابل بناتا ہے۔ یہ خاص طور پر لمبے ناموں والی تیسرے فریق کی لائبریریوں کی کلاسز کے لیے متعلقہ ہے۔

// Alias for nested class
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias for long library type
typealias UserId = Long
typealias JsonMap = Map<String, Any?>

fun process(error: NetworkError) {
    println("${error.code}: ${error.message}")
}

fun parseJson(data: JsonMap): UserId {
    return data["id"] as? Long ?: 0L
}

مثال میں، NetworkError نیسٹڈ کلاس NetworkResponse.Error کا عرفی نام ہے۔ typealias درآمد کرکے، آپ نیسٹنگ درجہ بندی ظاہر کیے بغیر NetworkError کو ایک عام قسم کے طور پر استعمال کر سکتے ہیں۔ JsonMap دستاویز کرتا ہے کہ نقشہ ایک JSON آبجیکٹ کی نمائندگی کرتا ہے۔ UserId ایک مخصوص سیاق و سباق میں Long کے مقصد کو واضح کرتا ہے — قاری فوری طور پر سمجھ جاتا ہے کہ یہ ایک صارف شناخت کنندہ ہے، نہ کہ کوئی صوابدیدی عدد۔ تاہم، typealias اس جگہ پر ایک سادہ Long بھیجنے سے نہیں روکتا جہاں UserId کی توقع ہو — اس کے لیے value class کی ضرورت ہے۔

Typealias بمقابلہ Inline Class: فرق

Typealias اور inline class (value class) مختلف مسائل حل کرتے ہیں، اگرچہ دونوں ایک قسم کے لیے ایک نیا نام متعارف کراتے ہیں۔ Typealias صرف ایک مترادف ہے: UserId = Long قسم کا ایک متغیر بغیر جانچ کے کسی بھی Long کو قبول کرتا ہے۔ Inline class ایک قدر کو ایک نئی قسم میں لپیٹتا ہے جسے مرتب وقت پر جانچا جاتا ہے: جہاں inline class UserId کی توقع ہو وہاں واضح تبدیلی کے بغیر ایک سادہ Long بھیجنا ناممکن ہے۔

جدول دونوں میکانزم کے درمیان فرق ظاہر کرتا ہے۔ Typealias مختصر ناموں اور کوڈ دستاویز کاری کے لیے موزوں ہے جب سخت ٹائپنگ کی ضرورت نہ ہو۔ value class کلیدی لفظ (پہلے inline class) کے ذریعے Inline class کی ضرورت ہوتی ہے جب ایک ہی ابتدائی قسم کی معنوی طور پر مختلف قدروں میں فرق کرنا اہم ہو۔ مثال کے طور پر، UserId اور OrderId دونوں Long ہیں، لیکن جہاں دوسرے کی توقع ہو وہاں ایک کو بھیجنا ایک منطقی غلطی ہے جسے value class مرتب وقت پر روکتا ہے۔