কেন আমি সি # তে সম্পত্তি ব্যবহার করা এড়ানো উচিত?

Question

সিএলআর ভায়ার সি # এর দুর্দান্ত বইতে জেফ্রি রিখটার বলেছিলেন যে তিনি সম্পত্তি পছন্দ করেন না এবং সেগুলি ব্যবহার না করার পরামর্শ দেন। তিনি কিছু কারণ দিয়েছেন, কিন্তু আমি আসলে বুঝতে পারি না। আমাকে সম্পত্তি কেন ব্যবহার করা উচিত বা করা উচিত নয় তা আমাকে কেউ ব্যাখ্যা করতে পারেন? সি # 3.0 এ, স্বয়ংক্রিয় বৈশিষ্ট্য সহ, এই পরিবর্তন হয়?

একটি রেফারেন্স হিসাবে, আমি জেফ্রি রিখটারের মতামতগুলি যুক্ত করেছি:

Property একটি সম্পত্তি কেবল পঠনযোগ্য বা কেবল লেখার জন্য হতে পারে; ক্ষেত্রের অ্যাক্সেস সর্বদা পঠনযোগ্য এবং লিখনযোগ্য। আপনি যদি কোনও সম্পত্তি সংজ্ঞায়িত করেন তবে গেম এবং সেট অ্যাকসেসর পদ্ধতি উভয়ই দেওয়া ভাল।

Property একটি সম্পত্তি পদ্ধতি একটি ব্যতিক্রম নিক্ষেপ করতে পারে; ক্ষেত্রের অ্যাক্সেস কখনই ব্যতিক্রম ছুঁড়ে না ফেলে।

• সম্পত্তি কোনও পদ্ধতিতে আউট বা রেফ প্যারামিটার হিসাবে পাস করা যায় না; একটি ক্ষেত্র পারেন। উদাহরণস্বরূপ, নিম্নলিখিত কোডটি সংকলন করবে না:

using System;
public sealed class SomeType
{
   private static String Name 
   {
     get { return null; }
     set {}
   }
   static void MethodWithOutParam(out String n) { n = null; }
   public static void Main()
   {
      // For the line of code below, the C# compiler emits the following:
      // error CS0206: A property or indexer may not
      // be passed as an out or ref parameter
      MethodWithOutParam(out Name);
   }
}

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

A একটানা একাধিক বার বলা হয়ে থাকে, সম্পত্তি সম্পত্তি প্রতিটি সময় একটি পৃথক মান ফিরে আসতে পারে; একটি ক্ষেত্র প্রতিটি সময় একই মান প্রদান করে। সিস্টেম.ডেটটাইম শ্রেণিতে একটি পঠনযোগ্য এখন সম্পত্তি রয়েছে যা বর্তমান তারিখ এবং সময়কে দেয়। প্রতিবার আপনি এই সম্পত্তিটি জিজ্ঞাসা করবেন, এটি একটি পৃথক মান প্রদান করবে। এটি একটি ভুল, এবং মাইক্রোসফ্ট আশা করে যে তারা কোনও সম্পত্তির পরিবর্তে নাওকে একটি পদ্ধতি তৈরি করে ক্লাসটি ঠিক করতে পারে।

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

Property কোনও সম্পত্তি পদ্ধতির জন্য অতিরিক্ত মেমরির প্রয়োজন হতে পারে বা এমন কোনও জিনিসের রেফারেন্স ফিরে আসতে পারে যা আসলে বস্তুর রাজ্যের অংশ নয়, সুতরাং প্রত্যাবর্তিত বস্তুকে সংশোধন করা মূল বস্তুর উপর কোনও প্রভাব ফেলবে না; ক্ষেত্রটি জিজ্ঞাসা করা সর্বদা কোনও অবজেক্টের রেফারেন্স দেয় যা মূল বস্তুর অবস্থার অংশ হিসাবে গ্যারান্টিযুক্ত। কোনও অনুলিপি প্রদান করে এমন কোনও সম্পত্তি নিয়ে কাজ করা বিকাশকারীদের কাছে খুব বিভ্রান্তিকর হতে পারে এবং এই বৈশিষ্ট্যটি প্রায়শই নথিভুক্ত হয় না।

Comments

আমি সিএলআর মাধ্যমে সি # এর তৃতীয় সংস্করণটির মালিক এবং ২৪২ পৃষ্ঠায় মিঃ রিস্টার বলেছেন যে তিনি ব্যক্তিগতভাবে সম্পত্তি পছন্দ করেন না, তবে সেগুলি কখনও ব্যবহার না করার পরামর্শ দেন না। আপনি যেখানে পড়েছেন দয়া করে বইয়ের সংস্করণ এবং পৃষ্ঠা নম্বরটি উল্লেখ করুন।

— kirk.burleson

Answer 1

