Unowned Reference: এটি কী, সিনট্যাক্স এবং মোবাইল অ্যাপ্লিকেশনে ব্যবহার

Unowned Reference কী?

Unowned Reference ARC-তে একটি অবজেক্টের অ-মালিকানাধীন রেফারেন্স যা তার retain count বাড়ায় না। weak-এর বিপরীতে, unowned রেফারেন্স অবজেক্টের ডিলোকেশনের পরে শূন্যায়িত হয় না: এটি সেই মেমরির দিকে নির্দেশ করতে থাকে যা ইতিমধ্যে মুক্ত হয়ে গেছে। এই ধরনের রেফারেন্সে অ্যাক্সেস EXC_BAD_ACCESS সহ রানটাইম ক্র্যাশ ঘটায়।

“অমালিকানাধীন” শব্দটি শব্দার্থ প্রতিফলিত করে: অবজেক্টটি বিদ্যমান, কিন্তু কেউ তার লাইফটাইমের জন্য দায়ী নয়। ডেভেলপার স্পষ্টভাবে ঘোষণা করে: “আমি গ্যারান্টি দিচ্ছি যে এই অবজেক্টটি ততক্ষণ বেঁচে থাকবে যতক্ষণ আমি এটিকে রেফারেন্স করি।” কম্পাইলার এই গ্যারান্টি যাচাই করে না — এটি ডেভেলপার স্তরে একটি চুক্তি।

Swift.org Documentation, 2026-এর মতে, গ্যারান্টিযুক্ত লাইফটাইমযুক্ত পরিস্থিতিতে unowned রেফারেন্স weak-এর চেয়ে পছন্দনীয় কারণ সেগুলি: ঐচ্ছিক টাইপের প্রয়োজন হয় না (পরিষ্কার কোড), unwrap-এর প্রয়োজন হয় না (কম force-unwrap বা guard let), এবং শূন্যায়ন weak টেবিল রক্ষণাবেক্ষণের কোনো ওভারহেড নেই। তবে, চুক্তির কোনো লঙ্ঘন ক্র্যাশে পরিণত হয়।

Swift-এ unowned সিনট্যাক্স

Swift-এ, unowned রেফারেন্স let বা var-এর আগে কীওয়ার্ড unowned দিয়ে ঘোষণা করা হয়। weak-এর বিপরীতে, unowned let এবং var উভয়ই হতে পারে এবং ঐচ্ছিক টাইপের প্রয়োজন হয় না। এই বৈশিষ্ট্য unowned-কে সেই রেফারেন্সগুলির জন্য সুবিধাজনক করে তোলে যা ডোমেন লজিক দ্বারা nil হতে পারে না।

class Country {
    let name: String
    var capital: City!           // ইনিশিয়ালাইজেশনের পরে সেট করা হবে
    init(name: String) { self.name = name }
}

