নির্ভরতা ইনজেকশন (ডিআই) কী?
যেমনটি অন্যেরা বলেছেন, ডিপেন্ডেন্সি ইনজেকশন (ডিআই) অন্যান্য বস্তুর উদাহরণগুলির উপর নির্ভর করে যেখানে আমাদের আগ্রহের শ্রেণি (গ্রাহক শ্রেণি) নির্ভর করে ( ইউএমএল অর্থে ) তার সরাসরি জীবনধারণ এবং পরিচালনা করার দায়িত্ব সরিয়ে দেয় । এই উদাহরণগুলি পরিবর্তে আমাদের কনজিউমার ক্লাসে পৌঁছে দেওয়া হয়, সাধারণত কনস্ট্রাক্টর প্যারামিটার হিসাবে বা সম্পত্তি সেটারের মাধ্যমে (নির্ভরতা অবজেক্টের পরিচালনা এবং গ্রাহক শ্রেণিতে পাস করা সাধারণত নিয়ন্ত্রণের একটি ইনভার্শন (আইওসি) ধারক দ্বারা সম্পাদিত হয় তবে এটি অন্য বিষয়) ।
ডিআই, ডিআইপি এবং সলিড
বিশেষ করে, রবার্ট সি মার্টিন এর দৃষ্টান্ত মধ্যে ওরিয়েন্টড ডিজাইন বস্তু কঠিন নীতি , DIসম্ভাব্য বাস্তবায়নের অন্যতম নির্ভরতা ইনভার্সান নীতি (চোবান) । চোবান আছে Dএর SOLIDমন্ত্রকে অন্যান্য চোবান বাস্তবায়নের পরিষেবা লোকেটার এবং প্লাগইন নিদর্শন অন্তর্ভুক্ত -।
ডিআইপি'র উদ্দেশ্য ক্লাসের মধ্যে শক্ত, কংক্রিট নির্ভরতা ডিক্লোল করা এবং পরিবর্তে, একটি বিমূর্ততার মাধ্যমে মিলিতকরণকে আলগা করা, যা ব্যবহার করা ভাষা এবং পদ্ধতির উপর নির্ভর করে interface, abstract classবা দ্বারা অর্জন করা যেতে পারে pure virtual class।
ডিআইপি ব্যতীত, আমাদের কোড (আমি এই 'গ্রাহক শ্রেণি' বলেছি) সরাসরি একটি কংক্রিট নির্ভরতার সাথে মিলিত হয় এবং প্রায়শই এই নির্ভরতার উদাহরণ, যেমন ধারণাগতভাবে কীভাবে প্রাপ্ত এবং পরিচালনা করতে হয় তা জানার দায়িত্বের সাথে বোঝা থাকে:
"I need to create/use a Foo and invoke method `GetBar()`"
যেখানে ডিআইপি প্রয়োগের পরে প্রয়োজনীয়তাটি শিথিল করা হয় এবং Fooনির্ভরতার আয়ু অর্জন ও পরিচালনার উদ্বেগ অপসারণ করা হয়:
"I need to invoke something which offers `GetBar()`"
ডিআইপি (এবং ডিআই) কেন ব্যবহার করবেন?
শ্রেণিগুলির মধ্যে এইভাবে নির্ভরতাগুলি ডিকুলিংয়ের ফলে অন্যান্য বাস্তবায়নগুলির সাথে এই নির্ভরশীলতা শ্রেণীর সহজে প্রতিস্থাপনের সুযোগ দেয় যা বিমূর্তির পূর্বশর্তগুলিও পূরণ করে (যেমন নির্ভরতা একই ইন্টারফেসের অন্য প্রয়োগের সাথে বদলানো যেতে পারে)। অধিকন্তু, অন্যদের উল্লেখ করেছি, সম্ভবত চোবান মাধ্যমে decouple ক্লাস সবচেয়ে সাধারণ কারণ সর্বগ্রাসী বর্গ, বিচ্ছিন্নতা পরীক্ষিত করা যেমন এই একই নির্ভরতা এখন stubbed করা যেতে পারে এবং / অথবা ব্যঙ্গ অনুমতি দিতে হয়।
ডিআই-এর একটি পরিণতি হ'ল নির্ভরতা অবজেক্টের দৃষ্টান্তগুলির জীবনকাল পরিচালনা আর কোনও গ্রাহক শ্রেণীর দ্বারা নিয়ন্ত্রণ করা হয় না, কারণ নির্ভরতা অবজেক্টটি এখন গ্রাহক শ্রেণিতে (কনস্ট্রাক্টর বা সেটার ইনজেকশনের মাধ্যমে) পাস করা হয়।
এটি বিভিন্ন উপায়ে দেখা যায়:
- গ্রাহক শ্রেণীর নির্ভরতাগুলির আজীবন নিয়ন্ত্রণ যদি বজায় রাখা দরকার হয় তবে ভোক্তা শ্রেণিতে নির্ভরতা শ্রেণির উদাহরণ তৈরির জন্য একটি (বিমূর্ত) কারখানা ইনজেকশনের মাধ্যমে নিয়ন্ত্রণ পুনরায় প্রতিষ্ঠিত করা যেতে পারে। গ্রাহক
Createপ্রয়োজন অনুসারে কারখানায় কারখানার মাধ্যমে উদাহরণগুলি অর্জন করতে সক্ষম হবেন এবং এই দৃষ্টান্তগুলি সম্পূর্ণ হয়ে গেলে তা নিষ্পত্তি করতে সক্ষম হবেন ।
- বা, নির্ভরতা উদাহরণগুলির আজীবন নিয়ন্ত্রণ আইওসি ধারকটিতে ছেড়ে দেওয়া যেতে পারে (নীচে এটি সম্পর্কে আরও)।
ডিআই কখন ব্যবহার করবেন?
- সমতুল্য বাস্তবায়নের জন্য যেখানে নির্ভরতা স্থাপনের প্রয়োজন হতে পারে,
- যে কোনও সময় যেখানে আপনার শ্রেণিটির নির্ভরতাগুলি বিচ্ছিন্ন করার পদ্ধতিগুলি পরীক্ষা করার প্রয়োজন হবে,
- নির্ভরতার জীবনকাল সম্পর্কে অনিশ্চয়তা পরীক্ষা-নিরীক্ষার নিশ্চয়তা দিতে পারে (যেমন, হ্যাঁ
MyDepClass, থ্রেড নিরাপদ - যদি আমরা এটিকে একটি সিঙ্গলটন হিসাবে তৈরি করি এবং সমস্ত গ্রাহকের মধ্যে একই উদাহরণটি ইনজেকশন করি?)
উদাহরণ
এখানে একটি সাধারণ সি # বাস্তবায়ন। নীচে গ্রাহক শ্রেণি দেওয়া:
public class MyLogger
{
public void LogRecord(string somethingToLog)
{
Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
}
}
যদিও আপাতদৃষ্টিতে নির্দোষ মনে হচ্ছে, এটি staticঅন্য দুটি শ্রেণীর উপর দুটি নির্ভরশীলতা রয়েছে System.DateTimeএবং System.Consoleএটি কেবল লগিং আউটপুট বিকল্পগুলিকে সীমাবদ্ধ করে না (কনসোলে লগিং যদি কেউ দেখছে না তবে মূল্যহীন হবে), তবে আরও খারাপ, এর উপর নির্ভরতা দেখিয়ে স্বয়ংক্রিয়ভাবে পরীক্ষা করা কঠিন is একটি অ-নিরস্তক সিস্টেম ঘড়ি।
DIPনির্ভরতা হিসাবে টাইমস্ট্যাম্পিংয়ের উদ্বেগকে বাদ দিয়ে এবং MyLoggerকেবল একটি সাধারণ ইন্টারফেসে সংযুক্ত করে আমরা এই শ্রেণিতে প্রয়োগ করতে পারি :
public interface IClock
{
DateTime Now { get; }
}
আমরা Consoleএকটি বিমূর্তের উপর নির্ভরতা আলগা করতে পারি , যেমন এ TextWriter। নির্ভরতা ইনজেকশন সাধারণত হয় constructorইনজেকশন হিসাবে প্রয়োগ করা হয় (গ্রাহক শ্রেণীর নির্মাতার কাছে প্যারামিটার হিসাবে নির্ভরতা একটি বিমূর্ততা পাস) বা Setter Injection(একটি setXyz()সেটারের মাধ্যমে নির্ভরতা পাস বা একটি {set;}সংজ্ঞায়িত নেট সম্পত্তি )। কনস্ট্রাক্টর ইঞ্জেকশনটিকে অগ্রাধিকার দেওয়া হয়েছে, কারণ এটি গ্যারান্টি দেয় যে নির্মাণের পরে শ্রেণিটি সঠিক অবস্থায় থাকবে এবং অভ্যন্তরীণ নির্ভরতা ক্ষেত্রগুলিকে readonly(সি #) বা final(জাভা) হিসাবে চিহ্নিত করার অনুমতি দেয় । সুতরাং উপরের উদাহরণে কন্সট্রাক্টর ইঞ্জেকশন ব্যবহার করে এটি আমাদের সাথে ছেড়ে দেয়:
public class MyLogger : ILogger // Others will depend on our logger.
{
private readonly TextWriter _output;
private readonly IClock _clock;
// Dependencies are injected through the constructor
public MyLogger(TextWriter stream, IClock clock)
{
_output = stream;
_clock = clock;
}
public void LogRecord(string somethingToLog)
{
// We can now use our dependencies through the abstraction
// and without knowledge of the lifespans of the dependencies
_output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
}
}
(একটি কংক্রিট সরবরাহ করা Clockদরকার, অবশ্যই DateTime.Nowকোনটিতে ফিরে যেতে পারে এবং দুটি নির্ভরতা আইওসি ধারক দ্বারা কনস্ট্রাক্টর ইনজেকশনের মাধ্যমে সরবরাহ করা প্রয়োজন)
একটি স্বয়ংক্রিয় ইউনিট পরীক্ষা তৈরি করা যেতে পারে, যা নিশ্চিতভাবে প্রমাণ করে যে আমাদের লগার সঠিকভাবে কাজ করছে, যেহেতু এখন আমাদের নির্ভরতা - সময়ের উপর নিয়ন্ত্রণ রয়েছে এবং আমরা লিখিত আউটপুটটিতে নজর রাখতে পারি:
[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
// Arrange
var mockClock = new Mock<IClock>();
mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
var fakeConsole = new StringWriter();
// Act
new MyLogger(fakeConsole, mockClock.Object)
.LogRecord("Foo");
// Assert
Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}
পরবর্তী পদক্ষেপ
নির্ভরতা ইনজেকশন অবিচ্ছিন্নভাবে নিয়ন্ত্রণের ধারক ইনভার্শন (আইওসি) এর সাথে , কংক্রিটের নির্ভরতা উদাহরণগুলি সরবরাহ করতে এবং আজীবন দৃষ্টান্তগুলি পরিচালনা করার সাথে যুক্ত থাকে manage কনফিগারেশন / বুটস্ট্র্যাপিং প্রক্রিয়া চলাকালীন, ধারকগুলি IoCনিম্নলিখিতগুলি সংজ্ঞায়িত করার অনুমতি দেয়:
- প্রতিটি বিমূর্তি এবং কনফিগার করা কংক্রিট প্রয়োগের মধ্যে ম্যাপিং (উদাঃ "যে কোনও সময় কোনও গ্রাহক অনুরোধ করেন
IBar, ConcreteBarউদাহরণ ফেরৎ " )
- প্রতিটি পরাধীনতার জীবনকাল পরিচালনার জন্য নীতিগুলি সেট আপ করা যায়, যেমন প্রতিটি গ্রাহকের উদাহরণের জন্য একটি নতুন অবজেক্ট তৈরি করা, সমস্ত গ্রাহকের মধ্যে একটি একক নির্ভরতা উদাহরণ ভাগ করে নেওয়া, একই নির্ভরতার উদাহরণটি একই থ্রেডের মধ্যে ভাগ করে নেওয়া ইত্যাদি etc.
- নেট, আইওসি পাত্রে যেমন প্রোটোকল সম্পর্কে সচেতন
IDisposableএবং তা Disposingকনফিগার করা জীবনকাল পরিচালনার সাথে সামঞ্জস্য রেখে নির্ভরতাগুলির দায়িত্ব নেবে ।
সাধারণত, একবার আইওসি পাত্রে কনফিগার করা / বুটস্ট্র্যাপ করা হয়ে গেলে, তারা পটভূমিতে নির্বিঘ্নে কাজ করে কোডারকে নির্ভরতার বিষয়ে চিন্তা করার চেয়ে হাতের কোডটিতে ফোকাস করতে দেয়।
ডিআই-বান্ধব কোডের মূলটি হ'ল ক্লাসগুলির স্থির মিলন এড়ানো এবং নির্ভরতা তৈরির জন্য নতুন () ব্যবহার না করা
উপরোক্ত উদাহরণ অনুসারে, নির্ভরতাগুলি ডিকুয়াল করার জন্য কিছু নকশার প্রচেষ্টা প্রয়োজন হয় এবং বিকাশকারীদের জন্য newসরাসরি নির্ভরশীলতাগুলির অভ্যাসটি ভাঙার জন্য একটি প্যারাডিম শিফট দরকার হয় এবং পরিবর্তে নির্ভরতা পরিচালনার জন্য ধারকটির উপর নির্ভর করে।
তবে সুবিধাগুলি অনেকগুলি, বিশেষত আপনার আগ্রহের শ্রেণীর পুরোপুরি পরীক্ষা করার দক্ষতায়।
দ্রষ্টব্য : new ..()POCO / POJO / সিরিয়ালাইজেশন DTOs / সত্তা গ্রাফ / বেনামে JSON প্রজেকশন এবং অন্যান্য - যেমন "কেবলমাত্র ডেটা" শ্রেণি বা রেকর্ড - পদ্ধতি থেকে ব্যবহৃত বা প্রত্যাশিত - তৈরি বা ম্যাপিং / প্রজেকশন (মাধ্যমে ) নির্ভরতা হিসাবে বিবেচিত হয় না ( ইউএমএল ইন্দ্রিয়) এবং ডিআই সাপেক্ষে নয়। newএগুলি প্রজেক্ট করতে ব্যবহার করা ঠিক আছে।