জেফের সম্পত্তি অপছন্দ করার কারণ হ'ল তারা ক্ষেত্রগুলির মতো দেখায় - তাই বিকাশকারীরা যারা পার্থক্যটি বুঝতে পারে না তারা তাদের ক্ষেত্র বলে মনে করবে তারা ধরে নিবে যে তারা কার্যকর করতে সক্ষম হবে ইত্যাদি etc.

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

(এবং না, স্বয়ংক্রিয়ভাবে প্রয়োগকৃত বৈশিষ্ট্যগুলি আসলে এর কোনও পরিবর্তন করে না))

এটি সামান্য প্রসারিত পদ্ধতিগুলি ব্যবহার করার বিরুদ্ধে যুক্তিগুলির মতো - আমি যুক্তিটি বুঝতে পারি, তবে ব্যবহারিক সুবিধা (যখন খুব কম ব্যবহার করা হয়) আমার দৃষ্টিতে ডাউনসাইডকে ছাড়িয়ে যায়।

Comments

আপনাকে উত্তর দেওয়ার জন্য অনেক ধন্যবাদ! এক্সটেনশন পদ্ধতিগুলি ব্যবহার করার বিরুদ্ধে তর্কগুলি সম্পর্কে: আপনি কিছু জেফরি রিখরারের বিষয়ে বা বিমূর্তে কথা বলছেন?

— আবাটিশচেভ

@ বাতিশচেভ: এটি এক্সটেনশন পদ্ধতি সম্পর্কে একটি সাধারণ বিষয় ছিল। এটি সরাসরি বৈশিষ্ট্যের সাথে সম্পর্কিত নয়।

— জন স্কিটি

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

— দ্য ব্লাস্টঅন

@ পেট্রিকফ্র্যামবার্গ: আপনি প্রচুর পরিমাণে কোড মিস করেছেন যা আপাতদৃষ্টিতে কেবল পঠনযোগ্য ক্ষেত্র ব্যবহার করে। বলে রাখার মতো কিছুই নেই যে বৈশিষ্ট্যগুলি পরিবর্তনকে বোঝায়। আমার প্রায়শই কেবল পঠনযোগ্য ক্ষেত্রগুলি কেবলমাত্র পঠনযোগ্য বৈশিষ্ট্যগুলিকে সমর্থন করে - আপনি কি এটি খারাপ জিনিস বলে মনে করেন?

— জন স্কিটি

@ পেট্রিক: না, এটি প্রয়োগ থেকে API কে আলাদা করার সুবিধা নিয়ে আসে - আপনি পরে ক্ষেত্র থেকে কীভাবে সম্পত্তিটি গণনা করা যায় তা পরিবর্তন করতে পারেন (যেমন একটি ক্ষেত্র থেকে দুটি সম্পর্কিত বৈশিষ্ট্য গণনা করা) ute

— জন স্কিটি

Answer 2

ঠিক আছে, তার যুক্তিগুলি একে একে নেওয়া যাক:

একটি সম্পত্তি কেবল পঠনযোগ্য বা কেবল লেখার জন্য হতে পারে; ক্ষেত্রের অ্যাক্সেস সর্বদা পঠনযোগ্য এবং লিখনযোগ্য।

এটি বৈশিষ্ট্যগুলির জন্য একটি জয়, যেহেতু আপনার অ্যাক্সেসের আরও সূক্ষ্ম নিয়ন্ত্রণ রয়েছে।

একটি সম্পত্তি পদ্ধতি একটি ব্যতিক্রম নিক্ষেপ করতে পারে; ক্ষেত্রের অ্যাক্সেস কখনই ব্যতিক্রম ছুঁড়ে না ফেলে।

এটি বেশিরভাগ ক্ষেত্রে সত্য হলেও আপনি খুব ভালভাবে একটি পদ্ধতিটি কল করতে পারেন না কোনও সূচনাপ্রাপ্ত অবজেক্ট ক্ষেত্রে and

• সম্পত্তি কোনও পদ্ধতিতে আউট বা রেফ প্যারামিটার হিসাবে পাস করা যায় না; একটি ক্ষেত্র পারেন।

ফেয়ার।

Property একটি সম্পত্তি পদ্ধতি কার্যকর করতে দীর্ঘ সময় নিতে পারে; ক্ষেত্রের অ্যাক্সেস সর্বদা অবিলম্বে সম্পূর্ণ হয়।

এটি খুব সামান্য সময়ও নিতে পারে।

A একটানা একাধিক বার বলা হয়ে থাকে, সম্পত্তি সম্পত্তি প্রতিটি সময় একটি পৃথক মান ফিরে আসতে পারে; একটি ক্ষেত্র প্রতিটি সময় একই মান প্রদান করে।

