দুর্বল রেফারেন্স এবং অজানা রেফারেন্সের মধ্যে পার্থক্য কী?


240

সুইফট রয়েছে:

  • শক্তিশালী তথ্যসূত্র
  • দুর্বল উল্লেখ
  • অজানা তথ্যসূত্র

কীভাবে অনাবৃত রেফারেন্স দুর্বল রেফারেন্স থেকে আলাদা?

অযাচিত রেফারেন্সটি ব্যবহার করা কখন নিরাপদ?

অজানা রেফারেন্সগুলি কি সি / সি ++ এর পয়েন্টারগুলিতে ঝুঁকির মতো সুরক্ষা ঝুঁকিপূর্ণ ?



আমার অভিজ্ঞতাটি unownedআমরা যে ক্লাসগুলিকে নিয়ন্ত্রণ করি, অ্যাপল ক্লাসগুলির weakজন্য ব্যবহার করি তা ব্যবহার করি কারণ এটি কী করে তা আমরা নিশ্চিতভাবে গ্যারান্টি দিতে পারি না
onmyway133

@ নূরআলি, বা "মালিকানাধীন বাই" "অবিকৃত" রেফারেন্স হিসাবে প্রায়শই মালিককে নির্দেশ করে।
ইয়ান রিংরোজ

উত্তর:


361

উভয় weakএবং unownedরেফারেন্স রেফারেন্সযুক্ত strongবস্তুর উপর একটি হোল্ড তৈরি করে না (ওরফে তারা রেটযুক্ত বস্তুটিকে অবনমিত হতে আটকের জন্য রেন্ট কাউন্ট বাড়ায় না)।

তবে দুটি কীওয়ার্ড কেন? এই পার্থক্যটির সাথে সত্যতা আছে যে Optionalপ্রকারগুলি সুইফট ভাষা অন্তর্নির্মিত। তাদের সম্পর্কে দীর্ঘ গল্প সংক্ষিপ্ত: typesচ্ছিক প্রকারগুলি মেমরির সুরক্ষা সরবরাহ করে (এটি সুইফটের নির্মাতার নিয়মের সাথে সুন্দরভাবে কাজ করে - যা এই সুবিধা দেওয়ার জন্য কঠোর)।

একটি weakরেফারেন্স এটির সম্ভাবনা তৈরি করার অনুমতি দেয় nil(রেফারেন্সযুক্ত অবজেক্টটি বিলোপযুক্ত হয়ে গেলে এটি স্বয়ংক্রিয়ভাবে ঘটে) সুতরাং আপনার সম্পত্তির প্রকারটি অবশ্যই beচ্ছিক হতে হবে - সুতরাং আপনি, প্রোগ্রামার হিসাবে এটি ব্যবহার করার আগে আপনাকে এটি পরীক্ষা করতে বাধ্য (মূলতঃ সংকলক আপনাকে যতটা সম্ভব নিরাপদ কোড লিখতে বাধ্য করে)।

একটি unownedরেফারেন্স অনুমান করে যে এটি কখনই nilতার জীবদ্দশায় পরিণত হবে না । আরম্ভের সময় একটি অচেতন রেফারেন্স সেট করতে হবে - এর অর্থ এই যে রেফারেন্সটি একটি অ-.চ্ছিক প্রকার হিসাবে সংজ্ঞায়িত করা হবে যা চেক ছাড়াই নিরাপদে ব্যবহার করা যেতে পারে। যদি কোনওভাবে অবজেক্টটিকে উল্লেখ করা হচ্ছে তা নির্বিঘ্ন করা হয়, তবে অযৌক্তিক রেফারেন্স ব্যবহার করা হলে অ্যাপটি ক্র্যাশ হয়ে যায়।

থেকে অ্যাপল ডক্স :

