সি ++ কেন উত্তরাধিকারসূত্রে বন্ধুত্বের অনুমতি দেয় না?

Question

বন্ধুত্ব কেন কমপক্ষে +চ্ছিকভাবে সি ++ এ উত্তরাধিকারসূত্রে হয় না? আমি স্পষ্ট কারণগুলির জন্য ট্রানজিটিভিটি এবং রিফ্লেক্সিভিটি নিষিদ্ধ বুঝতে পেরেছি (আমি কেবল এফএকিউ এর সহজ উত্তরগুলি প্রকাশ করার জন্য এটি বলি), তবে virtual friend class Foo;আমার ধাঁধাটির পংক্তিতে কিছু অভাব আছে । এই সিদ্ধান্তের পিছনে anyoneতিহাসিক পটভূমি কি কেউ জানেন? বন্ধুত্ব কি আসলেই কেবল একটি সীমাবদ্ধ হ্যাক যা কিছু অস্পষ্ট সম্মানজনক ব্যবহারের পথ খুঁজে পেয়েছিল?

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

class A {
  int x;
  friend class B;
};

class B {
  // OK as per friend declaration above.
  void foo(A& a, int n) { a.x = n; }
};

class D : public B { /* can't get in A w/o 'friend class D' declaration. */ };

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

Answer 1

কারণ আমি লিখতে Fooএবং তার বন্ধু হতে পারেBar (সুতরাং একটি বিশ্বাসের সম্পর্ক রয়েছে)।

তবে আমি কি সেই লোকদের উপর নির্ভর করি যারা ক্লাসগুলি লেখেন যা থেকে প্রাপ্ত Bar?
আসলে তা না. সুতরাং তাদের বন্ধুত্বের উত্তরাধিকারী হওয়া উচিত নয়।

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

সুতরাং যদি এর অভ্যন্তরীণ প্রতিনিধিত্ব Fooসংশোধন করা হয় তবে Barঅবশ্যই সংশোধন করতে হবে (কারণ বন্ধুত্বটি দৃ tight়ভাবে আবদ্ধ Barহয় Foo)। বন্ধুত্ব যদি উত্তরাধিকার সূত্রে প্রাপ্ত হয় তবে এর থেকে প্রাপ্ত সমস্ত Barশ্রেণিও দৃ tight়ভাবে আবদ্ধ হবে Fooএবং সুতরাং Fooঅভ্যন্তরীণ উপস্থাপনা পরিবর্তন করা হলে পরিবর্তনের প্রয়োজন। তবে উত্পন্ন ধরণের সম্পর্কে আমার কোন জ্ঞান নেই (না আমারও হওয়া উচিত They এগুলি এমনকি বিভিন্ন সংস্থা ইত্যাদি দ্বারা বিকাশিত হতে পারে)। সুতরাং আমি Fooকোড বেসে ব্রেকিং পরিবর্তনগুলি চালু করার কারণে এটি পরিবর্তন করতে অক্ষম হব (যেহেতু আমি উত্পন্ন সমস্ত শ্রেণীর সংশোধন করতে পারিনি Bar)।

সুতরাং যদি বন্ধুত্ব উত্তরাধিকার সূত্রে প্রাপ্ত হয় তবে আপনি অজান্তেই কোনও শ্রেণি সংশোধন করার ক্ষমতার উপর একটি বিধিনিষেধ পেশ করছেন। আপনি মূলত একটি পাবলিক এপিআই এর ধারণাটি বেহুদা হিসাবে সরবরাহ করার কারণে এটি অনাকাঙ্ক্ষিত।

দ্রষ্টব্য: একটি শিশু ব্যবহার করে Barঅ্যাক্সেস করতে পারে , কেবল সুরক্ষিত পদ্ধতিটি তৈরি করে । তারপরে বাচ্চাটি তার অভিভাবক শ্রেণীর মাধ্যমে কল করে একটি অ্যাক্সেস করতে পারে ।FooBarBarBarFoo

এই কমান্ডের সাহায্যে আপনি চান কি?

class A
{
    int x;
    friend class B;
};

class B
{
    protected:
       // Now children of B can access foo
       void foo(A& a, int n) { a.x = n; }
};

class D : public B
{
    public:
        foo(A& a, int n)
        {
            B::foo(a, n + 5);
        }
};

Comments

বিঙ্গো এটি কোনও শ্রেণীর অভ্যন্তরীন পরিবর্তন করে আপনার যে ক্ষয়ক্ষতি করতে পারে তা সীমাবদ্ধ করার বিষয়ে।

— j_random_hacker

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

— জেফ

