C# 8 - নালেবল রেফারেন্স টাইপস

মাইক্রোসফট C# 8-এ Nullable Reference Types নামক একটি নতুন ফিচার যোগ করছে। যা প্রথমে বিভ্রান্তিকর কারণ সমস্ত রেফারেন্স টাইপ নালেবল… তাহলে এটি কীভাবে আলাদা? এগিয়ে যাওয়ার সময়, যদি ফিচারটি সক্ষম করা হয়, রেফারেন্স টাইপগুলি নন-নালেবল, যদি না আপনি স্পষ্টভাবে সেগুলিকে নালেবল হিসাবে চিহ্নিত করেন।

আমাকে ব্যাখ্যা করতে দিন।

নালেবল রেফারেন্স টাইপস

যখন নালেবল রেফারেন্স টাইপস সক্ষম করা হয় এবং কম্পাইলার বিশ্বাস করে যে একটি রেফারেন্স টাইপ নাল হওয়ার সম্ভাবনা রয়েছে, এটি আপনাকে সতর্ক করে। আপনি ভিজ্যুয়াল স্টুডিও থেকে সতর্কতা বার্তা দেখতে পাবেন:

এবং বিল্ড সতর্কতা:

এই সতর্কতা সরাতে, রেফারেন্স টাইপের পিছনে একটি প্রশ্ন চিহ্ন যোগ করুন। উদাহরণস্বরূপ:

public string StringTest()
{
    string? notNull = null;
    return notNull;
}

এখন রেফারেন্স টাইপ C# 8 এর আগে যেভাবে আচরণ করেছিল তার মতো আচরণ করে।

এই ফিচারটি যেকোনো C# ফাইলের শীর্ষে <span class="inline-code"> #nullable enable </span> যোগ করে বা .csproj ফাইলে <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> যোগ করে সক্ষম করা হয়। বাক্সের বাইরে এটি সক্ষম নয়, যা একটি ভাল জিনিস কারণ যদি এটি সক্ষম করা হয় তবে যেকোনো বিদ্যমান কোডবেস সম্ভবত ক্রিসমাস ট্রির মতো জ্বলে উঠবে।

নাল বিতর্ক

মাইক্রোসফট এখন এই ফিচারটি কেন যোগ করছে? নালগুলি ভাষার অংশ হয়েছে, ভালো, শুরু থেকেই? সৎভাবে, আমি জানি না কেন। আমি সর্বদা নালগুলি ব্যবহার করেছি, এটি C#-এ জীবনের একটি বাস্তবতা। আমি বুঝতে পারিনি যে নালগুলি না থাকা একটি বিকল্প ছিল… হয়তো জীবন তাদের ছাড়াই আরও ভাল হবে। আমরা খুঁজে বের করব।

আপনার নালগুলি ব্যবহার করা উচিত নাকি উচিত নয়? আমি চলমান বিতর্কটি সংক্ষিপ্ত করেছি যেমনটি আমি বুঝি।

পক্ষে

নালগুলির জন্য যুক্তি সাধারণত যে একটি অবজেক্টের একটি অজানা অবস্থা রয়েছে। এই অজানা অবস্থা নাল দিয়ে প্রতিনিধিত্ব করা হয়। আপনি এটি SQL Server-এ বিট ডেটা টাইপের সাথে দেখেন, যার 3টি মান রয়েছে, নাল (সেট করা হয়নি), 0 এবং 1। আপনি এটি UI-তেও দেখেন, যেখানে কখনও কখনও একজন ব্যবহারকারী একটি ফিল্ড স্পর্শ করেছে কিনা তা জানা গুরুত্বপূর্ণ। কেউ কেউ বলতে পারে, “নালের পরিবর্তে, কেন একটি অজানা অবস্থা টাইপ বা একটি ‘সেট করা হয়নি’ অবস্থা তৈরি করবেন না?” এটি নালের থেকে কীভাবে আলাদা? আপনাকে এখনও এই অতিরিক্ত অবস্থার জন্য পরীক্ষা করতে হবে। এখন আপনি প্রতিটি উদাহরণের জন্য অজানা অবস্থা তৈরি করছেন। কেন শুধু নাল ব্যবহার করবেন না এবং একটি গ্লোবাল অজানা অবস্থা থাকবেন না?

বিপক্ষে

নালগুলির বিরুদ্ধে যুক্তি হল এটি একটি ভিন্ন ডেটা টাইপ এবং আপনি প্রতিটি সময় একটি রেফারেন্স টাইপ ব্যবহার করার সময় এটির জন্য পরীক্ষা করতে হবে। নেট ফলাফল এই মতো কোড:

var user = GetUser(username, password);

if(user != null)
{
    DoSomethingWithUser(user);
} else 
{
    SetUserNotFoundErrorMessage()
}

যদি GetUser পদ্ধতি সমস্ত ক্ষেত্রে একজন ব্যবহারকারী ফেরত দেয়, যার মধ্যে ব্যবহারকারী পাওয়া যায় না। যদি কোড কখনও নাল ফেরত না দেয়, তবে এটির বিরুদ্ধে রক্ষা করা একটি বর্জ্য এবং আদর্শভাবে, এটি কোডটি সরল করে। তবে, কোনো সময়ে, আপনাকে একটি খালি ব্যবহারকারীর জন্য পরীক্ষা করতে হবে এবং একটি ত্রুটি বার্তা প্রদর্শন করতে হবে। নাল ব্যবহার না করা ব্যবহারকারী পাওয়া যায় না এমন ব্যবসায়িক ক্ষেত্রের প্রয়োজন দূর করে না।

এই ফিচারটি কি একটি ভাল ধারণা?

এই ফিচারের উদ্দেশ্য নালগুলির ব্যবহার দূর করা নয়, বরং প্রশ্ন জিজ্ঞাসা করা: “কি একটি ভাল উপায় আছে?” এবং কখনও কখনও উত্তর হল “না”। যদি আমরা একটু দূরদর্শিতার সাথে নালগুলির জন্য ক্রমাগত পরীক্ষা দূর করতে পারি, যা পরিবর্তে আমাদের কোডটি সরল করে। আমি আছি। ভাল খবর হল C# নালগুলির সাথে কাজ করা তুচ্ছ করেছে।

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

নালেবল রেফারেন্স টাইপস কি একটি ভাল ধারণা? এটি হল, যদি চূড়ান্ত ফলাফল সরল এবং কম ত্রুটি প্রবণ কোড হয়।