যখনই তার রেফারেন্সটি তার জীবদ্দশায় কোনও সময়ে শূন্য হয়ে যায় তখনই এটি দুর্বল রেফারেন্স ব্যবহার করুন। বিপরীতক্রমে, অবিকৃত রেফারেন্সটি ব্যবহার করুন যখন আপনি জানেন যে সূত্রটি আরম্ভের সময় সেট হয়ে গেলে এটি কখনই শূন্য হয় না।

দস্তাবেজগুলিতে কয়েকটি উদাহরণ রয়েছে যা ধরে রাখার চক্র এবং কীভাবে সেগুলি ভাঙতে পারে সে সম্পর্কে আলোচনা করে। এই সমস্ত উদাহরণ ডক্স থেকে নেওয়া হয়েছে

weakকীওয়ার্ডের উদাহরণ :

class Person {
    let name: String
    init(name: String) { self.name = name }
    var apartment: Apartment?
}

class Apartment {
    let number: Int
    init(number: Int) { self.number = number }
    weak var tenant: Person?
}

এবং এখন, কিছু ASCII শিল্পের জন্য (আপনার ডক্সগুলি দেখতে যাওয়া উচিত - তাদের সুন্দর ডায়াগ্রাম রয়েছে):

Person ===(strong)==> Apartment
Person <==(weak)===== Apartment

Personএবং Apartmentউদাহরণস্বরূপ একটি অবস্থা যেখানে দুই বৈশিষ্ট, এই দুই ধরনের শূন্য হতে অনুমোদিত, একটি শক্তিশালী রেফারেন্স চক্র বিকল হওয়ার সম্ভাবনা আছে দেখায়। এই দৃশ্যের একটি দুর্বল রেফারেন্স সহ সেরা সমাধান করা হয়েছে। উভয় সত্তা অন্যের উপর দৃ a় নির্ভরশীলতা ছাড়াই বিদ্যমান থাকতে পারে।

unownedকীওয়ার্ডের উদাহরণ :

class Customer {
    let name: String
    var card: CreditCard?
    init(name: String) { self.name = name }
}

class CreditCard {
    let number: UInt64
    unowned let customer: Customer
    init(number: UInt64, customer: Customer) { self.number = number; self.customer = customer }
}

এই উদাহরণে, Customerমে এর একটি থাকতে পারে বা নাও থাকতে পারে CreditCardতবে একটি এর সাথে CreditCard সর্বদা যুক্ত থাকবেCustomer । এটি উপস্থাপনের জন্য, Customerশ্রেণীর একটি alচ্ছিক সম্পত্তি রয়েছে cardতবে CreditCardশ্রেণীর একটি অ-alচ্ছিক (এবং অবিকৃত) customerসম্পত্তি রয়েছে।

Customer ===(strong)==> CreditCard
Customer <==(unowned)== CreditCard

Customerএবং CreditCardউদাহরণস্বরূপ একটি অবস্থা যেখানে এক সম্পত্তি যে শূন্য হতে অনুমোদিত হবে এবং অন্য সম্পত্তি যে শূন্য হতে পারে না একটি শক্তিশালী রেফারেন্স চক্র বিকল হওয়ার সম্ভাবনা থাকে শো। এই দৃশ্যটি অনাবৃত রেফারেন্স দিয়ে সবচেয়ে ভাল সমাধান করা হয়েছে।

অ্যাপল থেকে নোট:

দুর্বল রেফারেন্সগুলি অবশ্যই ভেরিয়েবল হিসাবে ঘোষণা করতে হবে, ইঙ্গিত করতে যে রানটাইমের সময় তাদের মান পরিবর্তন হতে পারে। একটি দুর্বল রেফারেন্সকে ধ্রুবক হিসাবে ঘোষণা করা যায় না।

তৃতীয় দৃশ্যাবলীও রয়েছে যখন উভয় বৈশিষ্ট্যের সর্বদা একটি মান থাকা উচিত এবং আরম্ভ করার পরে সম্পত্তির কোনওটিই শূন্য করা উচিত নয়।

