সুইচ স্টেটমেন্টের জন্য কেস পরীক্ষা করা

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

১৯৫২ সালে, স্টিফেন ক্লিন তার পেপার ইন্ট্রোডাকশন টু মেটামেথেমেটিক্স-এ সুইচ স্টেটমেন্ট তৈরি করেছিলেন। প্রথম উল্লেখযোগ্য বাস্তবায়ন ছিল ১৯৫৮ সালে ALGOL 58-এ। পরবর্তীতে, সুইচ স্টেটমেন্ট অন্তর্ভুক্ত করা হয়েছিল C প্রোগ্রামিং ভাষায়, যা আমরা জানি, বেশিরভাগ আধুনিক প্রোগ্রামিং ভাষাকে প্রভাবিত করেছে।

বর্তমান সময়ে দ্রুত এগিয়ে যান এবং প্রায় প্রতিটি ভাষার একটি সুইচ স্টেটমেন্ট রয়েছে। তবে, কয়েকটি ভাষা সুইচ স্টেটমেন্ট বাদ দিয়েছে। সবচেয়ে উল্লেখযোগ্য হল Smalltalk।

এটি আমার কৌতূহল জাগিয়ে তুলেছে, কেন সুইচ স্টেটমেন্ট Smalltalk থেকে বাদ দেওয়া হয়েছিল?

Andy Bower, Dolphin Smalltalk-এর পিছনে একজন সৃষ্টিকর্তা/সমর্থক, Smalltalk কেন সুইচ স্টেটমেন্ট বাদ দিয়েছে তার উপর তার চিন্তাভাবনা শেয়ার করেছেন:

যখন আমি প্রথম C++ থেকে Smalltalk-এ এসেছিলাম, আমি বুঝতে পারিনি কীভাবে একটি সম্পূর্ণ ভাষা একটি সুইচ/কেস কনস্ট্রাক্ট সমর্থন করে না। সর্বোপরি যখন আমি প্রথম BASIC থেকে “স্ট্রাকচার্ড প্রোগ্রামিং”-এ উঠেছিলাম তখন আমি মনে করেছিলাম যে সুইচ স্লাইসড ব্রেডের পর থেকে সেরা জিনিসগুলির মধ্যে একটি। তবে, কারণ Smalltalk একটি সুইচ সমর্থন করে না, আমাকে এই ঘাটতি কাটিয়ে উঠার উপায় খুঁজে বের করতে এবং বুঝতে হয়েছিল। সঠিক উত্তর হল, অবশ্যই, পলিমরফিজম ব্যবহার করা এবং অবজেক্টগুলিকে নিজেদেরকে সঠিক কোডে ডিসপ্যাচ করতে দেওয়া। তখন আমি বুঝতে পেরেছিলাম যে এটি একটি “ঘাটতি” নয়, বরং Smalltalk আমাকে C++-এ যা অভ্যস্ত হয়েছিলাম তার চেয়ে অনেক বেশি সূক্ষ্ম-দানাদার OOP ডিজাইনে বাধ্য করছিল। যদি একটি সুইচ স্টেটমেন্ট উপলব্ধ থাকত তবে এটি শিখতে আমার অনেক বেশি সময় লাগত বা, আরও খারাপ, আমি এখনও Smalltalk-এ C++/Java সিউডো-অবজেক্ট স্টাইলে প্রোগ্রামিং করছি।
আমি যুক্তি দিতে চাই যে সাধারণ OOP-এ সুইচ স্টেটমেন্টের কোনো প্রকৃত প্রয়োজন নেই। কখনও কখনও, একটি অ-OOP বিশ্বের সাথে ইন্টারফেসিং করার সময় (যেমন WM_XXXX Windows বার্তা গ্রহণ এবং ডিসপ্যাচ করা যা অবজেক্ট নয় বরং শুধুমাত্র পূর্ণসংখ্যা), তখন একটি সুইচ স্টেটমেন্ট উপকারী হবে। এই পরিস্থিতিতে, বিকল্প রয়েছে (যেমন একটি Dictionary থেকে ডিসপ্যাচ করা) এবং তারা যতবার দেখা দেয় তা অতিরিক্ত সিনট্যাক্স অন্তর্ভুক্ত করার ওয়ারেন্ট দেয় না।

Andy কি সঠিক ছিলেন? আমরা কি সুইচ স্টেটমেন্ট ছাড়াই ভালো আছি? অন্যান্য ভাষাগুলিও কি সুইচ স্টেটমেন্ট বাদ দিয়ে উপকৃত হবে?

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