সত্য না. আপনি কীভাবে জানবেন যে ক্ষেত্রের মান পরিবর্তিত হয়নি (সম্ভবত অন্য থ্রেড দ্বারা)?

সিস্টেম.ডেটটাইম শ্রেণিতে একটি পঠনযোগ্য এখন সম্পত্তি রয়েছে যা বর্তমান তারিখ এবং সময়কে দেয়। প্রতিবার আপনি এই সম্পত্তিটি জিজ্ঞাসা করবেন, এটি একটি পৃথক মান প্রদান করবে। এটি একটি ভুল, এবং মাইক্রোসফ্ট আশা করে যে তারা কোনও সম্পত্তির পরিবর্তে নাওকে একটি পদ্ধতি তৈরি করে ক্লাসটি ঠিক করতে পারে।

যদি এটি ভুল হয় তবে এটি একটি ছোটখাটো।

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

ফেয়ার।

Property কোনও সম্পত্তি পদ্ধতির জন্য অতিরিক্ত মেমরির প্রয়োজন হতে পারে বা এমন কোনও জিনিসের রেফারেন্স ফিরে আসতে পারে যা আসলে বস্তুর রাজ্যের অংশ নয়, সুতরাং প্রত্যাবর্তিত বস্তুকে সংশোধন করা মূল বস্তুর উপর কোনও প্রভাব ফেলবে না; ক্ষেত্রটি জিজ্ঞাসা করা সর্বদা কোনও অবজেক্টের রেফারেন্স দেয় যা মূল বস্তুর অবস্থার অংশ হিসাবে গ্যারান্টিযুক্ত। কোনও অনুলিপি প্রদান করে এমন কোনও সম্পত্তি নিয়ে কাজ করা বিকাশকারীদের কাছে খুব বিভ্রান্তিকর হতে পারে এবং এই বৈশিষ্ট্যটি প্রায়শই নথিভুক্ত হয় না।

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

আমি মনে করি বেশিরভাগ সমস্যার সমাধান আরও ভাল সিনট্যাক্স হাইলাইটিং দ্বারা (যেমন ক্ষেত্রগুলি থেকে বৈশিষ্ট্য পৃথক করে) সমাধান করা যেতে পারে তাই প্রোগ্রামার কী আশা করতে পারে তা জানে।

Comments

"আরও ভাল সিনট্যাক্স হাইলাইট করে সমস্যার সমাধান করা যেতে পারে" : আপনি কতবার সর্বজনীন ক্ষেত্র ব্যবহার করেন? ব্যক্তিগত ক্ষেত্রগুলিতে সাধারণত আলাদা স্টাইল থাকে _field। বা শুধু ছোট হাতের অক্ষর field।

— স্টিভেন জিউরিস

Answer 3

আমি বইটি পড়িনি, এবং আপনি যে অংশটি বুঝতে পারেন তা উদ্ধৃত করেন নি, তাই আমাকে অনুমান করতে হবে।

কিছু লোক সম্পত্তি অপছন্দ করে কারণ তারা আপনার কোডটিকে অবাক করে দেওয়ার কাজ করতে পারে।

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

পরিবর্তে, বৈশিষ্ট্য সহ, এটি আসলে একটি ফাংশন কল হতে পারে। এটি একটি অসীম লুপ হতে পারে। এটি একটি ডাটাবেস সংযোগ খুলতে পারে। আমি যখনই এটি অ্যাক্সেস করি ততবার এটি বিভিন্ন মান ফিরে আসতে পারে।

লিনাস কেন সি +++ ঘৃণা করে এটি এটি একটি অনুরূপ যুক্তি। আপনার কোড পাঠকের জন্য অবাক করে দিতে পারে। তিনি অপারেটর ওভারলোডিংকে ঘৃণা করেন: a + bঅগত্যা সহজ সংযোজন বোঝায় না। এর অর্থ সি # বৈশিষ্ট্যের মতো কিছু বিশাল জটিল অপারেশন হতে পারে। এর পার্শ্ব প্রতিক্রিয়া হতে পারে। এটি কিছু করতে পারে।

