অপরিবর্তনীয় বস্তুর জন্য ইন্টারফেস ঘোষণা করবেন না

Question

অপরিবর্তনীয় বস্তুর জন্য ইন্টারফেস ঘোষণা করবেন না

[সম্পাদনা] যেখানে প্রশ্নে থাকা বস্তুগুলি ডেটা ট্রান্সফার অবজেক্টস (ডিটিও) বা সাধারণ পুরানো ডেটা (পিওডি) প্রতিনিধিত্ব করে

এটি কি যুক্তিসঙ্গত গাইডলাইন?

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

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

এই সমস্যার কারণে, আমি কখনও পরিবর্তনযোগ্য বস্তুর জন্য ইন্টারফেস ঘোষণার বিষয়টি বিবেচনা করছি।

ইউনিট টেস্টিংয়ের ক্ষেত্রে এটির র্যামফিকেশন থাকতে পারে তবে এটির চেয়েও কি এটিকে যুক্তিসঙ্গত গাইডলাইন বলে মনে হচ্ছে?

বা "স্প্রেডিং-ইন্টারফেস" সমস্যাটি এড়াতে আমার অন্য প্যাটার্নটি ব্যবহার করা উচিত?

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

[Edit]

অবজেক্টগুলি অপরিবর্তনীয় করে তুলতে চাওয়ার জন্য আমার আরও অনেক প্রসঙ্গ সরবরাহ করতে, এরিক লিপার্টের এই ব্লগ পোস্টটি দেখুন:

http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/

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

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

---

অনুসরণ করুন

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

এ সম্পর্কিত আরও কিছু সমস্যা রয়েছে যা সম্পর্কে আমি জানতে চাই; লক্ষণীয় যে কোনও কিছুকে আমি "গভীর বা অগভীর অপ্রয়োজনীয়তা" বলছি (নামটি আমি ডিপ এবং শ্যালো ক্লোনিং থেকে চুরি করেছি) - তবে এটি অন্য সময়ের জন্য একটি প্রশ্ন।

Comments

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

— স্টিভেন ডগগার্ট

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

— স্টিভেন ডগগার্ট

আমি বিভ্রান্ত, কেন কেবল ইন্টারফেস বন্ধ সেটটার ছেড়ে না? কিন্তু অন্যদিকে, আমি সত্যই ডোমেন অবজেক্ট এবং / বা ডিটিওগুলির জন্য those অবজেক্টগুলির জন্য কারখানার প্রয়োজন হয় এমন অবজেক্টগুলির জন্য ইন্টারফেসগুলি দেখে আমার ক্লান্তি ঘটে ... আমার জন্য জ্ঞানীয় বিভেদ সৃষ্টি করে।

— মাইকেল ব্রাউন

যে সমস্ত ক্লাসগুলি অপরিবর্তনীয় তাদের ইন্টারফেস সম্পর্কে কী বলা যায় ? উদাহরণস্বরূপ, জাভার নম্বর বর্গ এক একটি সংজ্ঞায়িত করতে পারবেন List<Number>যা ধরে রাখতে পারেন Integer, Float, Long, BigDecimal, ইত্যাদি ... সবাই যার যা নিজেদের অপরিবর্তনীয় হয়।

@ মাইক্রব্রাউন আমি অনুমান করি যে ইন্টারফেসের ফলে অপরিবর্তনীয়তা বোঝায় কেবল বাস্তবায়ন এটি প্রয়োগ করে না। আপনি কেবল এটি কনভেনশন পর্যন্ত ছেড়ে দিতে পারেন (অর্থাত্ ইন্টারফেসটি ডকুমেন্ট করুন যে অপরিবর্তনীয়তা একটি প্রয়োজনীয়তা) তবে কেউ যদি কনভেনশন লঙ্ঘন করে তবে আপনি কিছু সত্যই বাজে বিষয় নিয়ে শেষ করতে পারেন।

— ওয়াঘানড্রয়েড

Answer 1

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

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

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

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

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

Comments

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

— সুপারক্যাট

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

— সুপারক্যাট

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

— কেভিন

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

— স্টিভেন ডগগার্ট

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

— স্টিভেন ডগগার্ট

Answer 2

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

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

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

Comments

আমি যখন ইউনিট পরীক্ষার জন্য নির্ভরতা ইনজেকশন প্রয়োজন তখন আমি সাধারণত ইন্টারফেসগুলি সংরক্ষণ করি।

— ট্র্যাভিস পার্কগুলি

Answer 3

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

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

Answer 4

কোডটি অনেক ক্ষেত্রে খুব সহজ হয়ে যায় যখন আপনি জানেন যে কোনও কিছু পরিবর্তনযোগ্য - যা আপনাকে কোনও ইন্টারফেস হস্তান্তরিত না হলে আপনি করেন না।

