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

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

আমি ব্যাখ্যা করি।

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

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

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

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

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#-এর অবিচ্ছেদ্য অংশ।

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