OCP — নীতি, সম্প্রসারণের জন্য উন্মুক্ততা এবং পরিবর্তনের জন্য বন্ধত্ব

OCP (Open/Closed Principle) কী?

OCP (Open/Closed Principle) — সম্প্রসারণের জন্য উন্মুক্ততা এবং পরিবর্তনের জন্য বন্ধত্বের নীতি। ক্লাস, মডিউল এবং ফাংশনগুলো এমনভাবে ডিজাইন করা উচিত যাতে তাদের সোর্স কোড পরিবর্তন না করেই নতুন আচরণ যোগ করা যায়। সম্প্রসারণ ইনহেরিটেন্স, কম্পোজিশন বা ইন্টারফেস বাস্তবায়নের প্রতিস্থাপনের মাধ্যমে অর্জিত হয়।

বার্ট্রান্ড মেয়ার তার Object-Oriented Software Construction (1988) বইয়ে প্রথমবারের মতো ইনহেরিটেন্সের মাধ্যমে OCP বর্ণনা করেছিলেন: বেস ক্লাস অপরিবর্তিত থাকে, যখন সাবক্লাসগুলো তার আচরণ সম্প্রসারণ করে। OCP-এর আধুনিক ব্যাখ্যা, রবার্ট মার্টিন দ্বারা প্রস্তাবিত, পলিমরফিজম এবং ইন্টারফেসের উপর ভিত্তি করে: ইনহেরিটেন্সের পরিবর্তে অ্যাবস্ট্র্যাক্ট কন্ট্র্যাক্ট ব্যবহার করা হয়।

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

OCP-এর ভিত্তি হিসেবে পলিমরফিজম

পলিমরফিক OCP একটি কন্ট্র্যাক্ট সংজ্ঞায়িত করতে অ্যাবস্ট্র্যাক্ট ক্লাস বা ইন্টারফেস ব্যবহার করে। ক্লায়েন্ট কোড কংক্রিট বাস্তবায়ন না জেনেই অ্যাবস্ট্র্যাকশনের সাথে কাজ করে। নতুন কার্যকারিতা একই ইন্টারফেস বাস্তবায়নকারী একটি নতুন ক্লাস তৈরি করে যোগ করা হয় — বিদ্যমান কোডে একটি পরিবর্তন ছাড়াই। এটি সিস্টেমকে পরিবর্তনের প্রতি প্রতিরোধী এবং সম্প্রসারণের জন্য অনুমানযোগ্য করে তোলে।

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

কীভাবে উন্মুক্ততা এবং বন্ধত্বের নীতি বাস্তবায়ন করবেন

OCP বাস্তবায়ন পরিবর্তনযোগ্য আচরণকে অ্যাবস্ট্র্যাকশনে আলাদা করার মাধ্যমে শুরু হয়। যদি কোডে switch নির্মাণ বা if-else শৃঙ্খল কোনও অবজেক্টের প্রকার পরীক্ষা করে — এটি OCP প্রয়োগের সংকেত। প্রতিটি শর্ত শাখা সম্প্রসারণের সময় একটি নতুন শাখা যোগ করার প্রয়োজন হতে পারে।

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

একটি গুরুত্বপূর্ণ স্পষ্টীকরণ: পরিবর্তনের জন্য বন্ধত্ব পরম নয়। যদি একটি প্রয়োজনীয়তা পরিবর্তন নিজেই অ্যাবস্ট্র্যাকশন বা কন্ট্র্যাক্টকে প্রভাবিত করে — পরিবর্তন অনিবার্য। OCP বাস্তবায়নে পরিবর্তন থেকে রক্ষা করে, কন্ট্র্যাক্টে নয়। ভালো ডিজাইন ধরে নেয় যে কন্ট্র্যাক্ট স্থিতিশীল এবং বাস্তবায়ন পরিবর্তনশীল।