সত্যি বলতে, আমি মনে করি এটি একটি দুর্বল যুক্তি। উভয় ভাষা এই জাতীয় জিনিস পূর্ণ। (আমাদেরও কি সি # তে অপারেটর ওভারলোডিং এড়ানো উচিত? সর্বোপরি, সেখানে একই যুক্তি ব্যবহার করা যেতে পারে)

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

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

তবে এগুলি নিখুঁত চেয়ে কম খুঁজে পাওয়ার আমার আরও একটি কারণ রয়েছে। অন্যান্য ফাংশনগুলির রেফারেন্স দ্বারা এগুলি পাস করা যায় না।

ক্ষেত্রগুলি যেমন refকোনও কল করা ফাংশনটিকে সরাসরি অ্যাক্সেসের অনুমতি দেয়, তেমন পাস করা যেতে পারে । ডাকা প্রতিনিধি হিসাবে ফাংশনগুলি পাস করা যেতে পারে, একটি ডাকা ফাংশনটিকে এটি সরাসরি অ্যাক্সেস করার অনুমতি দেয়।

সম্পত্তি ... না।

যে স্তন্যপান।

তবে এর অর্থ এই নয় যে সম্পত্তিগুলি খারাপ বা ব্যবহার করা উচিত নয়। অনেক উদ্দেশ্যে, তারা দুর্দান্ত।

Comments

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

— জন স্কিটি

হাঁ আমি একমত. যুক্তিটি ফুটে উঠেছে বলে মনে হচ্ছে "আমি কেবল এই ক্ষেত্রের জন্য এই সিনট্যাক্সটি ব্যবহার করছি Therefore সুতরাং, অন্যান্য ক্ষেত্রে এটি প্রসারিত করা খারাপ" " এবং এর সুস্পষ্ট উত্তর হ'ল "ঠিক আছে, তখন এর সাথে অন্যান্য ক্ষেত্রে coveringাকা পড়ে অভ্যস্ত হয়ে যান এবং এটি খারাপ হবে না"। ;)

— জলফ

আমি চাই। নেট ভাষাগুলি একটি মানক উপায় সরবরাহ করবে যার দ্বারা কোনও শ্রেণি refপ্যারাম হিসাবে সম্পত্তি প্রকাশ করে ; সদস্য (যেমন Fooএকটি ফর্ম এর) void Foo<T>(ActionByRef<Point,T> proc, ref T param)একটি বিশেষ বৈশিষ্ট্য সঙ্গে, এবং কম্পাইলার রুপান্তর আছে thing.Foo.X+=someVar;মধ্যে Foo((ref Point it, ref int param)=>it.X += param, ref someVar);। যেহেতু ল্যাম্বদা একটি স্ট্যাটিক প্রতিনিধি, তাই কোনও বন্ধ করার দরকার পড়বে না এবং কোনও বস্তুর ব্যবহারকারীর স্টোরের যে কোনও জায়গার সম্পত্তি জেনুইন refপ্যারামিটার হিসাবে সমর্থন করতে পারে (এবং এটি refপ্যারামিটার হিসাবে অন্যান্য পদ্ধতিতেও দিতে পারে )।

— সুপারক্যাট

হাত দিয়ে ল্যাম্বডা লিখে সত্যই আইকি-লুকিং উত্স কোড তৈরি করে, তবে সে কারণেই সংকলকটি ট্রান্সফর্মটি সম্পাদন করা সহায়ক হবে। "কলব্যাক-বাই-রেফ" সম্পত্তি প্রকাশের জন্য কোনও শ্রেণীর কোডটি বেশ যুক্তিসঙ্গত হবে। কলারের পক্ষে কোডটির একমাত্র কুৎসিত (অনুপস্থিত একটি রূপান্তর)।

— সুপারক্যাট

অনুগ্রহ করে বুঝুন যে কোনও সম্পত্তি সদস্য হিসাবে ছদ্মবেশযুক্ত একটি ফাংশন কল, সুতরাং আপনি কোনও শ্রেণীর পাবলিক ফাংশনগুলি পাস করার চেয়ে রেফারেন্স দিয়ে এটি পাস করতে পারবেন না। আপনি যদি সেভাবে এটি করার ইচ্ছা করেন তবে সর্বদা আপনি সর্বজনীন সদস্যকে ব্যবহার করতে পারেন। একটি সম্পত্তি হ'ল স্মার্ট সদস্য, এটি সেট করতে পাস করা অবৈধ ডেটার ব্যতিক্রম ছুঁড়ে ফেলতে পারে।

— ডাইসিয়াস

Answer 4

২০০৯ সালে ফিরে এই পরামর্শটি হু হু মাই চিজ জাতের বেলিচিংয়ের মতো বলে মনে হয়েছিল । আজ এটি প্রায় হাস্যোজ্জ্বল অপ্রচলিত।

একটি অত্যন্ত গুরুত্বপূর্ণ বিষয় যে অনেক উত্তর চারপাশে টিপটো বলে মনে হয় তবে বেশিরভাগ দিকই লক্ষ্য করে না যে সম্পত্তিগুলির এই উদ্দিষ্ট "বিপদ" ফ্রেমওয়ার্ক ডিজাইনের একটি ইচ্ছাকৃত অংশ!

হ্যাঁ, বৈশিষ্ট্যগুলি:

• গেটর এবং সেটারের জন্য আলাদা অ্যাক্সেস মডিফায়ার নির্দিষ্ট করুন। ক্ষেত্রগুলিতে এটি একটি সুবিধা । একটি সাধারণ প্যাটার্ন হ'ল পাবলিক গেটর এবং সুরক্ষিত বা অভ্যন্তরীণ সেটার, একটি খুব দরকারী উত্তরাধিকার কৌশল যা কেবলমাত্র ক্ষেত্রগুলি দ্বারা অর্জনযোগ্য নয়।

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

• কার্যকর করতে দীর্ঘ সময় দিন। এখানে বৈধ তুলনা পদ্ধতিগুলির সাথে হয় , যা ক্ষেত্রগুলিতে নয় - সমানভাবে বেশি সময় নেয় । একজন লেখকের ব্যক্তিগত পছন্দ ব্যতীত "একটি পদ্ধতি পছন্দসই" বিবৃতিটির কোনও ভিত্তি দেওয়া হয়নি।

• পরবর্তী মৃত্যুদন্ড কার্যকর করার সময় এর প্রাপ্তকারী থেকে বিভিন্ন মান ফেরত দিন। এটি প্রায় ক্ষেত্রগুলির সাথে ref/ outপরামিতিগুলির গুণাবলীকে বলার মতো বিন্দুটির নিকটতম দৃশ্যের মতো একটি কৌতুকের মতো বলে মনে হচ্ছে , যার ref/ একটি outকল করার পরে একটি ক্ষেত্রের মূল্য তার আগের মান থেকে বেশ আলাদা গ্যারান্টিযুক্ত এবং অনির্দেশ্যভাবে তাই।

  যদি আমরা কোনও সম্মতিযুক্ত দম্পতিবিহীন একক থ্রেডযুক্ত অ্যাক্সেসের সুনির্দিষ্ট (এবং ব্যবহারিকভাবে একাডেমিক) কেস সম্পর্কে কথা বলি তবে এটি মোটামুটি ভালভাবে বোঝা গেছে যে দৃশ্যমান-রাষ্ট্র-পরিবর্তনের পার্শ্ব-প্রতিক্রিয়াগুলি হ'ল এটি কেবল খারাপ সম্পত্তি ডিজাইন, এবং সম্ভবত আমার স্মৃতি বিবর্ণ, তবে আমি ব্যবহারকারীদের কোনও উদাহরণ ব্যবহার করে DateTime.Nowপ্রত্যাশা করতে পারি না এবং প্রতিবার একই মানটি প্রত্যাশা করে। কমপক্ষে এমন কোনও উদাহরণ নয় যেখানে তারা এটিকে কল্পনা করে ঠিক ততটা খারাপভাবে চিহ্নিত করতে না পারে DateTime.Now()।

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

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

অন্যান্য জিনিস যা বৈশিষ্ট্যগুলি করতে পারে যা ক্ষেত্রগুলি অন্তর্ভুক্ত করতে পারে না:

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

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

আমি এর দ্বারা যা বোঝাতে চাইছি তা হল তার "সম্পত্তিগুলি ক্ষতিকারক হিসাবে বিবেচিত" যুক্তিটি মূলত একক বিবৃতিতে ফুটে উঠেছে: সম্পত্তিগুলি ক্ষেত্রের মতো দেখায় তবে তারা ক্ষেত্রের মতো কাজ করতে পারে না। এবং বিবৃতিতে সমস্যাটি হ'ল এটি সত্য নয় বা সর্বোপরি এটি অত্যন্ত বিভ্রান্তিকর। সম্পত্তিগুলি ক্ষেত্রগুলির মতো দেখায় না - কমপক্ষে, তাদের ক্ষেত্রগুলির মতো দেখা উচিত নয় ।

দুই আছে খুব অনুরূপ নিয়মাবলী অন্যান্য CLR ভাষায় দ্বারা ভাগ করা সঙ্গে C # এর শক্তিশালী কোডিং সাধারণ প্রথা ও FXCop তোমার দিকে চিত্কার যদি আপনি তাদের অনুসরণ করো না হবে:

1. ক্ষেত্রগুলি সর্বদা ব্যক্তিগত হওয়া উচিত , কখনও সর্বজনীন নয়।
2. উট কেসে ক্ষেত্রগুলি ঘোষণা করা উচিত। বৈশিষ্ট্যগুলি প্যাসকেলকেস।

সুতরাং, Foo.Bar = 42সম্পত্তি অ্যাক্সেসর বা ফিল্ড অ্যাক্সেসর কিনা তা নিয়ে কোনও দ্বিধা নেই । এটা একটা সম্পত্তি অ্যাকসেসর এবং অন্য কোন পদ্ধতি মত চিকিত্সা করা উচিত - এটা ধীর হতে পারে, এটি একটি ব্যতিক্রম, ইত্যাদি প্রকৃতি যে ফেলে দিতে পারে বিমূর্ততা - এটা সম্পূর্ণরূপে ঘোষণা ক্লাসের বিচক্ষণতা পর্যন্ত কিভাবে প্রতিক্রিয়া আছে। ক্লাস ডিজাইনারদের ন্যূনতম বিস্ময়ের নীতিটি প্রয়োগ করা উচিত তবে কলকারীরা কোনও সম্পত্তি সম্পর্কে কিছুই ধারণা না করা ছাড়া এটি টিনে যা বলে সে তা করে। এটা উদ্দেশ্য।

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

আপনার যা খুশি বলুন তবে foo.Bar.Baz = quux.Answers[42]পড়ার চেয়ে সবসময় পড়া খুব সহজ হয়ে যায় foo.getBar().setBaz(quux.getAnswers().getItem(42))। এবং আপনি যখন এই দিনে কয়েক হাজার লাইন পড়ছেন, তখন এটি একটি পার্থক্য করে।

_{(এবং যদি উপরের অনুচ্ছেদে আপনার প্রাকৃতিক প্রতিক্রিয়া বলতে হয়, "নিশ্চিতভাবে এটি পড়া খুব কঠিন তবে আপনি যদি এটি একাধিক লাইনে ভাগ করে নেন তবে এটি আরও সহজ হবে") তবে আমি দুঃখিত হয়ে বলতে পারি যে আপনি বিন্দুটি পুরোপুরি মিস করেছেন have ।)}

