යැපුම් එන්නත් (DI) යනු කුමක්ද?
අනෙක් අය පවසා ඇති පරිදි, අපගේ උනන්දුව දක්වන පන්තිය (පාරිභෝගික පන්තිය) රඳා පවතින ( යූඑම්එල් අර්ථයෙන් ) වෙනත් වස්තු අවස්ථාවන්හි සෘජු නිර්මාණය හා ආයු කාලය කළමනාකරණය කිරීමේ වගකීම යැපුම් එන්නත් කිරීම (DI) ඉවත් කරයි . මෙම අවස්ථා ඒ වෙනුවට අපගේ පාරිභෝගික පන්තියට, සාමාන්යයෙන් ඉදිකිරීම්කරුවන්ගේ පරාමිතීන් ලෙස හෝ දේපල සැකසුම් හරහා යවනු ලැබේ (පරායත්ත වස්තු කළමනාකරණය සහ පාරිභෝගික පන්තියට ගමන් කිරීම සාමාන්යයෙන් සිදු කරනු ලබන්නේ ප්‍රතිලෝම පාලන (IoC) බහාලුමක් මගිනි , නමුත් එය තවත් මාතෘකාවක් වේ) .
DI, DIP සහ SOLID
විශේෂයෙන්, රොබට් සී මාටින්ගේ SOLID මූලධර්මවල Object Oriented Design හි පරමාදර්ශය තුළ , DIඑය ක්රියාත්මක කළ හැකි එකකි යැපුම් ප්‍රතිලෝම මූලධර්මය (ඩීඅයිපී) . මෙම DIP යනු Dපිළිබඳ SOLIDමන්ත්රය - වෙනත් DIP නිර්මාණයන් සේවා සෙවීම, සහ හොදම විදිය තමයි රටා ඇතුලත් වේ.
ඩීඅයිපී හි පරමාර්ථය වන්නේ පංති අතර තද, කොන්ක්රීට් පරායත්තතාවයන් විසන්ධි කිරීම සහ ඒ වෙනුවට, වියුක්තයක් මගින් සම්බන්ධ කිරීම ලිහිල් කිරීමයි, එය හරහා ලබා ගත හැකි 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()`"
DIP (සහ DI) භාවිතා කරන්නේ ඇයි?
මේ ආකාරයෙන් පන්ති අතර පරායත්තතාවයන් විකේතනය කිරීමෙන් මෙම පරායත්තතා පංති වෙනත් ක්රියාත්මක කිරීම් සමඟ පහසුවෙන් ආදේශ කිරීමට ඉඩ සලසයි . එපමණක්ද නොව, අනෙක් අය සඳහන් කර ඇති පරිදි, සමහරවිට එම තෙමාලන හරහා ජීවයේ පන්ති වඩාත් පොදු හේතුව පානය පන්ති හුදෙකලාව පරීක්ෂා කර තහවුරු කිරීම සඳහා ඉඩ ඇති මේ පරායත්තයන් දැන් stubbed සහ / හෝ සමච්චල් කරමින් කළ හැකි පරිදි වේ.
DI හි එක් ප්‍රතිවිපාකයක් නම් පරායත්ත වස්තු සිද්ධි වල ආයු කාලය තවදුරටත් පරිභෝජනය කරන පන්තියක් විසින් පාලනය නොකිරීමයි. මන්දයත් පරායත්ත වස්තුව දැන් පරිභෝජන පන්තියට (ඉදිකිරීම්කරු හෝ සෙටර් එන්නත් කිරීම හරහා) යවනු ලැබේ.
මෙය විවිධ ආකාරවලින් නැරඹිය හැකිය:
- පරිභෝජනය කරන පන්තිය විසින් පරායත්තතාවයේ ආයු කාලය පාලනය කර ගත යුතු නම්, පරායත්තතා පන්ති අවස්ථා නිර්මාණය කිරීම සඳහා (වියුක්ත) කර්මාන්ත ශාලාවක් පාරිභෝගික පන්තියට එන්නත් කිරීමෙන් පාලනය නැවත ස්ථාපිත කළ හැකිය. A හරහා පාරිභෝගිකයාට අවස්ථා ලබා ගත හැකිය
Create අවශ්ය පරිදි කර්මාන්තශාලාව අතර, මෙම අවස්ථා අවසන් වූ පසු බැහැර කරන්න.
- නැතහොත්, යැපුම් අවස්ථාවන්හි ආයු කාලය පාලනය කිරීම IoC බහාලුමකට භාර දිය හැකිය (මේ ගැන වැඩි විස්තර පහතින්).
DI භාවිතා කළ යුත්තේ කවදාද?
- සමාන ක්රියාත්මක කිරීමක් සඳහා යැපීමක් ආදේශ කිරීමේ අවශ්‍යතාවයක් ඇති විට,
- පංතියක පරායත්තතාවයන් හුදකලා කිරීමේ ක්‍රමවේදයන් ඔබට ඒකක පරීක්ෂා කිරීමට අවශ්ය ඕනෑම වේලාවක,
- යැපීමක ආයු කාලය පිළිබඳ අවිනිශ්චිතතාවයට අත්හදා බැලීම් අවශ්ය විය හැකි තැන (උදා: හේයි,
MyDepClassනූල් ආරක්ෂිතයි - අපි එය තනි පුද්ගලයකු බවට පත් කර එකම අවස්ථාව සියලු පාරිභෝගිකයින්ට එන්නත් කළහොත් කුමක් කළ යුතුද?)
උදාහරණයක්
මෙන්න සරල C # ක්රියාත්මක කිරීමකි. පහත දැක්වෙන පරිභෝජන පන්තිය:
public class MyLogger
{
public void LogRecord(string somethingToLog)
{
Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
}
}
අහිංසක බවක් පෙනෙන්නට තිබුණද, එයට staticතවත් පන්ති දෙකක් මත යැපීම් දෙකක් ඇත, System.DateTimeසහSystem.Console එම දැව සදහා නිෂ්පාදනය විකල්ප (කිසිවෙකු බලා නම් අග්රය වෙත ප්රවේශ වීම්, කිසි කමකට නැති වනු ඇත), සීමා පමණක් නොව, නමුත් ඊටත් වඩා, ඒ මත රඳා පැවැතීමට ලබා ස්වයංක්රීයව පරීක්ෂා කිරීම අපහසු වේ නිර්ණායක නොවන පද්ධති ඔරලෝසුව.
කෙසේ වෙතත් අපට DIPමෙම පන්තියට අයදුම් කළ හැක්කේ කාල පරාසය යැපීම ලෙස සැලකීමෙන් වියුක්ත කිරීමෙන් සහ MyLoggerසරල අතුරුමුහුණතකට පමණක් සම්බන්ධ වීමෙන් ය:
public interface IClock
{
DateTime Now { get; }
}
ConsoleA වැනි වියුක්තයක් මත යැපීම අපට ලිහිල් කළ හැකිය TextWriter. සත්කාර එන්නත් සාමාන්යයෙන් එක්කෝ ලෙස මෙය ක්රියාත්මක වේ constructorඑන්නත් (අ පානය පන්තියේ ඉදිකිරීමටත් පරාමිතියක් ලෙස යැපීම වියුක්තකර පසුකර) හෝ Setter Injection(අ හරහා පරායත්ත පසුකර setXyz()සමග පන්දු පිරිනමන්නා හෝ .Net ඉඩකඩම් {set;}අර්ථ). ඉදිකිරීම් වලින් පසු පන්තිය නිවැරදි තත්වයක පවතින බවට සහතික වන බැවින් ඉදිකිරීම් එන්නත් කිරීම වඩාත් සුදුසු වේ. තවද අභ්‍යන්තර පරායත්තතා ක්ෂේත්‍ර readonly(C #) හෝ 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 අතර පරායත්තතා දෙක ඉදිකිරීම්කරු එන්නත් කිරීම හරහා අයිඕසී බහාලුමක් මගින් සැපයිය යුතුය)
ස්වයංක්‍රීය ඒකක පරීක්ෂණයක් ගොඩනගා ගත හැකි අතර, එය අපගේ ල ger ු-සටහන නිවැරදිව ක්‍රියා කරන බව නිශ්චිතවම සනාථ කරයි, මන්දයත් දැන් අපට පරායත්තයන් - කාලය පාලනය කර ඇති අතර අපට ලිඛිත ප්‍රතිදානය පිළිබඳ ඔත්තු බැලීමට හැකිය:
[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());
}
ඊළඟ පියවර
පරායත්ත එන්නත් කිරීම පාලක බහාලුමක් (IoC) සමඟ නිරන්තරයෙන් සම්බන්ධ වේ , කොන්ක්රීට් පරායත්තතා අවස්ථා එන්නත් කිරීම (සැපයීම) සහ ආයු කාලය කළමනාකරණය කිරීම. වින්‍යාස කිරීමේ / ඇරඹුම් ක්‍රියාවලිය අතරතුර, IoCබහාලුම් පහත සඳහන් දේ අර්ථ දැක්වීමට ඉඩ දෙයි:
- එක් එක් වියුක්තකරණය සහ වින්‍යාසගත කොන්ක්රීට් ක්රියාත්මක කිරීම අතර සිතියම්ගත කිරීම (උදා: "පාරිභෝගිකයෙකු ඉල්ලීමක් කරන ඕනෑම වේලාවක උදාහරණයක්
IBarආපසු ConcreteBarඑවන්න" )
- එක් එක් පරායත්තතාවයේ ආයු කාලය කළමනාකරණය සඳහා ප්‍රතිපත්ති සැකසිය හැකිය, උදා: සෑම පාරිභෝගික අවස්ථාවක් සඳහාම නව වස්තුවක් නිර්මාණය කිරීම, සියලු පාරිභෝගිකයින් අතර තනි පරායත්තතා අවස්ථාවක් බෙදා ගැනීම, එකම පරායත්තතාව එකම නූල් හරහා පමණක් බෙදා ගැනීම යනාදිය.
- .Net හි, IoC බහාලුම් වැනි ප්‍රොටෝකෝල පිළිබඳව දැනුවත්ව සිටින අතර වින්‍යාසගත කර ඇති ආයු කාලය කළමනාකරණයට අනුකූලව පරායත්තතාවයේ
IDisposableවගකීම භාර ගනී Disposing.
සාමාන්යයෙන්, IoC බහාලුම් වින්‍යාසගත කිරීමෙන් / ඇරඹූ පසු, ඒවා බාධාවකින් තොරව ක්රියාත්මක වන අතර, කෝඩරයට පරායත්තතාවයන් ගැන කරදර නොවී අතේ ඇති කේතය කෙරෙහි අවධානය යොමු කිරීමට ඉඩ ලබා දේ.
DI- හිතකාමී කේතයේ ප්‍රධාන දෙය නම් පන්ති ස්ථිතිකව සම්බන්ධ වීම වළක්වා ගැනීම සහ යැපීම් නිර්මාණය කිරීම සඳහා නව () භාවිතා නොකිරීමයි.
ඉහත උදාහරණයට අනුව, පරායත්තයන් විකේතනය කිරීම සඳහා යම් නිර්මාණ උත්සාහයක් අවශ්ය වන අතර, සංවර්ධකයාට, newයැපීම්වල පුරුද්ද කෙලින්ම බිඳ දැමීම සඳහා අවශ්ය පරමාදර්ශී වෙනසක් අවශ්ය වන අතර ඒ වෙනුවට පරායත්තතා කළමනාකරණය කිරීම සඳහා කන්ටේනරය විශ්වාස කරයි.
නමුත් ප්‍රතිලාභ බොහෝය, විශේෂයෙන් ඔබේ උනන්දුව දක්වන පන්තිය හොඳින් පරීක්ෂා කිරීමේ හැකියාව තුළ.
සටහන : new ..()POCO / POJO / Serialization DTOs / Entity Graphs / Anonymous JSON ප්‍රක්ෂේපණ සහ වෙනත් - එනම් “දත්ත පමණක්” පන්ති හෝ වාර්තා නිර්මාණය කිරීම / සිතියම්ගත කිරීම / ප්‍රක්ෂේපණය ( ක්‍රමයෙන්) භාවිතා කරන හෝ ආපසු ලබා දෙන ක්‍රම මත රඳා නොපවතී ( යූඑම්එල් හැඟීම) සහ DI ට යටත් නොවේ. newමේවා ප්‍රක්ෂේපණය කිරීම සඳහා භාවිතා කිරීම හොඳයි.