কোনও আর্কিটেকচারের OCP সামঞ্জস্য মূল্যায়ন করার সময়, সম্প্রসারণ পয়েন্টগুলো দেখা উপযোগী। প্রতিটি পয়েন্ট যেখানে ডেভেলপার নতুন প্রকারের জন্য if-else বা switch যোগ করে — অ্যাবস্ট্র্যাকশনের জন্য প্রার্থী। OCP অনুসারে ডিজাইন করা সিস্টেমের অনুমানযোগ্য সম্প্রসারণ পয়েন্ট থাকে: ডকুমেন্টেশন সহ ইন্টারফেস যা বলে "নতুন প্রকার যোগ করতে এই ইন্টারফেসটি বাস্তবায়ন করুন"। Android-এ, ViewModelProvider.Factory-এর সাথে Factory প্যাটার্ন একটি স্পষ্ট উদাহরণ — নতুন ViewModel প্রকার যোগ করার জন্য বিদ্যমান ফ্যাক্টরি পরিবর্তনের প্রয়োজন হয় না।

OCP-এর জন্য কৌশল এবং প্যাটার্ন

সবচেয়ে কার্যকর প্যাটার্ন মোবাইল ডেভেলপমেন্টে OCP মেনে চলার জন্য Strategy, Template Method, Decorator এবং Factory অন্তর্ভুক্ত। এদের প্রত্যেকটি ভিন্ন অবজেক্ট-ওরিয়েন্টেড ডিজাইন প্রক্রিয়ার মাধ্যমে বিদ্যমান কোড পরিবর্তন না করেই আচরণ সম্প্রসারণের সমস্যা সমাধান করে।

Strategy একটি সাধারণ ইন্টারফেসের মাধ্যমে তাৎক্ষণিকভাবে অ্যালগরিদম পরিবর্তন করার অনুমতি দেয়। iOS ডেভেলপমেন্টে, অ্যানিমেশন এবং ফর্ম বৈধতার জন্য কৌশল ব্যবহার করা হয়। Template Method বেস ক্লাসে অ্যালগরিদমের কাঠামো সংজ্ঞায়িত করে, এবং সাবক্লাসগুলো ধাপগুলো ওভাররাইড করে — সাধারণ কাঠামো কিন্তু ভিন্ন বিষয়বস্তু সহ স্ক্রিনের জন্য উপযুক্ত।

Decorator একটি অবজেক্টের ক্লাস পরিবর্তন না করেই গতিশীলভাবে আচরণ যোগ করে। Android-এ, Decorator ক্যাশিং বা লগিং স্তর দিয়ে Repository মোড়ানোর জন্য ব্যবহৃত হয়। Factory Method ইন্টারফেসের মাধ্যমে অবজেক্ট তৈরি করে, যা সাবক্লাসগুলোকে সিদ্ধান্ত নিতে দেয় কোন ক্লাস ইনস্ট্যানশিয়েট করতে হবে — OCP-সামঞ্জস্যপূর্ণ নির্ভরতা তৈরির ভিত্তি।

মোবাইল প্রকল্পের জন্য কৌশল নির্বাচন

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

OCP ছাড়া এই প্যাটার্নগুলো প্রয়োগ করা প্রযুক্তিগতভাবে সম্ভব কিন্তু অর্থ হারায়। এটি OCP-ই ন্যায্যতা দেয় কেন আমরা অ্যাবস্ট্র্যাকশনের একটি অতিরিক্ত স্তর প্রবর্তন করি: যাতে সিস্টেম বিদ্যমান কোড পুনরায় লেখা ছাড়াই বাড়তে পারে।

মোবাইল অ্যাপ্লিকেশনে OCP-এর উদাহরণ

পেমেন্ট প্রসেসিং সহ একটি Android উদাহরণ বিবেচনা করুন। OCP ছাড়া, প্রতিটি নতুন পেমেন্ট সিস্টেমের জন্য হ্যান্ডলার ক্লাসে পরিবর্তন প্রয়োজন। OCP-এর সাথে, বিদ্যমান কোড পরিবর্তন না করেই একটি নতুন ইন্টারফেস বাস্তবায়ন যোগ করা হয়।

// OCP লঙ্ঘন: নতুন সিস্টেম যোগ করার সময় switch-এ পরিবর্তন প্রয়োজন
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // কার্ড প্রসেসিং
            "paypal" -> // PayPal প্রসেসিং
        }
    }
}

// OCP-সামঞ্জস্যপূর্ণ ডিজাইন
interface PaymentMethod {
    fun pay(amount: Double)
}

class CardPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

class PayPalPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

// নতুন সিস্টেম — নতুন ক্লাস, বিদ্যমান কোড পরিবর্তন না করে
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