Answer 5

আপনার সাধারণ সম্পত্তি কেন ব্যবহার করা উচিত নয় তার কোনও কারণ আমি দেখতে পাচ্ছি না।

সি # 3+ এ স্বয়ংক্রিয় বৈশিষ্ট্যগুলি কেবল সিনট্যাক্সকে কিছুটা সহজ করে তোলে (একটি লা সিনট্যাটিক চিনি)।

Comments

দয়া করে, বইটিতে 215-216 পৃষ্ঠা পড়ুন। আমি নিশ্চিত যে আপনি জানেন যে জেফরি রিখটার!

— কোয়ান মাই

আমি সিএলআর দিয়ে সি #, ২ য় এড।) পড়েছি, তার অবস্থানের সাথে একমত নই এবং প্রকৃত কারণগুলি বৈশিষ্ট্যগুলি ব্যবহার করে না দেখে নেই!

— আবাটিশচেভ

এটি একটি ভাল বই, তবে আমি এই মুহুর্তে লেখকের সাথে একমত নই।

— কনস্ট্যান্টিন তারকাস

যেখানে ঠিক সেই জায়গা যেখানে লেখক সম্পত্তি ব্যবহার না করার পরামর্শ দেন? P.215-217- তে কোনও কিছু খুঁজে পাওয়া যায় নি