প্রতিটি বাস্তবায়নের একটি পদ্ধতি রয়েছে যা একটি প্যারামিটার, একটি পূর্ণসংখ্যা নেয় এবং একটি স্ট্রিং প্রদান করে। আমরা সাইক্লোম্যাটিক জটিলতা এবং রক্ষণাবেক্ষণযোগ্যতা সূচক ব্যবহার করব প্রতিটি বাস্তবায়ন পরীক্ষা করতে। আমরা তখন তিনটি বাস্তবায়নের একটি সামগ্রিক দৃষ্টিভঙ্গি নেব।

কোড।

সুইচ স্টেটমেন্ট

    public class SwitchWithFourCases
    {
        public string SwitchStatment(int color)
        {
            var colorString = "Red";

            switch (color)
            {
                case 1:
                    colorString = "Green";
                    break;

                case 2:
                    colorString = "Blue";
                    break;

                case 3:
                    colorString = "Violet";
                    break;

                case 4:
                    colorString = "Orange";
                    break;

            }

            return colorString;
        }
    }

ডিকশনারি

public class DictionaryWithFourItems
{ 
    public string Dictionary(int color)
    {
        var colorString = "Red";
        var colors = new Dictionary<int, string> {{1, "Green"}, {2, "Blue"}, {3, "Violet"}, {4, "Orange"}};
        var containsKey = colors.ContainsKey(color);
        if (containsKey)
        {
            colorString = colors[color];
        }

        return colorString;
    }
}

পলিমরফিজম

ইন্টারফেস

public interface IColor
{
    string ColorName { get; }
}

ফ্যাক্টরি

public class ColorFactory
{
    public string GetColor(int color)
    {
        IColor defaultColor = new RedColor();
        var colors = GetColors();
        var containsKey = colors.ContainsKey(color);
        if (containsKey)
        {
            var c = colors[color];
            return c.ColorName;
        }

        return defaultColor.ColorName;
    }

    private static IDictionary<int, IColor> GetColors()
    {
        return new Dictionary<int, IColor>
        {
            {1, new GreenColor()}, 
            {2, new BlueColor()}, 
            {3, new VioletColor()}, 
            {4, new OrangeColor()}, 
            {5, new MagentaColor()}
        };
    }
}

বাস্তবায়ন

public class BlueColor : IColor
{
    public string ColorName => "Blue";
}

public class RedColor : IColor
{
    public string ColorName => "Red";
}

public class GreenColor : IColor
{
    public string ColorName => "Green";
}

public class MagentaColor : IColor
{
    public string ColorName => "Magenta";
}

public class VioletColor : IColor
{
    public string ColorName => "Violet";
}

ফলাফল

আমি ফলাফলে ডুব দেওয়ার আগে, আসুন সাইক্লোম্যাটিক জটিলতা এবং রক্ষণাবেক্ষণযোগ্যতা সূচক সংজ্ঞায়িত করি:

• সাইক্লোম্যাটিক জটিলতা হল যুক্তি শাখার পরিমাপ। সংখ্যা যত কম, তত ভালো।
• রক্ষণাবেক্ষণযোগ্যতা সূচক কোডের রক্ষণাবেক্ষণযোগ্যতা পরিমাপ করে। এটি ০ এবং ১০০ এর মধ্যে একটি স্কেলে। সংখ্যা যত বেশি, তত ভালো।

আমরা প্রথমে সাইক্লোম্যাটিক জটিলতা পরীক্ষা করব।

সাইক্লোম্যাটিক জটিলতার ফলাফল সরল। ডিকশনারি বাস্তবায়ন সবচেয়ে সহজ। এর মানে এটি সেরা সমাধান? না, যেমন আমরা রক্ষণাবেক্ষণযোগ্যতা সূচক মূল্যায়ন করার সময় দেখব।

বেশিরভাগ মানুষ আমার মতো চিন্তা করবে, সর্বনিম্ন সাইক্লোম্যাটিক জটিলতা সহ বাস্তবায়ন সবচেয়ে রক্ষণাবেক্ষণযোগ্য — এটি অন্য কোনো উপায়ে কীভাবে হতে পারে?

আমাদের পরিস্থিতিতে, সর্বনিম্ন সাইক্লোম্যাটিক জটিলতা সহ বাস্তবায়ন সবচেয়ে রক্ষণাবেক্ষণযোগ্য নয়। প্রকৃতপক্ষে আমাদের পরিস্থিতিতে, এটি বিপরীত। সবচেয়ে জটিল বাস্তবায়ন সবচেয়ে রক্ষণাবেক্ষণযোগ্য! মন উড়ে গেছে!

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