টেক্সট ফিল্ড বৈধতা সহ একটি iOS উদাহরণ Swift প্রোটোকলের মাধ্যমে একই যুক্তি প্রদর্শন করে:

// OCP-সামঞ্জস্যপূর্ণ বৈধতা
protocol ValidationRule {
    func validate(_ input: String) -> Bool
}

struct EmailRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.contains("@")
    }
}

struct PhoneRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count == 11
    }
}

// নতুন নিয়ম যোগ করার জন্য ভ্যালিডেটর কোড পরিবর্তনের প্রয়োজন নেই
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

এই উদাহরণগুলোতে OCP-এর মূল সুবিধা: ApplePay বা PasswordRule যোগ করার জন্য বিদ্যমান ক্লাস পরিবর্তনের প্রয়োজন হয় না। কোড অনুভূমিকভাবে সম্প্রসারিত হয় — নতুন ফাইলের মাধ্যমে, পুরনো ফাইল পরিবর্তন করে নয়। এটি রিগ্রেশনের ঝুঁকি হ্রাস করে এবং নতুন কার্যকারিতা বাস্তবায়ন ত্বরান্বিত করে।

OCP লঙ্ঘনের সাধারণ ভুল

সবচেয়ে সাধারণ লঙ্ঘন হল অবজেক্ট প্রকারের উপর ভিত্তি করে switch বা when নির্মাণ। প্রতিবার যখন একটি নতুন প্রকার যোগ করা হয়, কোডে সেই সমস্ত switch খুঁজে বের করে একটি নতুন শাখা যোগ করতে হয়। মিস করা switch একটি রানটাইম বাগ যা কম্পাইল সময়ে সনাক্ত করা কঠিন।

মোবাইল ডেভেলপমেন্টে, বিশাল enum ক্লাস ব্যবহার করার সময় OCP লঙ্ঘিত হয় যাদের enum মানের উপর নির্ভরশীল পদ্ধতি রয়েছে। একটি নতুন enum উপাদান যোগ করার জন্য পুরো প্রকল্প জুড়ে প্রতিটি switch পরিবর্তন প্রয়োজন। বিকল্প — ইন্টারফেসের মাধ্যমে পলিমরফিজম, যেখানে প্রতিটি প্রকার তার নিজস্ব আচরণ বাস্তবায়ন করে।

আরেকটি সাধারণ লঙ্ঘন হল God Adapter: RecyclerView.Adapter (Android) বা UITableViewDataSource (iOS) যা if-else এর মাধ্যমে বিভিন্ন সেল প্রকার পরিচালনা করে। প্রতিটি নতুন সেল প্রকারের জন্য অ্যাডাপ্টার সম্প্রসারণ প্রয়োজন। সমাধান — একটি সাধারণ bind পদ্ধতি সহ পলিমরফিক ViewHolder, যেখানে প্রতিটি সেল প্রকার তার নিজস্ব রেন্ডারিংয়ের জন্য দায়ী।

কীভাবে OCP লঙ্ঘন এড়াবেন

প্রতিরোধমূলক ব্যবস্থা অন্তর্ভুক্ত: পলিমরফিজমের পক্ষে প্রকার-ভিত্তিক switch এড়ানো, ইন্টারফেসের মাধ্যমে নির্ভরতা ইনজেক্ট করা এবং কনফিগারেশন অনুযায়ী অবজেক্ট তৈরি করতে Factory প্যাটার্ন ব্যবহার করা। "প্রকার অনুসারে সুইচ"-এর জন্য কোড বিশ্লেষণ OCP-ভিত্তিক টিমে কোড পর্যালোচনার একটি বাধ্যতামূলক অংশ।

বিদ্যমান OCP লঙ্ঘনের রিফ্যাক্টরিং Replace Conditional with Polymorphism-এর মাধ্যমে করা হয়: প্রতিটি শর্ত শাখা একটি সাধারণ ইন্টারফেস বাস্তবায়নকারী পৃথক ক্লাসে পরিণত হয়। ক্লায়েন্ট কোড ইন্টারফেসের সাথে কাজ করার জন্য পুনরায় লেখা হয়, এবং কংক্রিট বাস্তবায়ন ফ্যাক্টরি বা DI কন্টেইনারের মাধ্যমে সরবরাহ করা হয়।

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