— কনস্টান্টিন

আমি আমার প্রশ্নে জেফ্রির মতামত যুক্ত করেছি :)। আপনি এটি মুদ্রণ সংস্করণে 215-216 পৃষ্ঠাগুলিতে খুঁজে পেতে পারেন :)

— কোয়ান মাই

Answer 6

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

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

বৈশিষ্ট্য সহ ক্যাভ্যাট হিসাবে, একটি দম্পতি আছে। একটি সম্ভবত বৈশিষ্ট্যগুলির অপব্যবহার, অন্যটি সূক্ষ্ম হতে পারে।

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

যেমন

public class WorkerUsingMethod
{
   // Explicitly obvious that calculation is being done here
   public int CalculateResult()
   { 
      return ExpensiveLongRunningCalculation();
   }
}

public class WorkerUsingProperty
{
   // Not at all obvious.  Looks like it may just be returning a cached result.
   public int Result
   {
       get { return ExpensiveLongRunningCalculation(); }
   }
}

আমি দেখতে পাই যে এই ক্ষেত্রেগুলির জন্য পদ্ধতিগুলি ব্যবহার করা একটি পার্থক্য তৈরি করতে সহায়তা করে।

দ্বিতীয়ত এবং আরও গুরুত্বপূর্ণ, ডিবাগ করার সময় আপনি যদি সেগুলি মূল্যায়ন করেন তবে বৈশিষ্ট্যের পার্শ্ব-প্রতিক্রিয়া থাকতে পারে।

বলুন আপনার মতো কিছু সম্পত্তি আছে:

public int Result 
{ 
   get 
   { 
       m_numberQueries++; 
       return m_result; 
   } 
}

এখন ধরুন আপনার একটি ব্যতিক্রম রয়েছে যা ঘটে যখন অনেকগুলি প্রশ্ন করা হয়। অনুমান করুন যখন আপনি ডিবাগিংয়ের মধ্যে সম্পত্তিটি ডিবাগিং এবং রোলওভার শুরু করবেন তখন কি হবে? খারাপ জিনিসগুলো. এটি করা থেকে বিরত থাকুন! সম্পত্তির দিকে তাকানো প্রোগ্রামের অবস্থা পরিবর্তন করে।