class City {
    let name: String
    unowned let country: Country   // ✅ unowned let — লাইফটাইম গ্যারান্টি

    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

// ব্যবহার
let france = Country(name: "France")
let paris = City(name: "Paris", country: france)
france.capital = paris
// ✅ Country → City (strong), City → Country (unowned) — কোনো retain cycle নেই

এই উদাহরণে, City unowned let country — একটি শহর দেশ ছাড়া থাকতে পারে না। যদি দেশটি অদৃশ্য হয়ে যায়, শহর (এবং রেফারেন্স) তাদের অর্থ হারায়। শব্দার্থগতভাবে, এটি unowned-এর জন্য একটি আদর্শ ক্ষেত্র: লাইফটাইম গ্যারান্টি বিদ্যমান, ঐচ্ছিক প্রয়োজন নেই, retain cycle তৈরি হয় না।

unowned var

unowned var অনুমোদিত কিন্তু কম সাধারণ। এটি ব্যবহার করা হয় যখন রেফারেন্স প্রতিস্থাপন করা যেতে পারে (উদাহরণস্বরূপ, একটি শিশুকে ভিন্ন পিতামাতার সাথে পুনরায় বাঁধাই)। পুনঃনির্ধারণের সময়, পুরানো অবজেক্টের ডিলোকেশন বাহ্যিক মালিকের দায়িত্ব।

Unowned Optional

Swift 5.0+-এ, unowned ঐচ্ছিক (unowned let x: Type?)-এর জন্য সমর্থন চালু করা হয়েছে। এটি একটি সমঝোতা: unowned গ্যারান্টি দেয় যে যদি রেফারেন্স nil না হয়, তাহলে অবজেক্টটি জীবিত। ডিলোকেশনের সময় আচরণ ক্র্যাশ, যেমন সাধারণ unowned-এর ক্ষেত্রে।

Unowned vs Weak: কখন কী ব্যবহার করবেন

unowned এবং weak-এর মধ্যে পছন্দ Swift আর্কিটেকচার ডিজাইন করার সময় ঘন ঘন সিদ্ধান্তগুলির মধ্যে একটি। আসুন প্রতিটি ক্ষেত্রের মানদণ্ড এবং সুপারিশ পরীক্ষা করি।

ব্যবহারিক নিয়ম

weak ব্যবহার করুন যদি অবজেক্টের লাইফটাইম সম্পর্কে সামান্যতম সন্দেহ থাকে। Weak নিরাপদ, স্পষ্ট এবং প্রমাণের প্রয়োজন হয় না। unowned ব্যবহার করুন শুধুমাত্র যখন আপনি সমস্ত পরিস্থিতি বাতিল করতে পারেন যাতে অবজেক্ট আগে মুক্ত হতে পারে। সাধারণ ক্ষেত্র: শিশু যা পিতামাতা ছাড়া বিদ্যমান নয়; ক্লোজার যা সমকালিকভাবে সম্পাদিত হয়; নিজের ইনিশিয়ালাইজারের মধ্যে অবজেক্টে অ্যাক্সেস।

Airbnb Swift Style Guide, 2025-এর মতে, বড় কোডবেসে ডিফল্টরূপে weak ব্যবহার করার এবং শুধুমাত্র লাইফটাইম গ্যারান্টি ব্যাখ্যা করে স্পষ্ট মন্তব্য সহ unowned ব্যবহার করার পরামর্শ দেওয়া হয়। এটি রিফ্যাক্টরিংয়ের সময় অস্পষ্ট ক্র্যাশের ঝুঁকি হ্রাস করে।

ক্লোজারে Unowned self

ক্লোজারগুলি প্যারেন্ট-চাইল্ড সম্পর্কের পরে unowned-এর দ্বিতীয় সবচেয়ে ঘন ঘন ব্যবহারের ক্ষেত্র। ক্যাপচার লিস্ট [unowned self] ব্যবহার করা হয় যখন গ্যারান্টি থাকে যে self ক্লোজারের চেয়ে বেশি দিন বেঁচে থাকে। আসুন সঠিক এবং ভুল পরিস্থিতি পরীক্ষা করি।

কখন unowned self নিরাপদ

সমকালিক ক্লোজার — sorted, filter, map। সেগুলি বর্তমান থ্রেডে অবিলম্বে সম্পাদিত হয়, self নিশ্চিতভাবে জীবিত। unowned সহ ক্যাপচার লিস্ট এখানে গ্রহণযোগ্য এবং পরিষ্কার কোড দেয়।

class DataProcessor {
    var items: [Int] = [3, 1, 4, 1, 5]

    func processSorted() {
        // ✅ unowned self — sorted সমকালিকভাবে সম্পাদিত হয়, self গ্যারান্টিপূর্ণভাবে জীবিত
        let sorted = items.sorted { [unowned self] a, b in
            return self.customCompare(a, b)
        }
    }

    func customCompare(_ a: Int, _ b: Int) -> Bool { return a < b }
}

কখন unowned self বিপজ্জনক

অসমকালিক ক্লোজার — বিলম্ব, নেটওয়ার্ক অনুরোধ, অ্যানিমেশন সহ। ক্লোজার নির্ধারণ এবং তার সম্পাদনের মধ্যে self মুক্ত হতে পারে। এখানে unowned self ক্র্যাশের দিকে নিয়ে যায়। [weak self] ব্যবহার করুন।

class NetworkLoader {
    func loadData() {
        // ❌ বিপজ্জনক: অসমকালিক ক্লোজারে unowned self
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // ক্র্যাশ যদি self মুক্ত হয়
        }.resume()
    }

    func handleResponse(_ data: Data?) { }

    // ✅ সঠিক: weak self + guard
    func loadDataSafe() {
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            guard let self else { return }
            self.handleResponse(data)
        }.resume()
    }
}

নিয়মটি মনে রাখবেন: unowned self — শুধুমাত্র সমকালিক ক্লোজারের জন্য যা অবিলম্বে সম্পাদিত হয়। অসমকালিক ক্লোজারের জন্য, সর্বদা weak self + guard let ব্যবহার করুন। ব্যতিক্রম: যদি আপনি ক্লোজার সম্পূর্ণ না হওয়া পর্যন্ত স্পষ্টভাবে অবজেক্টের একটি রেফারেন্স ধরে রাখেন (উদাহরণস্বরূপ, অন্য ভেরিয়েবলে একটি শক্তিশালী রেফারেন্স রেখে)।

Unowned-এর ঝুঁকি এবং কীভাবে এড়াবেন