কেন সবচেয়ে জটিল বাস্তবায়ন সবচেয়ে রক্ষণাবেক্ষণযোগ্য? এর উত্তর দিতে, আমাদের রক্ষণাবেক্ষণযোগ্যতা সূচক বুঝতে হবে।

রক্ষণাবেক্ষণযোগ্যতা সূচক ৪টি মেট্রিক্স নিয়ে গঠিত: সাইক্লোম্যাটিক জটিলতা, কোডের লাইন, মন্তব্যের সংখ্যা এবং Halstead ভলিউম। প্রথম তিনটি মেট্রিক্স তুলনামূলকভাবে সুপরিচিত, কিন্তু শেষটি, Halstead ভলিউম, তুলনামূলকভাবে অজানা। সাইক্লোম্যাটিক জটিলতার মতো, Halstead ভলিউম উদ্দেশ্যমূলকভাবে কোড জটিলতা পরিমাপ করার চেষ্টা করে।

সহজ কথায়, Halstead ভলিউম কোডে চলমান অংশের সংখ্যা (ভেরিয়েবল, সিস্টেম কল, গাণিতিক, কোডিং কনস্ট্রাক্ট ইত্যাদি) পরিমাপ করে। চলমান অংশের সংখ্যা যত বেশি, জটিলতা তত বেশি। চলমান অংশের সংখ্যা যত কম, জটিলতা তত কম। এটি ব্যাখ্যা করে কেন পলিমরফিক বাস্তবায়ন রক্ষণাবেক্ষণযোগ্যতা সূচকে উচ্চ স্কোর করে; ক্লাসগুলির কম বা কোনো চলমান অংশ নেই। Halstead ভলিউম দেখার আরেকটি উপায় হল এটি “চলমান অংশ” ঘনত্ব পরিমাপ করে।

সফটওয়্যার কী, যদি এটি পরিবর্তন না হয়? বাস্তব বিশ্বকে প্রতিফলিত করতে, আমরা পরিবর্তন প্রবর্তন করছি। আমি প্রতিটি বাস্তবায়নে একটি নতুন রঙ যোগ করেছি।

নীচে সংশোধিত ফলাফল রয়েছে।

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

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

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

Google-এর Jem Finch সুইচ স্টেটমেন্টের ত্রুটিগুলির উপর তার চিন্তাভাবনা শেয়ার করেছেন:

১. পলিমরফিক পদ্ধতি বাস্তবায়নগুলি লেক্সিক্যালি একে অপরের থেকে বিচ্ছিন্ন। ভেরিয়েবলগুলি যোগ করা, সরানো, সংশোধন করা যেতে পারে এবং সুইচ স্টেটমেন্টের অন্য শাখায় সম্পর্কিত কোডকে প্রভাবিত করার কোনো ঝুঁকি ছাড়াই।

২. পলিমরফিক পদ্ধতি বাস্তবায়নগুলি সঠিক স্থানে ফিরে আসার গ্যারান্টি দেয়, অনুমান করে যে তারা শেষ হয়। C/C++/Java-এর মতো ফল-থ্রু ভাষায় সুইচ স্টেটমেন্টগুলির জন্য একটি ত্রুটি-প্রবণ “break” স্টেটমেন্ট প্রয়োজন যাতে তারা সুইচের পরে স্টেটমেন্টে ফিরে আসে পরবর্তী কেস ব্লকের পরিবর্তে।

৩. একটি পলিমরফিক পদ্ধতি বাস্তবায়নের অস্তিত্ব কম্পাইলার দ্বারা প্রয়োগ করা যেতে পারে, যা একটি পলিমরফিক পদ্ধতি বাস্তবায়ন অনুপস্থিত থাকলে প্রোগ্রাম সংকলন করতে অস্বীকার করবে। সুইচ স্টেটমেন্টগুলি কোনো সম্পূর্ণতা পরীক্ষা প্রদান করে না।

৪. পলিমরফিক পদ্ধতি ডিসপ্যাচিং অন্যান্য সোর্স কোডে অ্যাক্সেস (বা পুনঃসংকলন) ছাড়াই সম্প্রসারণযোগ্য। একটি সুইচ স্টেটমেন্টে অন্য কেস যোগ করার জন্য মূল ডিসপ্যাচিং কোডে অ্যাক্সেস প্রয়োজন, শুধুমাত্র এক জায়গায় নয় বরং প্রতিটি জায়গায় যেখানে প্রাসঙ