এই আমার একমাত্র সতর্কবাণী। আমি মনে করি সম্পত্তিগুলির সুবিধাগুলি সমস্যাগুলির চেয়ে অনেক বেশি।

Answer 7

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

Comments

ক্লায়েন্ট এবং শ্রেণীর সম্পত্তির মধ্যে "চুক্তি" এর গুরুত্বকে নিখুঁতভাবে তুলে ধরার জন্য +1।

— দ্য ব্লাস্টঅন

Answer 8

আমি জেফ্রি রিখটারের মতামতের বিশদটি বাছাইয়ে সহায়তা করতে পারি না:

একটি সম্পত্তি কেবল পঠনযোগ্য বা কেবল লেখার জন্য হতে পারে; ক্ষেত্রের অ্যাক্সেস সর্বদা পঠনযোগ্য এবং লিখনযোগ্য।

ভুল: ক্ষেত্রগুলি কেবল পঠনযোগ্য হিসাবে চিহ্নিত করতে পারে তাই কেবলমাত্র অবজেক্টের নির্মাতারা তাদের লিখতে পারেন।

একটি সম্পত্তি পদ্ধতি একটি ব্যতিক্রম নিক্ষেপ করতে পারে; ক্ষেত্রের অ্যাক্সেস কখনই ব্যতিক্রম ছুঁড়ে না ফেলে।

ভুল: একটি শ্রেণীর প্রয়োগের ফলে ক্ষেত্রের অ্যাক্সেস মডিফায়ারটিকে জনসাধারণ থেকে বেসরকারীতে পরিবর্তন করা যেতে পারে। রানটাইমের সময় ব্যক্তিগত ক্ষেত্রগুলি পড়ার প্রচেষ্টা সর্বদা একটি ব্যতিক্রমের ফলস্বরূপ।

Answer 9

আমি জেফ্রি রিখারের সাথে একমত নই, তবে কেন তিনি সম্পত্তি পছন্দ করেন না তা আমি অনুমান করতে পারি (আমি তার বইটি পড়িনি)।

যদিও শ্রেণীর ব্যবহারকারী হিসাবে বৈশিষ্ট্যগুলি হ'ল পদ্ধতিগুলির (প্রয়োগ-ভিত্তিক) মতো, আমি প্রত্যাশা করি যে এর বৈশিষ্ট্যগুলি একটি সর্বজনীন ক্ষেত্রের মতো "কমবেশি" আচরণ করবে, যেমন:

• সম্পত্তি গেটর / সেটারের অভ্যন্তরে কোনও সময়সাপেক্ষ অপারেশন চলছে না
• সম্পত্তি প্রাপ্তির কোনও পার্শ্ব প্রতিক্রিয়া নেই (এটিকে একাধিকবার কল করা, ফলাফল পরিবর্তন করে না)

দুর্ভাগ্যক্রমে, আমি এমন বৈশিষ্ট্য দেখেছি যা সেভাবে আচরণ করে না। তবে সমস্যাটি তাদের নিজস্ব সম্পত্তি নয়, যারা এগুলি প্রয়োগ করেছিলেন। সুতরাং এটি শুধু কিছু শিক্ষা প্রয়োজন।

Comments

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

— দ্য ব্লাস্টঅন

Answer 10

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

Answer 11

আপনার এগুলি ব্যবহার এড়ানো উচিত নয় তবে অন্যান্য অবদানকারীদের দেওয়া কারণগুলির জন্য আপনার এগুলি যোগ্যতা এবং যত্ন সহ ব্যবহার করা উচিত।

আমি একবার গ্রাহকদের মতো এমন একটি সম্পত্তি দেখেছি যা অভ্যন্তরীণভাবে একটি ডাটাবেসে প্রসেস কল করে এবং গ্রাহক তালিকাটি পড়ে। ক্লায়েন্ট কোডটিতে একটি 'for (গ্রাহকগণের জন্য আইটেম) ছিল' যা প্রতিটি পুনরাবৃত্তির উপর এবং নির্বাচিত গ্রাহকের অ্যাক্সেসের জন্য ডাটাবেসে পৃথক কল সৃষ্টি করে। এটি একটি বিস্ময়কর উদাহরণ যা সম্পত্তি খুব হালকা রাখার নীতি প্রদর্শন করে - অভ্যন্তরীণ ক্ষেত্রের অ্যাক্সেসের চেয়ে কমই বেশি।

বৈশিষ্ট্যগুলি ব্যবহারের জন্য একটি যুক্তি হ'ল তারা আপনাকে সেট করা মানটি বৈধ করার অনুমতি দেয়। অন্যটি হ'ল সম্পত্তির মান টোটালভ্যালু = পরিমাণ * পরিমাণের মতো একক ক্ষেত্র নয়, একটি উত্পন্ন মান হতে পারে।

