স্থাবরতার গ্যারান্টি দেওয়া কি কোনও সম্পত্তির পরিবর্তে ক্ষেত্রটি উন্মোচনের যৌক্তিকতা?


10

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

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

সুতরাং স্থায়ীত্বের নিশ্চয়তা readonlyকিছু ক্ষেত্রে কোনও সম্পত্তির উপর দিয়ে ক্ষেত্রটি বেছে নেওয়ার বৈধ কারণ ?

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



1
@ জাগান কেবল স্পষ্ট করে বলার জন্য, "রিডইনলি প্রপার্টি" তারা ভিবি.এনইটি টার্মিনোলজি ব্যবহার করছে যার অর্থ কোন সেটার ছাড়া সম্পত্তি, কেবল পাঠ্য ক্ষেত্র নয় not আমার প্রশ্নের উদ্দেশ্যগুলির জন্য, প্রশ্নটি যে দুটি বিকল্পের সাথে তুলনা করে সেগুলি সমতুল্য - তারা উভয়ই সম্পত্তি ব্যবহার করছে।
বেন অ্যারনসন

উত্তর:


6

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

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

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

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

  1. যে কোনও কিছু of অবজেক্টের সদস্যকে লেখেন, যেমন: ক্ষেত্র object.Location.X = 4হলেই কেবল সম্ভব Location। এটি পঠনযোগ্য ক্ষেত্রের জন্য যদিও প্রাসঙ্গিক নয়, কারণ আপনি কেবলমাত্র পঠনীয় কাঠামোটি সংশোধন করতে পারবেন না। (এটি ধরে নেওয়া Locationহচ্ছে একটি মান ধরণের - যদি তা না হয় তবে এই সমস্যাটি যে কোনও উপায়ে প্রযোজ্য হবে না কারণ readonlyএই ধরণের জিনিস থেকে রক্ষা করে না))
  2. একটি পদ্ধতি যে মান পাসের কোন কল outবা ref। আবার, এই একটি কেবলমাত্র ক্ষেত্রের জন্য সত্যিই প্রাসঙ্গিক কারণ নয়, outএবং refপরামিতি পরিবর্তন করা পেতে ঝোঁক, এবং এটি বা সুত্র হিসাবে একটি কেবলমাত্র মান প্রেরণ করতে একটি কম্পাইলার ত্রুটি যাহাই হউক না কেন।

অন্য কথায়, যদিও কেবলমাত্র পঠনযোগ্য ক্ষেত্রকে কেবলমাত্র পঠনযোগ্য বৈশিষ্ট্যে রূপান্তর করা বাইনারি সামঞ্জস্যকে ভেঙে দেয়, অন্য উত্স কোডটি কেবল এই পরিবর্তনটি পরিচালনা করতে কোনও পরিবর্তন ছাড়াই পুনরায় সংযুক্ত করা দরকার। এটি গ্যারান্টিটি ভঙ্গ করা সত্যিই সহজ করে তোলে।

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


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

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

2

আমার অভিজ্ঞতা থেকে, মূল readonlyশব্দটি যাদু করার প্রতিশ্রুতি দেয় না।

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

পরে, বর্গ আরও জটিল হয়ে ওঠে এবং এর নির্মাতাও। (আসুন আমরা এটি এমন একটি প্রকল্পে ঘটে যা পরীক্ষামূলক হয় বা তার পরিধি / নিয়ন্ত্রণের বাইরে প্রচুর গতিবেগ জুম হয় তবে আপনার এটি কোনওরকমভাবে কাজ করা দরকার)) আপনি দেখতে পাবেন যে ক্ষেত্রগুলি readonlyকেবল কনস্ট্রাক্টরের অভ্যন্তরে পরিবর্তিত হতে পারে - আপনি পদ্ধতিতে এটি পরিবর্তন করতে পারে না এমনকি যদি সেই পদ্ধতিটি কেবল কোনও নির্মাণকারী থেকে বলা হয়।

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

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


1
আমি কনস্ট্রাক্টরদের সহজ রাখতে পছন্দ করি - brendan.enrick.com/post/… , blog.ploeh.dk/2011/03/03/InicationConstructorsShotbesimple তাই বাস্তবে , পাঠ্যভাবে ভাল কোডিং স্টাইলকে উত্সাহ দেয়
আলেক্সফক্সগিল

1
একজন কনস্ট্রাক্টর readonlyফিল্ডকে অন্য পদ্ধতিতে outবা refপরামিতি হিসাবে পাস করতে পারে , যা তারা উপযুক্ত দেখায় এটি পরিবর্তন করতে পারে।
সুপারক্যাট

1

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

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

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

আমরা ভাষার সাথে কিছু করতে পারি বলেই এর অর্থ এই নয় যে ভাষা নিয়ে আমাদের কিছু করা উচিত

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


1
আমি ভবিষ্যতের নমনীয়তায় বিল্ডিংয়ের গুরুত্ব বুঝতে পারি, তবে অবশ্যই আমি যদি Rationalজনসাধারণের, অপরিবর্তনীয় NumeratorDenominatorসদস্যদের মতো একটি ক্লাস লিখি , আমি নিশ্চিত হতে পারি যে এই সদস্যদের অলস-লোডিং বা হিট কাউন্টারের প্রয়োজন হবে না বা অনুরূপ?
বেন অ্যারনসন

কিন্তু আপনি যে ব্যবহার বাস্তবায়ন নিশ্চিত থাকতে পারি floatজন্য ধরনের Numeratorএবং Denominatorপরিবর্তন করা প্রয়োজন হবে না doubles?
স্টিফেন

1
ওয়েল, Er, না, তারা স্পষ্টভাবে হওয়া উচিত তন্ন তন্ন floatনা double। তারা হওয়া উচিত int, longবা BigInteger। হতে পারে তাদের বদলাতে হবে ... তবে যদি তাদের জনসাধারণের ইন্টারফেসেও পরিবর্তন করতে হয়, তাই প্রকৃতপক্ষে বৈশিষ্ট্যগুলি ব্যবহার করা হলে সেই বিশদটি কোনও এনক্যাপসুলেশন যুক্ত করে না।
বেন অ্যারনসন

-3

না এটি ন্যায়সঙ্গত নয়।

অযৌক্তিকতা হিসাবে অকারণীয়তার গ্যারান্টি হিসাবে পাঠ্যকে ব্যবহার করা আরও একটি হ্যাকের মতো।

পঠনের অর্থ হ'ল ভেরিয়েবলটি সংজ্ঞায়িত করা হলে নির্ধারক দ্বারা মান নির্ধারিত হয়।

আমি মনে করি এটি একটি খারাপ অভ্যাস হবে

আপনি যদি সত্যিই গ্যারান্টিটি অপরিবর্তনীয়তার ইন্টারফেসটি ব্যবহার করতে চান তবে এতে কনস থেকে বেশি সুবিধা রয়েছে।

সাধারণ ইন্টারফেস উদাহরণ: এখানে চিত্র বর্ণনা লিখুন


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