নির্ভরতা বিপরীত

9.1 নির্ভরতা বিপরীত

মনে রাখবেন, আমরা একবার বলেছিলাম যে একটি সার্ভার অ্যাপ্লিকেশনে আপনি কেবল স্ট্রিম তৈরি করতে পারবেন না new Thread().start()? শুধুমাত্র পাত্রে থ্রেড তৈরি করা উচিত। আমরা এখন এই ধারণাটিকে আরও উন্নত করব।

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

• শীর্ষ-স্তরের মডিউলগুলি নিম্ন-স্তরের মডিউলগুলির উপর নির্ভর করা উচিত নয়। উভয়, এবং অন্যদের বিমূর্ততা উপর নির্ভর করা উচিত.
• বিমূর্ত বিবরণের উপর নির্ভর করা উচিত নয়। বাস্তবায়ন অবশ্যই বিমূর্ততার উপর নির্ভর করবে।

মডিউলগুলিতে নির্দিষ্ট বাস্তবায়নের রেফারেন্স থাকা উচিত নয় এবং তাদের মধ্যে সমস্ত নির্ভরতা এবং মিথস্ক্রিয়া সম্পূর্ণরূপে বিমূর্তকরণের ভিত্তিতে তৈরি করা উচিত (অর্থাৎ, ইন্টারফেস)। এই নিয়মের সারমর্মটি একটি বাক্যাংশে লেখা যেতে পারে: সমস্ত নির্ভরতা অবশ্যই ইন্টারফেসের আকারে হতে হবে ।

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

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

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

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

অতএব, যদি ভবিষ্যতে নতুন বিকল্পগুলি (বা নতুন বাস্তবায়ন, যেমন আমরা বিবেচনা করছি নতুন অবজেক্ট তৈরির ক্ষেত্রে) যোগ করার প্রয়োজন হয়, তবে এই তথ্যটি রয়েছে এমন মডিউল এবং অন্যান্য সমস্ত মডিউল আপডেট করা যথেষ্ট হবে। প্রভাবিত হবে না এবং তারা তাদের কাজ চালিয়ে যেতে সক্ষম হবে।

উদাহরণ 1

new ArrayList এর মতো কিছু লেখার পরিবর্তে, List.new()JDK-এর জন্য আপনাকে একটি পাতার সঠিক বাস্তবায়ন প্রদান করা অর্থপূর্ণ হবে : ArrayList, LinkedList, এমনকি ConcurrentList।

উদাহরণস্বরূপ, কম্পাইলার দেখে যে বিভিন্ন থ্রেড থেকে বস্তুতে কল এসেছে এবং সেখানে একটি থ্রেড-নিরাপদ বাস্তবায়ন রাখে। অথবা শীটের মাঝখানে অনেকগুলি সন্নিবেশ, তারপর বাস্তবায়ন LinkedList এর উপর ভিত্তি করে করা হবে।

উদাহরণ 2

এটি ইতিমধ্যে বিভিন্ন ধরণের সাথে ঘটেছে, উদাহরণস্বরূপ। শেষবার কখন আপনি একটি সংগ্রহ সাজানোর জন্য একটি সাজানোর অ্যালগরিদম লিখেছিলেন? পরিবর্তে, এখন সবাই পদ্ধতি ব্যবহার করে Collections.sort(), এবং সংগ্রহের উপাদানগুলিকে অবশ্যই তুলনামূলক ইন্টারফেস (তুলনাযোগ্য) সমর্থন করতে হবে।

আপনি যদি sort()পদ্ধতিতে 10 টিরও কম উপাদানের একটি সংগ্রহ পাস করেন তবে এটিকে একটি বুদবুদ সাজানোর (বাবল সর্ট) দিয়ে সাজানো বেশ সম্ভব, এবং Quicksort নয়।

উদাহরণ 3

কম্পাইলার ইতিমধ্যেই দেখছে আপনি কীভাবে স্ট্রিংগুলিকে সংযুক্ত করবেন এবং আপনার কোডটি এর সাথে প্রতিস্থাপন করবেন StringBuilder.append()।

9.2 অনুশীলনে নির্ভরতা বিপরীত

এখন সবচেয়ে আকর্ষণীয়: আসুন আমরা কীভাবে তত্ত্ব এবং অনুশীলনকে একত্রিত করতে পারি সে সম্পর্কে চিন্তা করি। কীভাবে মডিউলগুলি সঠিকভাবে তাদের "নির্ভরতা" তৈরি করতে এবং গ্রহণ করতে পারে এবং নির্ভরতা ইনভার্সন লঙ্ঘন করতে পারে না?

এটি করার জন্য, একটি মডিউল ডিজাইন করার সময়, আপনাকে অবশ্যই নিজের জন্য সিদ্ধান্ত নিতে হবে:

• মডিউলটি কী করে, এটি কী কাজ করে;
• তারপর মডিউলটি তার পরিবেশ থেকে প্রয়োজন, অর্থাৎ, কোন বস্তু/মডিউলগুলির সাথে এটি মোকাবেলা করতে হবে;
• আর সে কিভাবে পাবে?

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

