কম্পোসিট ডিসাইন প্যাটার্ন (Composite Design Pattern)

কম্পোসিট ডিসাইন প্যাটার্ন (Composite Design Pattern)

১০ মে শুক্রবার, ২০১৯

সফটওয়্যার ডিসাইন প্যাটার্নের উপর একটা কোর্স পড়াবো এই অগাস্টে। কোনোকিছু পড়াতে গেলেই বোধহয় ভালোভাবে শেখা হয়। নতুন করে আবার শিখছি বলেই আসলে আজকে লিখতে বসেছি। Coursera -তে ডিসাইন প্যাটার্নের উপরে একটা কোর্স আছে, কানাডার  ইউনিভার্সিটি অফ আলবার্টা-র প্রফেসর Kenny Wong -এর কোর্স। বেশ ভালো একটা কোর্স। কিন্তু মজার ব্যাপার হচ্ছে, কোর্সটা উনি নিজে পড়াচ্ছেন না! এক অভিনেত্রীকে দিয়ে পড়াচ্ছেন! অভিনেত্রী তার সুন্দর উচ্চারণ, বাচনভঙ্গি দিয়ে ভালোই প্রক্সি দিয়ে পড়িয়ে যাচ্ছেন! 

যাই হোক, কম্পোসিট ডিসাইন প্যাটার্নের আজকের লেখাটা এই কোর্স থেকেই নেয়া। আমি শুধু আমার নিজের মতো করে লিখে রাখছি নোট করে রাখার জন্যই। ভুলভ্রান্তি থাকলে ধরিয়ে দেয়ার অনুরোধ থাকলো।  

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

UML ডায়াগ্রাম, কিংবা কোড দেখে ব্যাপারটা বোঝার আগে আরেকটা উদাহরণ চিন্তা করা যাক।

ধরা যাক, আপনি একটা গানের প্লেলিস্ট জাভাতে ইমপ্লিমেন্ট করছেন। রিকোয়ারমেন্ট হিসাবে আপনাকে বলা হলো: একটা প্লেলিস্টে অনেকগুলো গান থাকবে (সেটা স্বাভাবিক)। কিন্তু প্লেলিস্টে অন্য আরেকটা প্লেলিস্টও থাকতে পারে। অর্থাৎ প্লেলিস্ট রিকার্সিভ হতে পারে। আচ্ছা, ভালো কথা। একটু চিন্তা করে বলুনতো একটা প্লেলিস্ট (যেখানে অনেকগুলো গান লিস্ট করা আছে), আর আরেকটা একক গান - এই দুইটার মধ্যে কমন ফাঙ্কশনটা কী হতে পারে? বলে দিচ্ছি,  দুটোই আসলে 'play' করা যাবে। আর এট্রিবিউট চিন্তা করলে, কমন এট্রিবিউট হবে নাম। কেননা একটা গানের যেমন নাম থাকে, একটা প্লেলিস্টেরও আমরা নাম দিয়ে দিতে পারি (যেমন দেশাত্ববোধক গানের প্লেলিস্ট)। দুটোর মধ্যে আলাদা ফাঙ্কশন বা এট্রিবিউট কী হতে পারে চিন্তা করলে দেখবেন একটা একক গানে না হলেও, প্লেলিস্টে কোনো গান 'add'  বা 'remove' করা যাবে। অন্য দিকে, একটা গানের গায়ক (গায়কের নাম) থাকলেও প্লেলিস্টের কোনো গায়ক থাকে না। ঠিক না ?

সুতরাং, এই দুটো কম্পোনেন্টের (Song, Playlist classes) কমন জিনিসগুলোকে (play(), name) একটা সুপারক্লাসে (এক্ষেত্রে ইন্টারফেসে) রেখে,  আলাদা জিনিস গুলোকে সাবক্লাসে ঠেলে দেয়া যায়। আর যেহেতু প্লেলিস্ট অনেকগুলো গান কিংবা অন্য প্লেলিস্ট কম্পোনেন্ট হিসাবে রাখতে পারে, প্লেলিস্টের মধ্যে একটা ইন্টারফেস টাইপ ArrayList রেখে দিয়ে, তারমধ্যে দরকার মতো (অন্য গান কিংবা প্লেলিস্ট) add , কিংবা remove করলেই হলো।  

