একটি আধুনিক মেগাসিটির কথা চিন্তা করা যাক। সেখানে হাজার হাজার উপাদান ছড়িয়ে রয়েছে—আকাশচুম্বী অট্টালিকা, দ্রুতগতির যানবাহন এবং ব্যস্ত নাগরিক। বাহ্যিকভাবে এদের বৈচিত্র্যময় মনে হলেও, কাঠামোগতভাবে এদের প্রত্যেকের সুনির্দিষ্ট কিছু বৈশিষ্ট্য এবং আচরণ রয়েছে।
প্রতিটি গাড়ির (Vehicle) একটি রেজিস্ট্রেশন নম্বর, প্রস্তুতকারকের নাম ও নির্দিষ্ট জ্বালানি থাকে। একই সাথে প্রতিটি গাড়ি এক্সিলারেট করতে পারে কিংবা ব্রেক চেপে থেমে যেতে পারে।
প্রতিটি ভবনের (Building) নির্দিষ্ট তলা সংখ্যা ও ধারণক্ষমতা থাকে।
প্রতিটি নাগরিকের (Person) একটি জাতীয় পরিচয়পত্র, নাম ও পেশা থাকে।
সফটওয়্যার ইঞ্জিনিয়ারিংয়ের ভাষায়—বাস্তব পৃথিবীর এই জটিল সিস্টেম, উপাদান ও তাদের মধ্যকার পারস্পরিক সম্পর্ককে কোডের মাধ্যমে লজিক্যালি মডেল করার আর্কিটেকচারাল প্যারাডাইমই হলো Object-Oriented Programming (OOP)। এটি ডেটা এবং ডেটার ওপর কার্যকর ফাংশনগুলোকে আলাদা না রেখে একটি ইউনিফাইড প্যাকেজের ভেতর আবদ্ধ করে।
OOP এর ভিত্তি প্রস্তর: Class এবং Object
প্রোগ্রামিংয়ে OOP মূলত দুটি প্রাইমারি কনসেপ্টের ওপর দাঁড়িয়ে থাকে:
Class (ব্লুপ্রিন্ট বা টেমপ্লেট): একটি ভবন নির্মাণের আগে যেমন তার আর্কিটেকচারাল ব্লুপ্রিন্ট তৈরি করা হয়, ক্লাস হলো ঠিক তেমনই একটি কাঠামোগত নকশা। এটি নির্ধারণ করে এই টাইপের উপাদানগুলোর কী কী স্টেট (Attribute) এবং কাজ (Method) থাকবে। ক্লাসের নিজস্ব কোনো রানটাইম মেমোরি এলোকেশন থাকে না যতক্ষণ না তা ইনিশিয়েট করা হয়।
Object (বাস্তব ইনস্ট্যান্স): সেই ব্লুপ্রিন্ট ব্যবহার করে যখন বাস্তবে কংক্রিট ও ইস্পাত দিয়ে একটি ভবন নির্মাণ করা হয়, সেটিই হলো অবজেক্ট। প্রতিটি অবজেক্ট মেমোরিতে নিজস্ব স্টেট ধারণ করে স্বাধীনভাবে এক্সিকিউট হতে পারে।
টার্ম | মেটাফোর (City) | প্রোগ্রামিং সংজ্ঞা |
Class | ভবনের ব্লুপ্রিন্ট নকশা | ডেটা ও লজিকের ইউজার-ডিফাইন্ড টেমপ্লেট |
Object | বাস্তবে নির্মিত একটি সুনির্দিষ্ট ভবন | ক্লাসের রানটাইম মেমোরি ইনস্ট্যান্স |
Attribute / State | ভবনের উচ্চতা, বর্তমান বাসিন্দা সংখ্যা | অবজেক্টের অভ্যন্তরীণ ভেরিয়েবল |
Method / Behavior | লিফট চালু হওয়া, মেইন গেট লক হওয়া | অবজেক্টের ওপর চালিত ফাংশন বা লজিক |
OOP-এর কোর আর্কিটেকচারাল পিলার্স
OOP মূলত চারটি মূল স্তম্ভ (Four Pillars of OOP) এবং ইন্টারফেস চুক্তির ওপর ভিত্তি করে গড়ে ওঠে:
১. Encapsulation (এনক্যাপসুলেশন ও ডেটা হাইডিং)
এনক্যাপসুলেশন হলো অবজেক্টের ইন্টারনাল স্টেটকে বাইরের সরাসরি ইন্টারফেয়ারেন্স থেকে আড়াল করা এবং শুধুমাত্র অনুমোদিত মেথডের (Getters/Setters) মাধ্যমে অ্যাক্সেস দেওয়ার নিয়ম।
একটি সিটির বৈদ্যুতিক গ্রিডের কথা ভাবা যাক। সাবস্টেশনের ভেতরে হাই-ভোল্টেজ ট্রান্সফরমার থাকে। সাধারণ নাগরিক সরাসরি ভেতরের তারে হাত দিতে পারে না; তাদের শুধুমাত্র একটি সুইচবোর্ড বা নিরাপদ প্লাগ পয়েন্ট দেওয়া হয়। এটিই এনক্যাপসুলেশন।
২. Abstraction (অ্যাবস্ট্রাকশন ও কমপ্লেক্সিটি কন্ট্রোল)
অ্যাবস্ট্রাকশন হলো সিস্টেমের জটিল অভ্যন্তরীণ মেকানিজম লুকিয়ে রেখে ব্যবহারকারীর সামনে কেবল প্রয়োজনীয় ও প্রাসঙ্গিক কন্ট্রোল উন্মুক্ত রাখা।
যখন আপনি গাড়ির এক্সিলারেটরে চাপ দেন, ইঞ্জিন সিলিন্ডারে ফুয়েল ইনজেক্ট হচ্ছে, স্পার্ক প্লাগে আগুন জ্বলছে, পিস্টন ঘুরছে—এই ইন্টারনাল জটিলতা আপনাকে জানতে হয় না। আপনার সামনে শুধু পেডাল বা স্টিয়ারিং হুইল থাকে।
৩. Inheritance (ইনহেরিটেন্স ও হায়ারার্কিকাল রিইউজেবিলিটি)
ইনহেরিটেন্স এমন একটি মেকানিজম যার মাধ্যমে একটি চাইল্ড ক্লাস (Subclass) তার প্যারেন্ট ক্লাসের (Superclass) সমস্ত সাধারণ অ্যাট্রিবিউট এবং মেথড গ্রহণ করে এবং নিজস্ব ইউনিক ফিচার যোগ করে।
একটি সিটির সব যানবাহনই Vehicle। কিন্তু ElectricBus এবং FireTruck-এর স্পেসিফিকেশন আলাদা। সাধারণ ফিচারগুলো প্যারেন্ট ক্লাসে রেখে চাইল্ড ক্লাসে রিইউজ করা যায়।
৪. Polymorphism (পলিমরফিজম ও ডাইনামিক ডিসপ্যাচ)
পলিমরফিজম (Polymorphism) শব্দের অর্থ "বহুরূপিতা"। এর মূল ধারণা হলো—একই ইন্টারফেস বা মেথড সিগনেচার দিয়ে ভিন্ন ভিন্ন অবজেক্ট তাদের নিজস্ব পদ্ধতিতে ভিন্ন আচরণ প্রকাশ করতে পারে।
ট্রাফিক সিগন্যালে যখন লাল বাতি জ্বলে, তখন সিটির প্রতিটি যানবাহন থামে। কিন্তু তাদের থামার পদ্ধতি ভিন্ন: সাধারণ প্রাইভেট কার ডিস্ক ব্রেক চেপে থামে, আর ইলেকট্রিক বাস রিজেনারেটিভ ব্রেকিং ব্যবহার করে ব্যাটারি রিচার্জ করতে করতে থামে।
পলিমরফিজমের প্রকারভেদ
Compile-time Polymorphism (Method Overloading): একই মেথড নাম কিন্তু প্যারামিটার ভিন্ন (জাভাতে সরাসরি সাপোর্টেড)।
Runtime Polymorphism (Method Overriding): প্যারেন্ট ক্লাসের মেথডকে সাবক্লাসে নতুন লজিক দিয়ে ওভাররাইট করা।
৫. Interface: সিস্টেম বাউন্ডারির কন্ট্রাক্ট
ইন্টারফেস হলো মেথডের একটি কঠোর চুক্তি (Contract), যেখানে কোনো ইমপ্লিমেন্টেশন লজিক থাকে না। একটি ক্লাস ইন্টারফেস ইমপ্লিমেন্ট করলে সে বাধ্যতামূলকভাবে ঐ মেথডগুলোর বডি প্রদান করতে বাধ্য থাকে।
সিটির যেকোনো জরুরি সেবামূলক গাড়ি (অ্যাম্বুলেন্স, ফায়ার সার্ভিস, পুলিশ ভ্যান) EmergencyResponder চুক্তি মেনে চলবে। ট্রাফিক কন্ট্রোল সিস্টেম এদের ভেতরের গঠন না জেনেও সিগন্যাল প্রায়োরিটি দিতে পারে।
এন্টারপ্রাইজ সিস্টেমে কেন OOP অপরিহার্য?
মডুলারিটি ও ফল্ট আইসোলেশন: প্রতিটি ক্লাস বা অবজেক্ট স্বাধীনভাবে কাজ করে। সিটির একটি সাবস্টেশনে ফল্ট হলে যেমন গোটা সিটির সব বিল্ডিং ধ্বংস হয় না, তেমনি অবজেক্ট-ওরিয়েন্টেড সিস্টেমে বাগ সহজে আইসোলেট ও ফিক্স করা যায়।
কোড রিইউজেবিলিটি ও DRY (Don't Repeat Yourself): ইনহেরিটেন্স ও কম্পোজিশন ব্যবহারের ফলে একই লজিক বারবার লেখার প্রয়োজন হয় না।
স্কেলেবিলিটি ও এক্সটেনসিবিলিটি (Open/Closed Principle): বিদ্যমান মূল কোডবেজ মডিফাই না করেই নতুন ক্লাস বা ইন্টারফেস ইমপ্লিমেন্ট করে সিস্টেমের পরিধি বাড়ানো যায়।
বাস্তব ডোমেইন ম্যাপিং (Domain-Driven Design): ব্যাংকিং, ই-কমার্স বা লজিস্টিকসের মতো জটিল ডোমেইনের বিজনেস লজিককে রিয়েল-ওয়ার্ল্ড অবজেক্ট ও এন্টিটির সাথে সরাসরি কনসেপচুয়াল ম্যাপিং করা যায়।
এন্টারপ্রাইজ সিকিউরিটি ও স্টেট ইন্টিগ্রিটি: এনক্যাপসুলেশন নিশ্চিত করে কোনো ম্যালিসিয়াস বা ইনভ্যালিড স্টেট যেন অবজেক্টের ভেতরে সিস্টেমে ইনজেক্ট হতে না পারে।