@ জেফ: একটি শ্রেণীর সমস্ত বাচ্চার কাছে অভ্যন্তরীণ প্রতিনিধিত্ব প্রকাশের ফলে কোডটি অপরিবর্তনীয় হয়ে উঠবে (এটি প্রকৃতপক্ষে অভ্যন্তরীণ সদস্যদের অ্যাক্সেস করতে চাইলে যে কোনও ব্যক্তিই বার থেকে উত্তরাধিকারী হতে হবে এমনকি যদি তারা সত্যিকার অর্থে বার না হয় তবে বার্সের উত্তরাধিকারী হতে হবে) )।

— মার্টিন ইয়র্ক

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

— জেফ

@ মার্টিন: ঠিক আছে, এটি আমি চাই যা প্রভাব এবং মাঝে মাঝে ইতিমধ্যে ইতিমধ্যে ব্যবহার করি, যেখানে এ আসলে কিছুটা সীমাবদ্ধ অ্যাক্সেস ক্লাস জেডের জন্য একটি পারস্পরিক বন্ধুবান্ধব ইন্টারফেস is সাধারণ অ্যাটর্নি-ক্লায়েন্ট ইডিয়মের সাথে সাধারণ অভিযোগ মনে হয় ইন্টারফেস শ্রেণি এ-কে জেড-এ কল র‌্যাপারগুলি বয়লারপ্লেট করতে হয় এবং উপক্লাসে অ্যাক্সেস প্রসারিত করতে এ-এর বয়লারপ্লেটটি বি এর মতো প্রতিটি বেস শ্রেণিতে মূলত নকল করতে হয় একটি ইন্টারফেস সাধারণত মডিউলটি কী কার্যকারিতা প্রকাশ করতে চায় তা প্রকাশ করে, অন্যের কার্যকারিতা নয় নিজেই ব্যবহার করতে চায়

— জেফ

Answer 2

বন্ধুত্ব কেন কমপক্ষে +চ্ছিকভাবে সি ++ এ উত্তরাধিকারসূত্রে হয় না?

আমি মনে করি যে আপনার প্রথম প্রশ্নের উত্তর এই প্রশ্নের মধ্যে রয়েছে: "আপনার বাবার বন্ধুরা কি আপনার প্রাইভেটে অ্যাক্সেস পাবে?"

Comments

সত্যি কথা বলতে কি, এই প্রশ্নটি আপনার পিতাকে নিয়ে বিরক্তিকর বিষয়গুলি উত্থাপন করে। । ।

— ইহানেই

এই উত্তরের মূল বক্তব্য কী? সর্বোপরি একটি সন্দেহজনক যদিও সম্ভবত হালকা অন্তরের মন্তব্য

— বিকাশকারী

Answer 3

বন্ধুবান্ধব শ্রেণি তার বন্ধুকে অ্যাক্সেসর ফাংশনগুলির মাধ্যমে প্রকাশ করতে পারে এবং তারপরে সেগুলির মাধ্যমে অ্যাক্সেস দিতে পারে।

class stingy {
    int pennies;
    friend class hot_girl;
};

class hot_girl {
public:
    stingy *bf;

    int &get_cash( stingy &x = *bf ) { return x.pennies; }
};

class moocher {
public: // moocher can access stingy's pennies despite not being a friend
    int &get_cash( hot_girl &x ) { return x.get_cash(); }
};

এটি alচ্ছিক ট্রানজিটিভিটির চেয়ে সূক্ষ্ম নিয়ন্ত্রণের অনুমতি দেয়। উদাহরণস্বরূপ, রানটাইম-সীমাবদ্ধ অ্যাক্সেসের একটি প্রোটোকল get_cashহতে পারে protectedবা প্রয়োগ করতে পারে ।

Comments

@ হেক্টর: রিফ্যাক্টরিংয়ের জন্য ভোট! ;)

— আলেকজান্ডার শুকায়েভ

Answer 4

সি ++ স্ট্যান্ডার্ড, বিভাগ 11.4 / 8

বন্ধুত্ব উত্তরাধিকারসূত্রে হয় না বা ট্রানজিটিভ হয় না।

যদি বন্ধুত্ব উত্তরাধিকার সূত্রে প্রাপ্ত হয়, তবে যে ক্লাসটি বন্ধু হিসাবে বোঝানো হয়নি তা হঠাৎ করে আপনার শ্রেণীর অভ্যন্তরীণগুলিতে অ্যাক্সেস পেতে পারে এবং এটি এনক্যাপসুলেশন লঙ্ঘন করে।

Comments

Q "বন্ধুবান্ধব" A বলুন এবং B এ থেকে উদ্ভূত হয়েছে এবং বি যদি A এর কাছ থেকে বন্ধুত্বের উত্তরাধিকার সূত্রে প্রাপ্ত হয় তবে B কারণ A এর এক প্রকার, প্রযুক্তিগতভাবে এটি A A যা Q এর প্রাইভেটগুলি অ্যাক্সেস করে। সুতরাং এটি কোনও ব্যবহারিক কারণ দিয়ে প্রশ্নের উত্তর দেয় না।