Unowned একটি শক্তিশালী কিন্তু বিপজ্জনক হাতিয়ার। আসুন বাস্তব-বিশ্বের পরিস্থিতি দেখি যেখানে unowned ক্র্যাশের কারণ হতে পারে এবং ঝুঁকি কমানোর পদ্ধতি।

রিফ্যাক্টরিং এবং গ্যারান্টি পরিবর্তন

unowned-এর প্রধান ঝুঁকি হল ব্যবসায়িক লজিকে পরিবর্তন যা লাইফটাইম গ্যারান্টি বাতিল করে। একজন ডেভেলপার কোড রিফ্যাক্টর করে: মালিকানা পরিবর্তন করে, বিলম্বিত মুক্তি প্রবর্তন করে, ক্যাশিং যোগ করে — এবং unowned রেফারেন্সটি একটি টাইম বোমায় পরিণত হয়। কম্পাইলার সতর্ক করবে না — শুধুমাত্র ব্যবহারকারীর ডিভাইসে ক্র্যাশ।

সুপারিশ: unowned ব্যবহার করুন শুধুমাত্র যখন লাইফটাইম গ্যারান্টি স্পষ্ট এবং নথিভুক্ত। প্রতিটি unowned-এর জন্য একটি মন্তব্য যোগ করুন: কেন এই রেফারেন্সটি নিরাপদ এবং কোন পরিস্থিতিতে এটি লঙ্ঘন হতে পারে।

UIKit হায়ারার্কিতে Unowned

UIKit unowned-এর জন্য উচ্চ ঝুঁকিপূর্ণ এলাকা। নেভিগেশন (pop, dismiss), মেমরি আনলোডিং, বা ওরিয়েন্টেশন পরিবর্তনের সময় যেকোনো মুহূর্তে ViewController মুক্ত হতে পারে। যদি আপনি unowned self সহ ক্লোজারে ViewController পাস করেন, তাহলে ব্যাকগ্রাউন্ড থেকে ফিরে আসার সময় বা অ্যানিমেশন সম্পূর্ণ হওয়ার সময় self nil হতে পারে।

সেরা অনুশীলন

unowned ব্যবহার করার সময় ঝুঁকি কমাতে, এই নিয়মগুলি অনুসরণ করুন:

• ডিফল্টরূপে weak পছন্দ করুন — weak নিরাপদ, unowned একটি অপ্টিমাইজেশন, মান নয়
• গ্যারান্টি নথিভুক্ত করুন — প্রতিটি unowned-এর জন্য, যুক্তি সহ মন্তব্য লিখুন
• ViewController-এ unowned এড়িয়ে চলুন — UIKit লাইফসাইকেল unowned গ্যারান্টির জন্য অপ্রত্যাশিত
• শুধুমাত্র সমকালিক ক্লোজারের জন্য unowned ব্যবহার করুন — sorted, filter, map নিরাপদ প্রার্থী
• কোড রিভিউ চলাকালীন পরীক্ষা করুন — প্রতিটি unowned-কে কোড লেখকের কাছ থেকে যুক্তি প্রয়োজন
• সামান্য সন্দেহে weak-এ স্থানান্তর করুন — পঠনযোগ্যতার ক্ষতি (একটি guard let) প্রোডাকশনে ক্র্যাশের চেয়ে কম

// উদাহরণ: স্পষ্ট যুক্তি সহ নথিভুক্ত unowned রেফারেন্স
class InvoiceLineItem {
    let productName: String
    let price: Decimal

    // unowned Invoice — InvoiceLineItem Invoice ছাড়া বিদ্যমান থাকতে পারে না।
    // Invoice Item তৈরি করে এবং এটি মুছে ফেলা হলে সরিয়ে দেয়।
    // গ্যারান্টি: Invoice অন্তত যতক্ষণ বেঁচে থাকে ততক্ষণ Item।
    unowned let invoice: Invoice

    init(productName: String, price: Decimal, invoice: Invoice) {
        self.productName = productName
        self.price = price
        self.invoice = invoice
    }
}

// এটি একটি শক্তিশালী গ্যারান্টি: Invoice deinit-এ সমস্ত Items সরিয়ে দেয়।
// গ্যারান্টি লঙ্ঘন = ব্যবসায়িক লজিকে একটি বাগ যা ঠিক করতে হবে।

গ্যারান্টি নথিভুক্ত করা একটি পেশাদার মান। বড় প্রকল্পে (Airbnb, Uber), কোড রিভিউ প্রতিটি unowned-এর জন্য যুক্তি প্রয়োজন। যদি গ্যারান্টি স্পষ্ট না হয়, weak ব্যবহার করুন। unowned-এ মন্তব্য ভবিষ্যতের ডেভেলপারদের বুঝতে সাহায্য করে কেন এখানে weak ব্যবহার করা হয়নি এবং কোন পরিস্থিতিতে গ্যারান্টি ভেঙে যেতে পারে।