আমি মনে করি না যে এটি উদ্বেগ যা অ্যাক্সেসর প্রয়োগকারীকে উদ্বিগ্ন হতে হবে। যদি interface Xতা অপরিবর্তনীয় বলে বোঝানো হয়, তবে ইন্টারফেস বাস্তবায়নের দায় নয় যে তারা কোনও পরিবর্তনযোগ্য ফ্যাশনে ইন্টারফেসটি প্রয়োগ করে?

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

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

Comments

আপনি কি সাজসজ্জা হিসাবে অপরিবর্তনীয়তা প্রয়োগের উদাহরণ প্রদান করতে পারেন?

— ওয়াঘানড্রয়েড

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

— জোনাথন ধনী

সংকলন-সময় নিশ্চিতিকে আমি রান-টাইম ব্যতিক্রমের সম্ভাবনায় রূপান্তরিত করতে পছন্দ করি না ...

— ম্যাথু ওয়াটসন

ঠিক আছে, তবে কোনও প্রদত্ত পদ্ধতিতে রাষ্ট্রের পরিবর্তন হয়েছে কিনা তা ইমট্যুটেবল ডেকোরেটর কীভাবে জানতে পারে?

— ওয়াঘানড্রয়েড

আপনার ইন্টারফেস দ্বারা সংজ্ঞায়িত পদ্ধতিগুলির ক্ষেত্রে শ্রেনী যা আপনার ইন্টারফেস প্রয়োগ করে তা অবিচ্ছিন্ন হলে আপনি কোনও অবস্থাতেই নিশ্চিত হতে পারবেন না। @ বাউকেটা সাজসজ্জারকে বেস ক্লাস বাস্তবায়নের জ্ঞান থাকতে হবে।

— জোনাথন ধনী

Answer 5

আপনি একটি ইন্টারফেসটি পাস করার সময় শেষ হয়ে যান এবং তারপরে এটি এমন কোনও কোডে পাস করতে চান যা সত্যিই ধরে নিতে চায় যে জিনিসটি এতে প্রেরণ করা যাচ্ছে তা স্থাবর নয়।

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

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

এবার এরিকের নকশায় লেগে থাকি। যে পদ্ধতিতে অপরিবর্তনীয় স্ট্যাকের প্রয়োজন হয় Stack<T>তার সাধারণ ইন্টারফেসের চেয়ে ধরণের পরামিতি থাকতে হবে IStack<T>যা সাধারণ অর্থে স্ট্যাকের বিমূর্ত তথ্য প্রকারের প্রতিনিধিত্ব করে। এরিকের অপরিবর্তনীয় স্ট্যাক ব্যবহার করার সময় এটি কীভাবে করা যায় তা স্পষ্ট নয় এবং তিনি তার নিবন্ধগুলিতে এটি নিয়ে আলোচনা করেননি, তবে এটি সম্ভব। সমস্যাটি খালি স্ট্যাকের ধরণের সাথে। আপনি কখনও খালি স্ট্যাক পাবেন না তা নিশ্চিত করে আপনি এই সমস্যাটি সমাধান করতে পারেন। এটি স্ট্যাকের প্রথম মান হিসাবে একটি ডামি মানকে চাপ দিয়ে এবং কখনই পপিংয়ের মাধ্যমে নিশ্চিত করা যায়। এই ভাবে, আপনি নিরাপদে ফলাফল কাস্ট করতে পারেন Pushএবং Popকরতে Stack<T>।

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

অপরিবর্তনীয় স্ট্যাকের বিকল্প নকশা এবং প্রয়োগের বিষয়ে আমি আগে উল্লেখ করেছি যা একটি ইন্টারফেস বলে IImmutableStack<T>। অবশ্যই, ইন্টারফেসের নামটিতে "অপরিবর্তনীয়" সন্নিবেশ করানো এমন প্রতিটি ধরণের তৈরি করে না যা এটি অপরিবর্তনীয় করে তোলে। যাইহোক, এই ইন্টারফেসে, অপরিবর্তনীয়তা চুক্তিটি কেবল মৌখিক। একজন ভাল বিকাশকারী এটি সম্মান করা উচিত।

আপনি যদি একটি ছোট, অভ্যন্তরীণ লাইব্রেরি বিকাশ করছেন তবে আপনি এই চুক্তিকে সম্মান জানাতে দলের প্রত্যেকের সাথে একমত হতে পারেন এবং আপনি IImmutableStack<T>পরামিতিগুলির ধরণ হিসাবে ব্যবহার করতে পারেন । অন্যথায়, আপনার ইন্টারফেসের ধরণটি ব্যবহার করা উচিত নয়।

আমি যুক্ত করতে চাই, যেহেতু আপনি প্রশ্ন # # ট্যাগ করেছেন, যে সি # স্পেসিফিকেশনে, ডিটিও এবং পিওডি-তে কোনও জিনিস নেই। অতএব, তাদের ত্যাগ করা বা তাদের সঠিকভাবে সংজ্ঞা দেওয়া প্রশ্নকে উন্নত করে।