এবার নিচের UML ডায়াগ্রাম টা দেখে উপরের ব্যাপারটা বোঝা যায় কিনা চেষ্টা করে দেখুন:

কম্পোজিট ডিসাইন প্যাটার্নের উদাহরণ UML 

UML ডায়াগ্রামের বিভিন্ন সিম্বলের meaning -র ব্যাখ্যাতে আর যাচ্ছি না। শুধু এইটুকু বলে রাখি, ডায়মন্ড সিম্বল দিয়ে কম্পোসিশন বোঝায়।  অর্থাৎ, কোনো ক্লাসে যখন অন্য ক্লাস বা ইন্টারফেসের রেফারেন্স রেখে দেয়া হয়, তখন তা বোঝাতে এই ডায়মন্ড চিহ্ন ব্যবহার করা হয়।  

নিচের কোডগুলো  দেখলে আশা করি ব্যাপারটা আরো ভালো করে বোঝা যাবে:

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

ইন্টারফেসে শুধু কমন ফাঙ্কশনগুলোর সিগনেচার রেখে দেয়া হচ্ছে। ক্লাসগুলো নিজেরা এই মেথড বা ফাঙ্কশন গুলো ইমপ্লিমেন্ট করবে।  

Song ক্লাস leaf হিসাবে কাজ করবে।  অন্য কোনো ক্লাসের রেফারেন্স রাখবে না 

Song ক্লাস leaf ক্লাস হিসাবে শুধু ইন্টারফেসের মেথড গুলো ইমপ্লিমেন্ট করবে। তার মধ্যে অন্য কোনো ক্লাসের রেফারেন্স (কম্পোসিট) হিসাবে রাখার দরকার নাই।  

Playlist ক্লাস array লিস্টের মধ্যে ইন্টারফেস টাইপের অবজেক্ট রেফারেন্স রাখবে। 

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

ফাইনালি, ক্লায়েন্ট ক্লাসে (অর্থাৎ main() মেথড যেই ক্লাসে থাকবে - এই ক্লাসের কোড আর দিচ্ছি না), তাতে আমরা ইচ্ছামতো গানের অবজেক্ট, প্লেলিস্টের অবজেক্ট তৈরি করতে পারি। একটা গান একা (whole) থাকতে পারে, আবার একটা প্লেলিস্টের পার্ট (part) হতে পারে। একইভাবে একটা প্লেলিস্টও অন্য প্লেলিস্টের পার্ট হতে পারে। যেমন একটা প্লেলিস্টে অনেকগুলো গান add  করতে পারি। চাইলে আবার একটা প্লেলিস্টে অন্য একটা প্লেলিস্টও add (একই ভাবে remove -ও) করতে পারি। অন্য দিকে গান কিংবা প্লেলিস্ট দুটোর জন্যই কমন 'play()' মেথড মেথড কল করে গান শুনতে পারি। অর্থাৎ দুটোকেই uniformly বা একইভাবে treat করতে পারি।  

Head First Design Pattern বইয়ে দেয়া Composite Design Pattern-র সংজ্ঞা অনুযায়ী: 

"The Composite Patter allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly"

আশা করি, UML ডায়াগ্রাম আর কোড দেখে এখন কম্পোসিট ডিসাইন প্যাটার্নের কনসেপ্টটা বুঝতে পারছেন। আরো ভালো কোনো আর্টিকেল, ব্লগ পোস্ট কিংবা YouTube ভিডিও পেলে শেয়ার করার অনুরোধ থাকলো।

অন্যান্য সফটওয়্যার ডিসাইন প্যাটার্ন নিয়ে আমার লেখাগুলো একসাথে পাওয়া যাবে এই লিংকে।

 ধন্যবাদ!