— এমডেন্টন 8

Answer 5

কারণ এটি কেবল অপ্রয়োজনীয়।

ব্যবহার friend নিজেই সন্দেহজনক। সংযোগের মেয়াদে এটি সবচেয়ে খারাপ সম্পর্ক (উত্তরাধিকার এবং রচনার পথে)।

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

আমি নির্দ্বিধায় স্বীকার করি যে হোম ওয়ার্ক / পোষা প্রকল্পের জন্য নির্ভরতা প্রায়শই অনেক দূরের বিবেচনা। ছোট আকারের প্রকল্পগুলিতে এটি কোনও বিষয় নয়। তবে যত তাড়াতাড়ি একাধিক ব্যক্তি একই প্রকল্পে কাজ করে এবং এটি কয়েক লক্ষাধিক লাইনে বৃদ্ধি পায় আপনাকে পরিবর্তনের প্রভাব সীমাবদ্ধ করতে হবে।

এটি একটি খুব সহজ নিয়ম এনেছে:

কোনও শ্রেণীর ইন্টার্নাল পরিবর্তন করা কেবলমাত্র ক্লাসকেই প্রভাবিত করে

অবশ্যই, আপনি সম্ভবত এর বন্ধুদের প্রভাবিত করতে পারেন, তবে এখানে দুটি মামলা রয়েছে:

• বন্ধু মুক্ত ফাংশন: যাইহোক সম্ভবত সদস্য ফাংশন বেশি (আমি মনে করি std::ostream& operator<<(...) যেহেতু এখানে , যা ভাষা নিয়মের দুর্ঘটনায় নিখুঁতভাবে সদস্য নয়)
• বন্ধু শ্রেণি? আপনার বাস্তব ক্লাসে বন্ধু ক্লাসের দরকার নেই।

আমি সহজ পদ্ধতিটি ব্যবহারের পরামর্শ দেব:

class Example;

class ExampleKey { friend class Example; ExampleKey(); };

class Restricted
{
public:
  void forExampleOnly(int,int,ExampleKey const&);
};

এই সাধারণ Keyপ্যাটার্নটি আপনাকে আপনার অভ্যন্তরগুলিতে এটির অ্যাক্সেস না দিয়েই কোনওভাবে (কোনওভাবে) বন্ধু হিসাবে ঘোষণা করতে দেয়, এভাবে এটি পরিবর্তন থেকে পৃথক করে দেয়। তদতিরিক্ত, এটি যদি প্রয়োজন হয় তবে এই বন্ধুটিকে ট্রাস্টিগুলিতে (বাচ্চাদের মতো) এর চাবি ndণ দেওয়ার অনুমতি দেয়।

Answer 6

একটি অনুমান: কোনও শ্রেণি যদি অন্য কোনও শ্রেণি / ক্রিয়াকে বন্ধু হিসাবে ঘোষণা করে, কারণ এটি দ্বিতীয় সত্তার প্রথমটিতে বিশেষাধিকার প্রাপ্ত অ্যাক্সেসের প্রয়োজন। প্রথম সত্তা থেকে প্রাপ্ত স্বেচ্ছাসেবী সংখ্যায় দ্বিতীয় সত্তাকে বিশেষাধিকারী অ্যাক্সেস দেওয়ার ক্ষেত্রে কী ব্যবহার রয়েছে?

Comments

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

— জেফ

@ জেফ: আহ, তাহলে আমি আপনার উদ্দেশ্যযুক্ত অর্থ ভুল বুঝেছি। আমি ধরে নিয়েছি আপনার অর্থ হ'ল Bউত্তরাধিকার সূত্রে প্রাপ্ত সমস্ত শ্রেণীর অ্যাক্সেস থাকবে A...

— অলিভার চার্লসওয়ার্থ

Answer 7

একটি উত্পন্ন শ্রেণি কেবলমাত্র কিছু উত্তরাধিকারী হতে পারে যা বেসের 'সদস্য'। বন্ধুত্বের ঘোষণাটি বন্ধুত্বপূর্ণ শ্রেণীর সদস্য নয় ।

.4 11.4 / 1- "... বন্ধুর নাম ক্লাসের আওতায় নেই, এবং বন্ধুটি অন্য প্রবেশাধিকারী অপারেটরগুলির সাথে কল করা হয় না (5.2.5) যদি না এটি অন্য শ্রেণীর সদস্য না হয়।"