এবং এখানে নিম্নলিখিত বিকল্পগুলি রয়েছে:

• মডিউল নিজেই বস্তু তৈরি করে;
• মডিউল ধারক থেকে বস্তু নেয়;
• বস্তুগুলি কোথা থেকে আসে মডিউলটির কোন ধারণা নেই।

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

"বটম লাইন হল যে নতুনের মাধ্যমে একটি বস্তুকে সরাসরি ইনস্ট্যান্টিয়েট করার পরিবর্তে, আমরা ক্লায়েন্ট ক্লাসকে অবজেক্ট তৈরি করার জন্য কিছু ইন্টারফেস প্রদান করি। যেহেতু এই ধরনের একটি ইন্টারফেস সবসময় সঠিক ডিজাইনের সাথে ওভাররাইড করা যেতে পারে, তাই নিম্ন-স্তরের মডিউল ব্যবহার করার সময় আমরা কিছুটা নমনীয়তা পাই। উচ্চ-স্তরের মডিউলগুলিতে" ।

যেসব ক্ষেত্রে সংশ্লিষ্ট বস্তুর গোষ্ঠী বা পরিবার তৈরি করা প্রয়োজন, সেখানে ফ্যাক্টরি পদ্ধতির পরিবর্তে একটি বিমূর্ত কারখানা ব্যবহার করা হয় ।

9.3 সার্ভিস লোকেটার ব্যবহার করা

মডিউলটি যার কাছে ইতিমধ্যেই রয়েছে তার কাছ থেকে প্রয়োজনীয় বস্তুগুলি নেয়৷ ধারণা করা হয় যে সিস্টেমে বস্তুর কিছু ভান্ডার রয়েছে, যেখানে মডিউলগুলি তাদের বস্তুগুলিকে "স্থাপিত" করতে পারে এবং সংগ্রহস্থল থেকে বস্তুগুলিকে "নেতে" পারে।

এই পদ্ধতিটি পরিষেবা লোকেটার প্যাটার্ন দ্বারা প্রয়োগ করা হয় , যার মূল ধারণা হল যে প্রোগ্রামটিতে এমন একটি বস্তু রয়েছে যা জানে যে কীভাবে সমস্ত নির্ভরতা (পরিষেবা) পেতে হয় যা প্রয়োজন হতে পারে।

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

গুরুত্বপূর্ণ ! পরিষেবা লোকেটার একই ইতিমধ্যে বিদ্যমান বস্তুর রেফারেন্স তৈরি করে । অতএব, পরিষেবা লোকেটার দ্বারা জারি করা বস্তুগুলির সাথে আপনাকে খুব সতর্কতা অবলম্বন করতে হবে, যেহেতু অন্য কেউ আপনার মতো একই সময়ে সেগুলি ব্যবহার করতে পারে।

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

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

• পরিষেবা লোকেটার একটি অ্যান্টি-প্যাটার্ন
• বিমূর্ত কারখানা বা পরিষেবা লোকেটার?

9.4 নির্ভরতা ইনজেকশন

মডিউলটি "মাইনিং" নির্ভরতা সম্পর্কে মোটেও চিন্তা করে না। এটি শুধুমাত্র কাজ করার জন্য কী প্রয়োজন তা নির্ধারণ করে এবং সমস্ত প্রয়োজনীয় নির্ভরতা অন্য কেউ বাইরে থেকে সরবরাহ করে (প্রবর্তিত)।

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

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

এই দিক পরিবর্তনকে বলা হয় ইনভারশন অফ কন্ট্রোল , বা হলিউডের নীতি - "আমাদের কল করবেন না, আমরা আপনাকে কল করব।"

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

কাজের জন্য প্রয়োজনীয় সমস্ত কিছু সহ মডিউল সরবরাহ করা একটি পৃথক কাজ, যা উপযুক্ত "বিশেষজ্ঞ" দ্বারা পরিচালনা করা উচিত (সাধারণত একটি নির্দিষ্ট ধারক, একটি আইওসি ধারক, নির্ভরতা পরিচালনা এবং তাদের বাস্তবায়নের জন্য দায়ী)।

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

এটা বললে অত্যুক্তি হবে না যে মডিউলগুলির মধ্যে নির্ভরতা বর্ণনা করতে ইন্টারফেসের ব্যবহার (নির্ভরতা ইনভার্সন) + এই নির্ভরতাগুলির সঠিক সৃষ্টি এবং ইনজেকশন (প্রাথমিকভাবে নির্ভরতা ইনজেকশন) ডিকপলিং এর মূল কৌশল ।

তারা এমন ভিত্তি হিসাবে কাজ করে যার উপর কোডের আলগা সংযোগ, এর নমনীয়তা, পরিবর্তনের প্রতিরোধ, পুনঃব্যবহার এবং যা ছাড়া অন্যান্য সমস্ত কৌশল সামান্যই অর্থবহ। এটি আলগা কাপলিং এবং ভাল স্থাপত্যের ভিত্তি।

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