Answer 12

সাধারণভাবে / সেট সেট পদ্ধতিগুলি তৈরি করার সময় আমি ব্যক্তিগতভাবে আমি বৈশিষ্ট্যগুলি ব্যবহার করি। জটিল ডাটা স্ট্রাকচারে আসার সময় আমি এ থেকে দূরে সরে যাই।

Answer 13

যুক্তি অনুমান করে যে সম্পত্তিগুলি খারাপ কারণ তারা ক্ষেত্রগুলির মতো দেখায়, কিন্তু আশ্চর্যজনক ক্রিয়া করতে পারে। এই অনুমানটি। নেট প্রোগ্রামারদের প্রত্যাশা দ্বারা অবৈধ হয়:

সম্পত্তিগুলি ক্ষেত্রগুলির মতো দেখায় না। ক্ষেত্রগুলি বৈশিষ্ট্যের মতো দেখায়।

Property একটি সম্পত্তি পদ্ধতি একটি ব্যতিক্রম নিক্ষেপ করতে পারে; ক্ষেত্রের অ্যাক্সেস কখনই ব্যতিক্রম ছুঁড়ে না ফেলে।

সুতরাং, ক্ষেত্রটি এমন সম্পত্তির মতো যা কখনও ব্যতিক্রম ছুঁড়ে ফেলার গ্যারান্টিযুক্ত।

• সম্পত্তি কোনও পদ্ধতিতে আউট বা রেফ প্যারামিটার হিসাবে পাস করা যায় না; একটি ক্ষেত্র পারেন।

সুতরাং, ক্ষেত্রটি একটি সম্পত্তির মতো, তবে এটির অতিরিক্ত ক্ষমতাও রয়েছে: একটি ref/ outগ্রহণযোগ্য পদ্ধতিতে চলে।

Property একটি সম্পত্তি পদ্ধতি কার্যকর করতে দীর্ঘ সময় নিতে পারে; ক্ষেত্রের অ্যাক্সেস সর্বদা অবিলম্বে সম্পূর্ণ হয়। [...]

সুতরাং, একটি ক্ষেত্র দ্রুত সম্পত্তির মতো।

A একটানা একাধিক বার বলা হয়ে থাকে, সম্পত্তি সম্পত্তি প্রতিটি সময় একটি পৃথক মান ফিরে আসতে পারে; একটি ক্ষেত্র প্রতিটি সময় একই মান প্রদান করে। সিস্টেম.ডেটটাইম শ্রেণিতে একটি পঠনযোগ্য এখন সম্পত্তি রয়েছে যা বর্তমান তারিখ এবং সময়কে দেয়।

সুতরাং, ক্ষেত্রটি এমন একটি সম্পত্তির মতো যা ক্ষেত্রটি অন্য কোনও মানকে সেট না করা হলে একই মান ফেরত দেওয়ার গ্যারান্টিযুক্ত।

Property একটি সম্পত্তি পদ্ধতি পর্যবেক্ষণযোগ্য পার্শ্ব প্রতিক্রিয়া হতে পারে; ক্ষেত্র অ্যাক্সেস কখনও না।

আবার কোনও ক্ষেত্র এমন একটি সম্পত্তি যা এটি না করার গ্যারান্টিযুক্ত।

Property কোনও সম্পত্তি পদ্ধতির জন্য অতিরিক্ত মেমরির প্রয়োজন হতে পারে বা এমন কোনও জিনিসের রেফারেন্স ফিরে আসতে পারে যা আসলে বস্তুর রাজ্যের অংশ নয়, সুতরাং প্রত্যাবর্তিত বস্তুকে সংশোধন করা মূল বস্তুর উপর কোনও প্রভাব ফেলবে না; ক্ষেত্রটি জিজ্ঞাসা করা সর্বদা কোনও অবজেক্টের রেফারেন্স দেয় যা মূল বস্তুর অবস্থার অংশ হিসাবে গ্যারান্টিযুক্ত। কোনও অনুলিপি প্রদান করে এমন কোনও সম্পত্তি নিয়ে কাজ করা বিকাশকারীদের কাছে খুব বিভ্রান্তিকর হতে পারে এবং এই বৈশিষ্ট্যটি প্রায়শই নথিভুক্ত হয় না।

এটি আশ্চর্যজনক হতে পারে তবে এটি এমন কোনও সম্পত্তি যা এটি করে। বরং, এটি কেবল যে কেউ সম্পত্তিতে পরিবর্তনীয় অনুলিপিগুলি ফিরিয়ে দেয়, যাতে 0.1% কেস অবাক করে।

Answer 14

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

জাভাতে সি # এর অন্যতম প্রধান সুবিধা বৈশিষ্ট্য এবং সূচকগুলির জন্য সমর্থন।