.4 11.4 - "এছাড়াও, যেহেতু বন্ধু শ্রেণীর বেস-ক্লজটি তার সদস্য ঘোষণার অংশ নয়, বন্ধু শ্রেণীর বেস-ক্লজ বন্ধুত্ব দানকারী শ্রেণীর ব্যক্তিগত এবং সুরক্ষিত সদস্যদের নাম অ্যাক্সেস করতে পারে না।"

এবং আরও

.3 10.3 / 7- "[দ্রষ্টব্য: ভার্চুয়াল স্পেসিফায়ার সদস্যতার বোঝায় তাই ভার্চুয়াল ফাংশনটি ননমেম্বার (7.1.2) ফাংশন হতে পারে না এবং ভার্চুয়াল ফাংশনটি কোনও স্থির সদস্য হতে পারে না, যেহেতু ভার্চুয়াল ফাংশন কল একটি নির্দিষ্ট অবজেক্টের জন্য নির্ভর করে কোন ফাংশনটি প্রার্থনা করতে হবে তা নির্ধারণ করে one এক শ্রেণিতে ঘোষিত একটি ভার্চুয়াল ফাংশনকে অন্য শ্রেণিতে বন্ধু হিসাবে ঘোষণা করা যেতে পারে]] "

যেহেতু 'বন্ধু' প্রথমে বেস ক্লাসের সদস্য নয়, এটি কীভাবে উত্তরাধিকার সূত্রে প্রাপ্ত বর্গ দ্বারা প্রাপ্ত হতে পারে?

Comments

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

— জেফ

Answer 8

ক্লাসে থাকা ফ্রেন্ড ফাংশনটি ফাংশনে বাহ্যিক সম্পত্তি বরাদ্দ করে। অর্থাত্ বাহ্যিক অর্থ ক্লাসের বাইরে কোথাও ঘোষিত এবং সংজ্ঞায়িত করা হয়েছে।

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

Answer 9

কনটেইনারটির জন্য স্টাইল ইন্টারফেসের মতো বন্ধু উত্তরাধিকারে ভাল তবে আমার পক্ষে প্রথম হিসাবে বলা হয়েছে, সি ++ এর প্রচারযোগ্য উত্তরাধিকারের অভাব রয়েছে

class Thing;

//an interface for Thing container's
struct IThing {
   friend Thing;
   protected:
       int IThing_getData() = 0;
};

//container for thing's
struct MyContainer : public IThing {
    protected: //here is reserved access to Thing
         int IThing_getData() override {...}
};

struct Thing {
    void setYourContainer(IThing* aContainerOfThings) {
        //access to unique function in protected area 
        aContainerOfThings->IThing_getData(); //authorized access
    }
};

struct ChildThing : public Thing {
    void doTest() {
        //here the lack of granularity, you cannot access to the container.
        //to use the container, you must implement all 
        //function in the Thing class
        aContainerOfThings->IThing_getData(); //forbidden access
    }
};

আমার জন্য সি ++ এর সমস্যা হ'ল যে কোনও জায়গা থেকে যে কোনও জায়গা থেকে সমস্ত অ্যাক্সেস নিয়ন্ত্রণ করতে খুব ভাল গ্রানুলারালটির অভাব:

থিং-এর সমস্ত সন্তানের অ্যাক্সেস দেওয়ার জন্য বন্ধু থিং বন্ধু থিং হয়ে উঠতে পারে

এবং আরও, বন্ধু [নামযুক্ত অঞ্চল] জিনিস * * সুনির্দিষ্টভাবে অ্যাক্সেস দেওয়ার জন্য বন্ধুর জন্য বিশেষ নামকৃত অঞ্চলটি ধারক ধারক হয়ে কনটেইনার ক্লাসে রয়েছে।

ঠিক আছে স্বপ্ন থামান। তবে এখন, আপনি বন্ধুর একটি আকর্ষণীয় ব্যবহার জানেন।

অন্য ক্রমে, আপনি আকর্ষণীয় সনাক্ত করতে পারেন সমস্ত শ্রেণীর স্ব সাথে বন্ধুত্বপূর্ণ হয়। অন্য কথায়, একটি শ্রেণীর উদাহরণ
কোনও বাধা ছাড়াই একই নামের অন্য একটি উদাহরণের সমস্ত সদস্যকে কল করতে পারে:

class Object {
     private:
         void test() {}
     protected:
         void callAnotherTest(Object* anotherObject) {
             //private, but yes you can call test() from 
             //another object instance
             anotherObject)->test(); 
         }
};

Answer 10

সাধারণ যুক্তি: 'আমার একটি বন্ধু জেন আছে। আমরা গতকাল বন্ধু হয়েছি বলেই তার সমস্ত বন্ধু আমার হয় না ''

আমার এখনও সেই স্বতন্ত্র বন্ধুত্বগুলি অনুমোদন করা দরকার এবং সেই অনুযায়ী আস্থার স্তরটিও হবে।