মেসেজিং সঙ্গে সরাসরি নির্ভরতা প্রতিস্থাপন
কখনও কখনও একটি মডিউলকে অন্যদের জানানোর প্রয়োজন হয় যে এটিতে কিছু ঘটনা/পরিবর্তন ঘটেছে এবং এই তথ্যের পরে কী ঘটবে তা বিবেচ্য নয়।
এই ক্ষেত্রে, মডিউলগুলির একেবারেই "একে অপরের সম্পর্কে জানার" দরকার নেই, অর্থাৎ, সরাসরি লিঙ্ক ধারণ করে এবং সরাসরি ইন্টারঅ্যাক্ট করে, তবে এটি কেবল বার্তা (বার্তা) বা ইভেন্টগুলি (ইভেন্ট) বিনিময় করার জন্য যথেষ্ট।
কখনও কখনও মনে হয় যে মেসেজিংয়ের মাধ্যমে মডিউল যোগাযোগ সরাসরি নির্ভরতার তুলনায় অনেক দুর্বল। প্রকৃতপক্ষে, যেহেতু পদ্ধতিগুলি বলা হয় না, ক্লাস সম্পর্কে কোনও তথ্য নেই। কিন্তু এটা একটা মায়া ছাড়া আর কিছু নয়।
পদ্ধতির নামের পরিবর্তে, যুক্তি বার্তার ধরন, তাদের পরামিতি এবং প্রেরিত ডেটার সাথে আবদ্ধ হতে শুরু করে। এই ধরনের মডিউল সংযোগ smeared হয়.
এটি এমন হত: আমরা পদ্ধতিগুলিকে কল করি - সংযোগ রয়েছে, আমরা পদ্ধতিগুলিকে কল করি না - কোনও সংযোগ নেই। এখন কল্পনা করুন যে মডিউল A তার বার্তাগুলিতে সামান্য ভিন্ন ডেটা পাঠাতে শুরু করেছে। এবং একই সময়ে, এই বার্তাগুলির উপর নির্ভরশীল সমস্ত মডিউল সঠিকভাবে কাজ করবে না।
ধরুন, আগে, একটি নতুন ব্যবহারকারী যোগ করার সময়, অনুমোদন মডিউলটি USER_ADDED বার্তাটি পাঠিয়েছিল এবং আপডেটের পরে, এটি নিবন্ধন করার চেষ্টা করার সময় এই বার্তাটি পাঠাতে শুরু করে এবং অতিরিক্তভাবে পরামিতিতে সফল নিবন্ধন বা না নির্দেশ করে।
অতএব, বার্তা প্রক্রিয়াটি অত্যন্ত দক্ষতার সাথে বাস্তবায়ন করা অত্যন্ত গুরুত্বপূর্ণ। এই জন্য বিভিন্ন টেমপ্লেট আছে.
পর্যবেক্ষক। এটি এক-থেকে-অনেক নির্ভরতার ক্ষেত্রে ব্যবহৃত হয়, যখন অনেকগুলি মডিউল একের অবস্থার উপর নির্ভর করে - প্রধানটি। এটি মেইলিং মেকানিজম ব্যবহার করে, যার মানে হল যে মূল মডিউলটি তার সমস্ত গ্রাহকদের কাছে একই বার্তা পাঠায় এবং এই তথ্যে আগ্রহী মডিউলগুলি "সাবস্ক্রাইবার" ইন্টারফেস বাস্তবায়ন করে এবং মেলিং তালিকায় সদস্যতা নেয়।
এই পদ্ধতিটি ব্যবহারকারীর ইন্টারফেসের সাথে সিস্টেমে ব্যাপকভাবে ব্যবহৃত হয়, যা অ্যাপ্লিকেশনের মূল (মডেল) স্বাধীন থাকার অনুমতি দেয় এবং এর সংশ্লিষ্ট ইন্টারফেসগুলিকে জানায় যে কিছু পরিবর্তন হয়েছে এবং আপডেট করা দরকার।
এখানে বার্তা বিন্যাসটি অপারেটিং সিস্টেম স্তরে প্রমিত করা হয়েছে, যার বিকাশকারীদের অবশ্যই পশ্চাদগামী সামঞ্জস্য এবং ভাল ডকুমেন্টেশনের যত্ন নিতে হবে।
বার্তা বিতরণের মাধ্যমে মিথস্ক্রিয়া সংগঠনের একটি অতিরিক্ত "বোনাস" রয়েছে - "প্রকাশিত" (অর্থাৎ প্রেরিত) বার্তাগুলিতে "সাবস্ক্রাইবারদের" ঐচ্ছিক অস্তিত্ব। এই ধরনের একটি ভাল-পরিকল্পিত সিস্টেম যে কোনো সময় মডিউল যোগ/মুছে ফেলার অনুমতি দেয়।
মেসেজিং বাস
আপনি বার্তা বিনিময় সংগঠিত করতে পারেন এবং এটির জন্য একটি ভিন্ন উপায়ে মধ্যস্থতাকারী প্যাটার্ন ব্যবহার করতে পারেন ।
এটি ব্যবহৃত হয় যখন মডিউলগুলির মধ্যে বহু-থেকে-অনেক নির্ভরতা থাকে। মধ্যস্থতাকারী মডিউলগুলির মধ্যে যোগাযোগের মধ্যস্থতাকারী হিসাবে কাজ করে, একটি যোগাযোগ কেন্দ্র হিসাবে কাজ করে এবং একে অপরকে স্পষ্টভাবে উল্লেখ করার জন্য মডিউলগুলির প্রয়োজনীয়তা দূর করে।
ফলস্বরূপ, একে অপরের সাথে মডিউলগুলির মিথস্ক্রিয়া ("সকলের সাথে") শুধুমাত্র একটি মধ্যস্থতাকারীর ("সবার সাথে এক") মডিউলগুলির মিথস্ক্রিয়া দ্বারা প্রতিস্থাপিত হয়। মধ্যস্থতাকারী একাধিক মডিউল মধ্যে মিথস্ক্রিয়া encapsulate বলা হয়.
এটি তথাকথিত স্মার্ট মধ্যস্থতাকারী । এটি সেখানেই যে বিকাশকারীরা প্রায়শই তাদের ক্রাচ যুক্ত করতে শুরু করে, যা নির্দিষ্ট বার্তাগুলি পাওয়ার / চালু করে পৃথক মডিউলগুলির আচরণকে প্রভাবিত করে।
একটি সাধারণ বাস্তব জীবনের উদাহরণ হল বিমানবন্দর ট্রাফিক নিয়ন্ত্রণ। বিমান থেকে সমস্ত বার্তা সরাসরি বিমানের মধ্যে পাঠানোর পরিবর্তে নিয়ন্ত্রকের কন্ট্রোল টাওয়ারে যায়। এবং কন্ট্রোলার ইতিমধ্যেই সিদ্ধান্ত নেয় যে কোন প্লেনগুলি টেক অফ বা অবতরণ করতে পারে এবং এর পরিবর্তে প্লেনগুলিতে বার্তা পাঠায়৷
গুরুত্বপূর্ণ ! মডিউলগুলি একে অপরকে কেবল সাধারণ বার্তাই নয়, কমান্ড অবজেক্টও পাঠাতে পারে। এই ধরনের মিথস্ক্রিয়া কমান্ড টেমপ্লেট দ্বারা বর্ণনা করা হয় । নীচের লাইনটি হল একটি পৃথক বস্তু হিসাবে একটি নির্দিষ্ট ক্রিয়া সম্পাদন করার জন্য একটি অনুরোধ এনক্যাপসুলেট করা।
প্রকৃতপক্ষে, এই অবজেক্টটিতে একটি একক execute() পদ্ধতি রয়েছে, যা আপনাকে প্যারামিটার হিসাবে সম্পাদনের জন্য অন্যান্য মডিউলগুলিতে এই ক্রিয়াটি পাস করতে দেয় এবং সাধারণত কমান্ড অবজেক্টের সাথে যেকোন ক্রিয়াকলাপ সম্পাদন করতে দেয় যা সাধারণ বস্তুতে সঞ্চালিত হতে পারে।
ডিমিটারের আইন
ডিমিটারের আইন অন্তর্নিহিত নির্ভরতা ব্যবহার নিষিদ্ধ করে: "বস্তু A অবশ্যই বস্তু C এ সরাসরি অ্যাক্সেস করতে সক্ষম হবে না যদি অবজেক্ট A এর B অবজেক্টে অ্যাক্সেস থাকে এবং B অবজেক্ট C এর অ্যাক্সেস থাকে।"
এর মানে হল যে কোডের সমস্ত নির্ভরতা অবশ্যই "স্পষ্ট" হতে হবে - ক্লাস / মডিউলগুলি শুধুমাত্র তাদের কাজে "তাদের নির্ভরতা" ব্যবহার করতে পারে এবং তাদের মাধ্যমে অন্যদের কাছে আরোহণ করা উচিত নয়। একটি ভাল উদাহরণ একটি তিন স্তরের স্থাপত্য। ইন্টারফেস স্তরটি লজিক স্তরের সাথে কাজ করা উচিত, তবে ডাটাবেস স্তরের সাথে সরাসরি যোগাযোগ করা উচিত নয়।
সংক্ষেপে, এই নীতিটিও এইভাবে প্রণয়ন করা হয়েছে: "শুধুমাত্র তাত্ক্ষণিক বন্ধুদের সাথে যোগাযোগ করুন, বন্ধুদের বন্ধুদের সাথে নয়।" এটি কোডের কম সংগতি অর্জন করে, সেইসাথে এর নকশার বৃহত্তর দৃশ্যমানতা এবং স্বচ্ছতা অর্জন করে।
ডিমিটারের আইনটি ইতিমধ্যে উল্লিখিত "সর্বনিম্ন জ্ঞানের নীতি" প্রয়োগ করে, যা আলগা সংযোগের ভিত্তি এবং এটি এই বিষয়টির মধ্যে রয়েছে যে একটি বস্তু / মডিউল অন্যান্য বস্তু / মডিউলগুলির গঠন এবং বৈশিষ্ট্য সম্পর্কে যতটা সম্ভব বিস্তারিত জানা উচিত এবং সাধারণ কিছু, তার নিজস্ব উপাদান সহ ।
জীবন থেকে একটি উপমা: আপনি যদি কুকুরটিকে দৌড়াতে চান তবে তার পাঞ্জাকে আদেশ করা বোকামি, কুকুরটিকে আদেশ দেওয়া ভাল এবং সে নিজেই তার পাঞ্জা মোকাবেলা করবে।
উত্তরাধিকারের পরিবর্তে রচনা
এটি একটি খুব বড় এবং আকর্ষণীয় বিষয় এবং এটি অন্তত একটি পৃথক বক্তৃতা প্রাপ্য। ইন্টারনেটে এই বিষয়ে অনেকগুলি অনুলিপি ভাঙা হয়েছে যতক্ষণ না একটি ঐক্যমত পৌঁছায় - আমরা সর্বনিম্ন, রচনা - সর্বাধিক পর্যন্ত উত্তরাধিকার ব্যবহার করি।
বিন্দু হল যে উত্তরাধিকার আসলে ক্লাসের মধ্যে সবচেয়ে শক্তিশালী সংযোগ প্রদান করে, তাই এটি এড়ানো উচিত। এই বিষয়টি হার্ব সাটারের নিবন্ধ " উত্তরাধিকারের চেয়ে রচনা পছন্দ করুন " এ ভালভাবে কভার করা হয়েছে।
আপনি যখন ডিজাইনের প্যাটার্ন শিখতে শুরু করবেন, তখন আপনি একটি সম্পূর্ণ প্যাটার্নের একটি গুচ্ছ দেখতে পাবেন যা একটি বস্তু বা এর অভ্যন্তরীণ গঠনকে নিয়ন্ত্রণ করে। যাইহোক, আমি এই প্রসঙ্গে উপদেশ দিতে পারি ডেলিগেট/ডেলিগেট প্যাটার্ন এবং কম্পোনেন্ট প্যাটার্নের দিকে মনোযোগ দিতে, যা গেম থেকে এসেছে ।
আমরা একটু পরে নিদর্শন সম্পর্কে আরও কথা বলব।