ক্লোজারগুলির সাথে কাজ করার সময় এড়াতে ক্লাসিক ধরে রাখা চক্রের দৃশ্যও রয়েছে।

এর জন্য, আমি আপনাকে অ্যাপল ডক্স পরিদর্শন করতে , বা বইটি পড়তে উত্সাহিত করছি ।


3
এটি কিছুটা তুচ্ছ কিন্তু আমি অ্যাপার্টমেন্ট এবং ব্যক্তির উদাহরণ কিছুটা বিভ্রান্তিকর খুঁজে পাই যা শক্তিশালী রেফারেন্স চক্রটি ভাঙ্গার জন্য একটি অতিরিক্ত সমাধানও উপস্থাপন করে। কোনও ব্যক্তির অ্যাপার্টমেন্ট alচ্ছিক এবং তাই অ্যাপার্টমেন্টের ভাড়াটে optionচ্ছিক পাশাপাশি শূন্য হতে পারে এবং উভয় সম্পত্তি দুর্বল হিসাবে সংজ্ঞায়িত করা যায় তাই শূন্য হতে পারে। `` `
জাস্টিন লেভি শীতকাল

শ্রেণী ব্যক্তি {লেট নাম: স্ট্রিং init (নাম: স্ট্রিং) {স্ব.নাম = নাম} দুর্বল ভার অ্যাপার্টমেন্ট: অ্যাপার্টমেন্ট? } শ্রেণি অ্যাপার্টমেন্ট {লেট সংখ্যা: আইএনটি ইনম (সংখ্যা: আন্ত) {স্ব.নাম্বার = সংখ্যা} দুর্বল ভার ভাড়াটিয়া: ব্যক্তি? }
জাস্টিন লেভি শীতকাল

3
weak var Person?বনাম মধ্যে পার্থক্য কি var Person??
ডিন

4
@ জাস্টিনলেভি, আপনি যদি উভয় সম্পত্তি দুর্বল হিসাবে ঘোষণা করেন তবে তাদের বিঘ্নিত হওয়ার সম্ভাবনা রয়েছে। ব্যক্তি অ্যাপার্টমেন্টে একটি দৃ reference় রেফারেন্স রাখে যাতে অ্যাপার্টমেন্টটি হ্রাস করা না যায়। যদি অ্যাপার্টমেন্টটিতে ব্যক্তির প্রতি একই শক্তিশালী রেফারেন্স থাকে তবে তারা একটি ধরে রাখার চক্র তৈরি করবে - যা প্রোগ্রামারের দ্বারা রানটাইম দ্বারা ভেঙে যেতে পারে যদি তিনি সে সম্পর্কে জানেন তবে অন্যথায় এটি কেবল একটি স্মৃতি ফাঁস। দৃ strong়, দুর্বল এবং অজানা: এটি একটি উচ্চ স্তরে মেমরি পরিচালনা সম্পর্কে সমস্ত গোলমাল, কারণ এআরসি সমস্ত নোংরা জিনিস আমাদের জন্য করে। রক্ষণ চক্র এড়ানো আমাদের কাজ।
ইলিয়া ক্রিশ্চিয়ান

1
দুর্বলদের উপর অবহেলিত হওয়ার একমাত্র উপকারটি হ'ল আপনার আনপ্রেপ করার দরকার নেই এবং ধ্রুবকটি ব্যবহার করতে পারেন? এমন কোনও উদাহরণ রয়েছে যেখানে আপনি দুর্বল ব্যবহার করতে পারবেন না এবং কেবল অবাঞ্ছিত ব্যবহার করতে পারবেন?
অ্যালান

29

চতুর্থাংশ 1। "দুর্বল রেফারেন্স" কীভাবে একটি "দুর্বল রেফারেন্স" থেকে আলাদা?

দুর্বল রেফারেন্স:

একটি দুর্বল রেফারেন্স হল এমন একটি রেফারেন্স যা উল্লেখ করা নজরে দৃ .়ভাবে ধরে রাখে না এবং তাই এআরসিটিকে রেফারেন্সযুক্ত উদাহরণটি নিষ্পত্তি করা থেকে বিরত রাখে না। দুর্বল রেফারেন্সগুলিতে "কোনও মূল্য নেই" থাকার অনুমতি দেওয়া হওয়ায় আপনাকে অবশ্যই প্রতিটি দুর্বল রেফারেন্সটিকে optionচ্ছিক প্রকার হিসাবে ঘোষণা করতে হবে। (অ্যাপল ডক্স)

অজানা রেফারেন্স:

দুর্বল রেফারেন্সগুলির মতো, অবাঞ্ছিত রেফারেন্সটি যে উদাহরণটিকে নির্দেশ করে তা দৃ a়ভাবে ধরে রাখে না। একটি দুর্বল রেফারেন্সের মতো নয়, তবে একটি অচেতন রেফারেন্স সর্বদা একটি মান বলে ধরে নেওয়া হয়। এই কারণে, একটি অবাঞ্ছিত রেফারেন্স সর্বদা একটি অ-alচ্ছিক প্রকার হিসাবে সংজ্ঞায়িত করা হয়। (অ্যাপল ডক্স)

প্রতিটি কখন ব্যবহার করবেন:

যখনই তার রেফারেন্সটি তার জীবদ্দশায় কোনও সময় শূন্য হওয়ার জন্য এটি বৈধ হয় তখনই দুর্বল রেফারেন্স ব্যবহার করুন। বিপরীতক্রমে, অবিকৃত রেফারেন্সটি ব্যবহার করুন যখন আপনি জানেন যে সূত্রটি আরম্ভের সময় সেট হয়ে গেলে এটি কখনই শূন্য হয় না। (অ্যাপল ডক্স)


Q2 এর। কখন "অবিকৃত রেফারেন্স" ব্যবহার করা নিরাপদ?

উপরে উদ্ধৃত হিসাবে, একটি অবিকৃত রেফারেন্স সর্বদা একটি মান আছে বলে ধরে নেওয়া হয়। সুতরাং আপনার কেবল তখনই এটি ব্যবহার করা উচিত যখন আপনি নিশ্চিত হন যে রেফারেন্সটি কখনই বাতিল হবে না। অ্যাপল ডক্স নিম্নলিখিত উদাহরণের মাধ্যমে অনাবৃত রেফারেন্সগুলির জন্য একটি ব্যবহারের ক্ষেত্রে চিত্রিত করে।

ধরুন আমাদের দুটি ক্লাস আছে Customerএবং CreditCard। ক্রেডিট কার্ড ব্যতীত গ্রাহকের অস্তিত্ব থাকতে পারে তবে গ্রাহক ব্যতীত ক্রেডিট কার্ডের অস্তিত্ব থাকবে না, অর্থাৎ এটি ধরে নেওয়া যায় যে ক্রেডিট কার্ডে সর্বদা গ্রাহক থাকবে। সুতরাং, তাদের নিম্নলিখিত সম্পর্ক থাকা উচিত:

class Customer {
    var card: CreditCard?
}

class CreditCard {
    unowned let customer: Customer
}

চতুর্থাংশ 3। সি / সি ++ এর মধ্যে "ঝুঁকিপূর্ণ পয়েন্টার" এর মতো সুরক্ষা ঝুঁকির বিষয়টি "অবিকৃত রেফারেন্স" রয়েছে reference

আমি তাই মনে করি না.

যেহেতু অযৌক্তিক উল্লেখগুলি কেবল দুর্বল রেফারেন্স যেগুলি একটি মান থাকার গ্যারান্টিযুক্ত, তাই এটি কোনওভাবেই সুরক্ষা ঝুঁকি হওয়া উচিত নয়। যাইহোক, যদি আপনি কোনও অনাবৃত রেফারেন্সটি উল্লেখ করার পরে যে অধ্যায়টি উল্লেখ করার পরে এটি অ্যাক্সেস করার চেষ্টা করেন, আপনি রানটাইম ত্রুটিটি ট্রিগার করবেন এবং অ্যাপটি ক্রাশ হয়ে যাবে।

এটিই আমি এটির সাথে দেখছি risk

অ্যাপল ডক্সের লিঙ্ক


আপনার কিউ 2 উদাহরণস্বরূপ প্রোগ্রাম অজানা ... ধন্যবাদ সম্পর্কে বুঝতে সহজ .. আপনি কি দুর্বল ও শক্তিশালী জন্য একই ধরণের উদাহরণ যুক্ত করতে পারেন ..
রঞ্জিত কুমার ২

চমৎকার। ধন্যবাদ.
সুইফ্টি ম্যাকউইফটার্টন

আপনি অজানা বা দুর্বলদের জন্য একটি সাধারণ উদাহরণ অন্তর্ভুক্ত করতে পারেন?
মধু

পিতা-মাতার এবং সন্তানের অবজেক্টগুলি বিবেচনা করুন, যদি পিতা-মাতা ছাড়া সন্তানের অস্তিত্ব না থাকে তবে unownedশিশু শ্রেণিতে পিতামাতার সম্পত্তি হিসাবে ব্যবহার করুন । দুর্বল vise বিপরীতে। মাইক্রোসটিক সুন্দর ব্যাখ্যা! unownedতথ্যসূত্রগুলি কেবলমাত্র weakরেফারেন্স যা একটি মান থাকার গ্যারান্টিযুক্ত!
সাইফ

26

যদি স্ব অবসান ব্যবহারে শূন্য হতে পারে [দুর্বল স্ব]

যদি স্বাবলম্বন কখনই বন্ধের ব্যবহারে [অচেতন স্ব] নিরস্ত হয় না

আপনি যখন [অচেতন স্ব] ব্যবহার করছেন তখন যদি এটি ক্রাশ হয়ে থাকে তবে স্বভাব সম্ভবত সেই বন্ধের কোনও সময় শূন্য হয় এবং পরিবর্তে আপনার সম্ভবত সম্ভবত [দুর্বল স্ব] ব্যবহার করা প্রয়োজন।

শক্তিশালী , দুর্বল এবং বন্ধ অবস্থায় অবহেলিত ব্যবহারের উদাহরণগুলি দেখুন :

https://developer.apple.com/library/ios/documentation/swift/conceptual/swift_programming_language/AutomaticReferenceCounting.html


7
শুধু দুর্বল ব্যবহার করে কেন নিজের ক্ষতি কখনই শূন্য হতে পারে না, কোনও ক্ষতি সঠিকভাবে করা যায় না কেন?
বুড়ো

4
হাই @ বন - এটি সত্যই সমালোচনামূলক প্রশ্ন।
ফ্যাটি

[দুর্বল স্ব] => যদি আমি ভিউডিডলড () এর অভ্যন্তরে ক্লোজার ব্যবহার করি তবে কীভাবে শুন্য হতে selfপারে?
হাসান তারেক

@ হাসান তারেক, আমি মনে করি উপরে উল্লিখিত নিবন্ধে কয়েকটি ভাল উদাহরণ উল্লেখ করা হয়েছে। "বন্ধের জন্য শক্তিশালী রেফারেন্স চক্রগুলি সমাধান করা" বিভাগটি পরীক্ষা করুন, esp। উদ্ধৃতি: "সুইফ্টের জন্য আপনাকে যখনই কোনও বন্ধের মধ্যে স্ব-সদস্যের কথা উল্লেখ করা হয় তবে কেবলমাত্র কিছু প্রোপার্টি বা কোনও ম্যাসথড () এর চেয়ে স্ব.সোমপ্রোপার্টি বা সেলফসোমথোড () লিখতে হবে This এটি আপনাকে মনে রাখতে সহায়তা করে যে নিজের দ্বারা ক্যাপচার করা সম্ভব দুর্ঘটনা। " এর উত্স: অ্যাপল ইনক। "দ্য সুইফ্ট প্রোগ্রামিং ভাষা (সুইফট 4)" iBooks। itunes.apple.com/de/book/the-swift-programming-language-swift-4/... "
নিক Entin

1
@ বাুন আপনি যদি সর্বদা দুর্বল ব্যবহার করেন তবে সংকলক ব্যবহারের আগে alচ্ছিক জন্য পরীক্ষা করতে বাধ্য করবে। আপনি যদি এই চেকটি না রাখেন তবে এটি সংকলন সময় ত্রুটি দেবে। অন্য কোনও ক্ষতি নেই।
বিকাশ মিশ্র

5

লিঙ্ক থেকে নিষ্কাশন

কয়েকটি সমাপ্তি পয়েন্ট

  • এমনকি আপনার যদি শক্তিশালী, দুর্বল, বা অচেতন সম্পর্কে চিন্তা করা দরকার কিনা তা নির্ধারণ করতে, জিজ্ঞাসা করুন, "আমি কি রেফারেন্সের ধরণগুলি নিয়ে কাজ করছি"। আপনি যদি স্ট্রাক্টস বা এনামসের সাথে কাজ করছেন তবে এআরসি Typ প্রকারের জন্য মেমরি পরিচালনা করছে না এবং সেই ধ্রুবকগুলি বা ভেরিয়েবলগুলির জন্য দুর্বল বা অজানা নির্দিষ্ট করার জন্য আপনাকেও উদ্বিগ্ন হওয়ার দরকার নেই।
  • শ্রেণিবদ্ধ সম্পর্কের ক্ষেত্রে শক্তিশালী উল্লেখগুলি সূক্ষ্ম হয় যেখানে পিতামাতারা সন্তানের উল্লেখ করেন তবে বিপরীত নয়। প্রকৃতপক্ষে, শক্তিশালী রেফারেন্সগুলি বেশিরভাগ সময় সর্বাধিক এপ্রোপ্রেইট ধরণের রেফারেন্স।
  • দুটি উদাহরণ যখন অপরটির সাথে একে অপরের সাথে সম্পর্কিত হয় তখন নিশ্চিত হয়ে নিন যে those দৃষ্টান্তগুলির মধ্যে একটির অন্যটির সাথে দুর্বল উল্লেখ রয়েছে।
  • যখন দুটি দৃষ্টান্ত এমনভাবে সম্পর্কিত হয় যেগুলির একটির অন্যটি ছাড়া অস্তিত্ব থাকতে পারে না, বাধ্যতামূলক নির্ভরতার সাথে উদাহরণটি অন্য উদাহরণের জন্য অজানা রেফারেন্স রাখা দরকার।

1

উভয় weakএবং unownedরেফারেন্স বস্তুর রেফারেন্স গণনা প্রভাবিত করবে না। তবে দুর্বল রেফারেন্স সর্বদা alচ্ছিক হবে অর্থাত্ এটি শূন্য হতে পারে whereasunowned উল্লেখগুলি কখনই শূন্য হতে পারে না তাই তারা কখনই alচ্ছিক হতে পারে না। Anচ্ছিক রেফারেন্স ব্যবহার করার সময় আপনাকে সর্বদা অবজেক্টের শূন্য হওয়ার সম্ভাবনাটি পরিচালনা করতে হবে। অপরিবর্তিত রেফারেন্সের ক্ষেত্রে আপনাকে নিশ্চিত করতে হবে যে বস্তুটি কখনই শূন্য নয়। একটি শূন্য বস্তুর অবাঞ্ছিত রেফারেন্স ব্যবহার করা জোর করে একটি alচ্ছিক অপশারণযোগ্য যা শূন্য হয় similar

এটি বলেছিল যে অবাঞ্ছিত রেফারেন্সটি ব্যবহার করা নিরাপদ যেখানে আপনি নিশ্চিত যে বিষয়টির জীবনকাল রেফারেন্সের চেয়ে বেশি। যদি এটি না হয় তবে তার পরিবর্তে একটি দুর্বল রেফারেন্স ব্যবহার করা ভাল।

প্রশ্নের তৃতীয় অংশ হিসাবে, আমি মনে করি না অজানা রেফারেন্স একটি ঝুঁকির পয়েন্টারের অনুরূপ। যখন আমরা রেফারেন্স গণনা সম্পর্কে কথা বলি, আমরা সাধারণত অবজেক্টের শক্তিশালী রেফারেন্স গণনা উল্লেখ করি। একইভাবে সুইফট অবজেক্টের রেফারেন্স গণনা এবং অবজেক্টের জন্য দুর্বল রেফারেন্স গণনা বজায় রাখে (কোনও বিষয়কে দুর্বল রেফারেন্স পয়েন্ট হিসাবে না বলে "সাইড টেবিল" বলে মনে হয়)। শক্তিশালী রেফারেন্স গণনাটি শূন্যে পৌঁছে গেলে অবজেক্টটি ডিনিটাইয়ালাইজড হয়ে যায়, তবে অবিকৃত রেফারেন্স গণনাটি শূন্যের চেয়ে বেশি হলে এটি বিশিষ্ট হতে পারে না।

এখন একটি ঝুঁকিপূর্ণ পয়েন্টার এমন একটি জিনিস যা ইতিমধ্যে অবমুক্ত করা হয়েছে এমন একটি মেমরির অবস্থানকে নির্দেশ করে। তবে দ্রুতগতিতে যেহেতু মেমরিটি কেবল তখনই অবনমিত হতে পারে যতক্ষণ না কোনও বস্তুর অনাবৃত রেফারেন্স থাকে তাই এটি কোনও ঝুঁকির পয়েন্টার তৈরি করতে পারে না।

আরও অনেক নিবন্ধ রয়েছে যা আরও বিস্তারিতভাবে দ্রুত মেমরি পরিচালনা নিয়ে আলোচনা করে। এখানে একটি।


0

অজানা রেফারেন্সগুলি হ'ল এক ধরণের দুর্বল রেফারেন্স যা দুটি বস্তুর মধ্যে সম-লাইফটাইম সম্পর্কের ক্ষেত্রে ব্যবহৃত হয়, যখন কোনও বস্তু কেবল কখনও অন্য কোনও বস্তুর মালিকানাধীন থাকে। এটি কোনও উপায় এবং এর একটি বৈশিষ্ট্যের মধ্যে একটি অপরিবর্তনীয় বাঁধাই তৈরি করার একটি উপায়।

মধ্যবর্তী সুইফট ডাব্লুডাব্লুডিসি ভিডিওতে প্রদত্ত উদাহরণে, কোনও ব্যক্তির একটি ক্রেডিট কার্ড রয়েছে এবং ক্রেডিট কার্ডের কেবল একটি ধারক থাকতে পারে। ক্রেডিট কার্ডে, ব্যক্তিটি optionচ্ছিক সম্পত্তি হওয়া উচিত নয়, কারণ আপনি কেবল একটি মালিকের সাথে চারপাশে একটি ক্রেডিট কার্ড ভাসতে চান না। আপনি ক্রেডিটে ধারক সম্পত্তিকে একটি দুর্বল রেফারেন্স বানিয়ে এই চক্রটি ভেঙে ফেলতে পারেন, তবে এটির জন্য আপনাকে এটিকে alচ্ছিক পাশাপাশি পরিবর্তনশীলও করতে হবে (ধ্রুবকের বিপরীতে)। এই ক্ষেত্রে অযৌক্তিক রেফারেন্সের অর্থ হ'ল ক্রেডিটকার্ডের কোনও ব্যক্তির নিজস্ব অংশীদারি না থাকলেও এর জীবন নির্ভর করে।

class Person {
    var card: CreditCard?
}

class CreditCard {

    unowned let holder: Person

    init (holder: Person) {
        self.holder = holder
    }
}

ডাব্লুডাব্লুডিসির ভিডিও বা শিরোনামের লিঙ্ক?
ওসায়

-2

unownedআপনি যখন নিশ্চিত হন তখন ব্যবহার করুন selfকখনই nilআপনি অ্যাক্সেস করতে পারবেন নাself যে সময়ে।

উদাহরণ (আপনি অবশ্যই লক্ষ্য সরাসরি যুক্ত করতে পারেন তবে এটি MyViewControllerআবার একটি সাধারণ উদাহরণ): .:

class MyViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        let myButton = MyButton { [unowned self] in
            print("At this point, self can NEVER be nil. You are safe to use unowned.")
            print("This is because myButton can not be referenced without/outside this instance (myViewController)")
        }
    }
}

class MyButton: UIButton {
    var clicked: (() -> ())

    init(clicked: (() -> ())) {
        self.clicked = clicked

        // We use constraints to layout the view. We don't explicitly set the frame.
        super.init(frame: .zero)

        addTarget(self, action: #selector(clicked), for: .touchUpInside)
    }

    @objc private func sendClosure() {
        clicked()
    }
}

ব্যবহার করুন weakযখন একটি সম্ভাবনা আছে selfহতে পারে nilবিন্দু আপনি অ্যাক্সেস এself

উদাহরণ:

class MyViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        NetworkManager.sharedInstance.receivedData = { [weak self] (data) in
            print("Can you guarentee that self is always available when the network manager received data?")
            print("Nope, you can't. Network manager will be alive, regardless of this particular instance of MyViewController")
            print("You should use weak self here, since you are not sure if this instance is still alive for every")
            print("future callback of network manager")
        }
    }
}

class NetworkManager {

    static let sharedInstance = NetworkManager()

    var receivedData: ((Data) -> ())?

    private func process(_ data: Data) {
        // process the data...

        // ... eventually notify a possible listener.
        receivedData?(data)
    }
}

কনস unowned:

  • দুর্বলের চেয়ে বেশি দক্ষ
  • আপনি উদাহরণটি অপরিবর্তনীয় হিসাবে চিহ্নিত করতে (ভাল, আপনি বাধ্য হয়েছেন) করতে পারেন (সুইফট 5.0 থেকে আর নয়)।
  • আপনার কোডের পাঠকের প্রতি ইঙ্গিত দেয়: এই উদাহরণটির এক্স এর সাথে একটি সম্পর্ক রয়েছে এবং এটি ছাড়া বাঁচতে পারে না, তবে এক্স চলে গেলে আমিও চলে গিয়েছি।

কনস weak:

  • অজানা থেকে বেশি নিরাপদ (যেহেতু এটি ক্রাশ করতে পারে না)।
  • এক্স এর সাথে এমন সম্পর্ক তৈরি করতে পারে যা উভয় উপায়েই যায় তবে উভয়ই একে অপরকে ছাড়া বাঁচতে পারে।

আপনি যদি নিশ্চিত না হন তবে ব্যবহার করুন weakঅপেক্ষা করুন , মানে স্ট্যাকওভারফ্লোতে এখানে জিজ্ঞাসা করুন আপনার ক্ষেত্রে আপনার কী করা উচিত! যখন আপনার উচিত হয় না তখন সবসময় দুর্বল ব্যবহার করা আপনার কোডটি এবং আপনার পাঠককে বিভ্রান্ত করে তোলে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.