การพึ่งพาการฉีด (DI) คืออะไร?
ดังที่คนอื่น ๆ ได้กล่าวไว้ว่าการพึ่งพาการฉีด (DI) เป็นการขจัดความรับผิดชอบของการสร้างโดยตรงและการจัดการอายุขัยของวัตถุอื่น ๆ ที่ซึ่งระดับความสนใจของเรา (ระดับผู้บริโภค) ขึ้นอยู่กับ (ในแง่ของ UML ) อินสแตนซ์เหล่านี้จะถูกส่งผ่านไปยังคลาสผู้บริโภคของเราโดยทั่วไปเป็นพารามิเตอร์คอนสตรัคเตอร์หรือผ่านตัวตั้งค่าคุณสมบัติ (การจัดการของวัตถุอ้างอิงและการส่งผ่านไปยังระดับผู้บริโภคมักจะดำเนินการโดยInversion of Control (IoC)คอนเทนเนอร์แต่นั่นเป็นหัวข้ออื่น) .
DI กรมทรัพย์สินทางปัญญาและของแข็ง
โดยเฉพาะในกระบวนทัศน์ของโรเบิร์ตซีมาร์ตินเป็นหลักการที่มั่นคงของการออกแบบเชิงวัตถุ , DIเป็นหนึ่งในการใช้งานเป็นไปได้ของการพึ่งพาผกผันหลักการ (DIP) กรมทรัพย์สินทางปัญญาเป็น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()`"
ทำไมต้องใช้ DIP (และ DI)
การแยก Decoupling dependencies ระหว่างคลาสด้วยวิธีนี้ช่วยให้ง่ายต่อการทดแทนคลาสพึ่งพาเหล่านี้ด้วยการใช้งานอื่น ๆ ซึ่งยังเติมเต็มสิ่งที่จำเป็นต้องมีของ abstraction (เช่นการพึ่งพาสามารถสลับกับการใช้งานของอินเตอร์เฟสเดียวกัน) นอกจากนี้ยังเป็นคนอื่น ๆ ได้กล่าวอาจสาเหตุที่พบได้บ่อยที่สุดในการแยกคลาสผ่านทางกรมทรัพย์สินทางปัญญาคืออนุญาตให้มีการทดสอบคลาสที่แยกออกจากกันเนื่องจากการพึ่งพาที่เหมือนกันเหล่านี้สามารถถูกขัดจังหวะและ / หรือเยาะเย้ย
ผลลัพธ์หนึ่งของ DI คือการจัดการอายุการใช้งานของอินสแตนซ์วัตถุพึ่งพาไม่ได้ถูกควบคุมโดยคลาสการบริโภคอีกต่อไปเนื่องจากวัตถุการอ้างอิงถูกส่งผ่านไปยังคลาสบริโภค (ผ่านคอนสตรัคเตอร์หรือ setter injection)
สามารถดูได้ในรูปแบบต่างๆ:
- หากการควบคุมอายุการใช้งานโดยการพึ่งพาคลาสการบริโภคจำเป็นต้องถูกเก็บรักษาไว้การควบคุมสามารถสร้างใหม่ได้โดยการฉีดโรงงาน (นามธรรม) เพื่อสร้างอินสแตนซ์ของคลาสการพึ่งพาลงในคลาสผู้บริโภค ผู้บริโภคจะสามารถรับอินสแตนซ์ผ่าน
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; }
}
เราสามารถคลายการพึ่งพาConsoleให้กับสิ่งที่เป็นนามธรรมเช่น a TextWriter. โดยทั่วไปแล้วการพึ่งพาการฉีดจะถูกนำไปใช้เป็นการconstructorฉีดอย่างใดอย่างหนึ่ง(ผ่านนามธรรมไปยังการพึ่งพาเป็นพารามิเตอร์ไปยังตัวสร้างของคลาสที่บริโภค) หรือSetter Injection(ผ่านการพึ่งพาผ่านsetXyz()setter หรือ. Net คุณสมบัติที่{set;}กำหนดไว้) Constructor Injection เป็นที่ต้องการเนื่องจากเป็นการรับประกันว่าคลาสจะอยู่ในสถานะที่ถูกต้องหลังการก่อสร้างและอนุญาตให้ทำเครื่องหมายเขตข้อมูลการพึ่งพาภายในเป็นreadonly(C #) หรือfinal(Java) ดังนั้นการใช้ constructor injection ในตัวอย่างด้านบนทำให้เรามี:
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และต้องมีการอ้างอิงสองรายการโดยคอนเทนเนอร์ IoC ผ่านตัวสร้างคอนสตรัคเตอร์)
สามารถสร้างการทดสอบหน่วยอัตโนมัติซึ่งพิสูจน์ได้อย่างชัดเจนว่าคนตัดไม้ของเราทำงานอย่างถูกต้องเนื่องจากเราสามารถควบคุมการพึ่งพา - เวลาและเราสามารถสอดแนมผลลัพธ์ที่เขียนได้:
[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());
}
ขั้นตอนถัดไป
การพึ่งพาการฉีดมีความเกี่ยวข้องกับInversion of Control container (IoC)อย่างสม่ำเสมอเพื่อฉีด (ให้) อินสแตนซ์การพึ่งพาที่เป็นรูปธรรมและเพื่อจัดการอินสแตนซ์อายุการใช้งาน ในระหว่างกระบวนการกำหนดค่า / การบูตสแตรปIoCคอนเทนเนอร์อนุญาตให้มีการกำหนดดังต่อไปนี้:
- การทำแผนที่ระหว่างสิ่งที่เป็นนามธรรมและการใช้งานรูปธรรมที่กำหนดค่าไว้ (เช่น"เมื่อใดก็ตามที่ผู้บริโภคร้องขอ
IBarและส่งคืนConcreteBarอินสแตนซ์" )
- นโยบายสามารถตั้งค่าสำหรับการจัดการอายุการใช้งานของการอ้างอิงแต่ละรายการเช่นการสร้างวัตถุใหม่สำหรับแต่ละอินสแตนซ์ผู้บริโภคเพื่อแบ่งปันอินสแตนซ์การพึ่งพาแบบซิงเกิลในผู้บริโภคทั้งหมดเพื่อแบ่งปันอินสแตนซ์การพึ่งพาเดียวกันผ่านเธรดเดียวกันเท่านั้น
- ใน. Net คอนเทนเนอร์ IoC ตระหนักถึงโปรโตคอลเช่นนั้น
IDisposableและจะรับผิดชอบเกี่ยวDisposingกับการพึ่งพาซึ่งสอดคล้องกับการจัดการอายุการใช้งานที่กำหนดไว้
โดยทั่วไปเมื่อคอนเทนเนอร์ IoC ได้รับการกำหนดค่า / bootstrapped พวกเขาทำงานได้อย่างราบรื่นในพื้นหลังทำให้ coder มุ่งเน้นไปที่รหัสในมือมากกว่ากังวลเกี่ยวกับการพึ่งพา
กุญแจสำคัญในรหัส DI ง่ายคือการหลีกเลี่ยงการมีเพศสัมพันธ์แบบคงที่ของชั้นเรียนและไม่ใช้ใหม่ () สำหรับการสร้างการพึ่งพา
ตามตัวอย่างข้างบนการแยกการพึ่งพาต้องอาศัยความพยายามในการออกแบบและสำหรับนักพัฒนามีการเปลี่ยนกระบวนทัศน์ที่จำเป็นในการทำลายนิสัยของการnewพึ่งพาโดยตรงและแทนที่จะไว้วางใจคอนเทนเนอร์เพื่อจัดการการพึ่งพา
แต่คุณประโยชน์มากมายโดยเฉพาะอย่างยิ่งในความสามารถในการทดสอบระดับความสนใจ
หมายเหตุ : การสร้าง / การทำแผนที่ / ฉาย (ผ่านnew ..()) ของประมาณการ POCO / POJO / อันดับ DTOs / Entity กราฟ / ไม่ประสงค์ออกนาม JSON, et al - คือ "เท่านั้นข้อมูล" เรียนหรือระเบียน - การใช้หรือกลับมาจากวิธีการที่จะไม่ได้รับการยกย่องเป็นพึ่งพา (ใน ความหมาย UML) และไม่อยู่ภายใต้ DI การใช้newโปรเจ็กต์เหล่านี้ก็ใช้ได้
