รูปแบบการต่อต้านการพึ่งพาการฉีดที่ถูกต้องตามกฎหมายเท่านั้นที่ฉันรับรู้คือรูปแบบของตัวค้นหาบริการซึ่งเป็นรูปแบบการต่อต้านเมื่อใช้เฟรมเวิร์ก DI
รูปแบบการต่อต้าน DI อื่น ๆ ทั้งหมดที่ฉันเคยได้ยินที่นี่หรือที่อื่น ๆ เป็นเพียงกรณีที่เฉพาะเจาะจงมากขึ้นเล็กน้อยของรูปแบบการต่อต้านการออกแบบ OO / ซอฟต์แวร์ทั่วไป ตัวอย่างเช่น
ตัวสร้างมากกว่าการฉีดเป็นการละเมิดที่Single รับผิดชอบหลักการ อาร์กิวเมนต์ตัวสร้างมากเกินไประบุว่ามีการขึ้นต่อกันมากเกินไป การพึ่งพามากเกินไปบ่งชี้ว่าชั้นพยายามทำมากเกินไป โดยปกติแล้วข้อผิดพลาดนี้มีความสัมพันธ์กับกลิ่นรหัสอื่น ๆ เช่นชื่อคลาสที่ยาวผิดปกติหรือคลุมเครือ ("ผู้จัดการ") เครื่องมือวิเคราะห์แบบคงที่สามารถตรวจจับการมีเพศสัมพันธ์ส่วนเกิน / ออกจากที่มากเกินไปได้อย่างง่ายดาย
การฉีดข้อมูลซึ่งตรงข้ามกับพฤติกรรมเป็นประเภทย่อยของโพลเทอร์จิสต์ anti-pattern โดยที่ 'geist ในกรณีนี้คือคอนเทนเนอร์ หากคลาสจำเป็นต้องทราบวันที่และเวลาปัจจุบันคุณไม่ต้องฉีด a DateTimeซึ่งเป็นข้อมูล แต่คุณฉีดสิ่งที่เป็นนามธรรมเหนือนาฬิการะบบ (ฉันมักจะเรียกฉันISystemClockว่าแม้ว่าฉันคิดว่ามีทั่วไปมากกว่าหนึ่งในโครงการSystemWrappers ) สิ่งนี้ไม่เพียงถูกต้องสำหรับ DI; เป็นสิ่งสำคัญอย่างยิ่งสำหรับความสามารถในการทดสอบเพื่อให้คุณสามารถทดสอบฟังก์ชั่นที่เปลี่ยนแปลงตามเวลาโดยไม่จำเป็นต้องรอฟัง
การประกาศทุก ๆ วงจรชีวิตในฐานะที่เป็นซิงเกิลสำหรับฉันนั้นเป็นตัวอย่างที่สมบูรณ์แบบของ การเขียนโปรแกรมลัทธิการขนส่งสินค้าและในระดับที่น้อยกว่านั้นชื่อ " Object cesspool " ฉันเคยเห็นการทารุณกรรมเดี่ยวมากกว่าที่ฉันจำได้และส่วนน้อยมากที่เกี่ยวข้องกับ DI
ข้อผิดพลาดทั่วไปอีกประการหนึ่งคือประเภทอินเตอร์เฟสเฉพาะของการติดตั้งใช้งาน (ที่มีชื่อแปลก ๆIOracleRepository) ที่ทำเพื่อให้สามารถลงทะเบียนในคอนเทนเนอร์ได้ สิ่งนี้อยู่ในตัวของมันเองและเป็นการละเมิดหลักการการพึ่งพาการพึ่งพา (เพียงเพราะมันเป็นอินเทอร์เฟซไม่ได้หมายความว่ามันเป็นนามธรรมอย่างแท้จริง) และมักจะรวมถึงอินเทอร์เฟซขยายตัวที่ละเมิดอินเตอร์เฟสแยกหลักการ
ข้อผิดพลาดที่ผ่านมาผมมักจะเห็นคือ "การพึ่งพาตัวเลือก" ซึ่งพวกเขาได้ใน NerdDinner ในคำอื่น ๆ ที่มีคอนสตรัคที่รับฉีดพึ่งพา แต่ยังอีกคอนสตรัคที่ใช้การดำเนินการ "เริ่มต้น" สิ่งนี้ยังละเมิดกรมและมีแนวโน้มจะนำไปสู่การละเมิดLSPเช่นเดียวกับนักพัฒนาเมื่อเวลาผ่านไปเริ่มต้นการตั้งสมมติฐานเกี่ยวกับการใช้งานเริ่มต้นและ / หรือเริ่มต้นอินสแตนซ์ใหม่โดยใช้ตัวสร้างเริ่มต้น
เป็นคำพูดเดิมไปคุณสามารถเขียน FORTRAN ในภาษาใด การพึ่งพาการฉีดไม่ใช่กระสุนเงินที่จะป้องกันไม่ให้นักพัฒนาเพิ่มการจัดการการพึ่งพา แต่มันจะป้องกันข้อผิดพลาดทั่วไปจำนวนมาก / รูปแบบการต่อต้าน:
... และต่อไป
เห็นได้ชัดว่าคุณไม่ต้องการที่จะออกแบบกรอบการทำงานที่ขึ้นอยู่กับการใช้งานคอนเทนเนอร์ IoC เฉพาะเช่น Unity หรือ AutoFac นั่นคืออีกครั้งละเมิดกรมทรัพย์สินทางปัญญา แต่ถ้าคุณพบว่าตัวเองกำลังคิดที่จะทำสิ่งนั้นคุณจะต้องทำผิดพลาดหลายครั้งเนื่องจาก Dependency Injection เป็นเทคนิคการจัดการเพื่อการพึ่งพาทั่วไปและเป็นไม่ได้เชื่อมโยงกับแนวคิดของคอนเทนเนอร์ IoC
อะไรก็ได้ที่สามารถสร้างต้นไม้ที่พึ่งพาได้ อาจเป็นคอนเทนเนอร์ IoC หรืออาจเป็นยูนิตทดสอบที่มี mocks มากมายบางทีอาจเป็นไดรเวอร์ทดสอบที่ส่งข้อมูลดัมมี่ กรอบงานของคุณไม่ควรสนใจและกรอบงานส่วนใหญ่ที่ฉันเห็นไม่สนใจ แต่พวกเขายังคงใช้การฉีดขึ้นต่อกันจำนวนมากเพื่อให้สามารถรวมเข้ากับคอนเทนเนอร์ IoC ของผู้ใช้ปลายทางได้อย่างง่ายดาย
DI ไม่ใช่วิทยาศาสตร์จรวด เพียงพยายามหลีกเลี่ยงnewและstaticยกเว้นเมื่อมีเหตุผลที่น่าสนใจที่จะใช้พวกเขาเช่นวิธีอรรถประโยชน์ที่ไม่มีการพึ่งพาภายนอกหรือคลาสยูทิลิตี้ที่ไม่สามารถมีวัตถุประสงค์นอกกรอบ (interop wrappers และพจนานุกรมคีย์เป็นตัวอย่างทั่วไปของ นี้).
ปัญหาหลายอย่างของกรอบ IoC เกิดขึ้นเมื่อนักพัฒนาเริ่มเรียนรู้วิธีใช้และแทนที่จะเปลี่ยนวิธีการจัดการอ้างอิงและนามธรรมให้เหมาะสมกับโมเดล IoC แทนที่จะพยายามจัดการคอนเทนเนอร์ IoC เพื่อตอบสนองความคาดหวังของพวกเขา รูปแบบการเข้ารหัสแบบเก่าซึ่งมักจะเกี่ยวข้องกับการมีเพศสัมพันธ์สูงและการทำงานร่วมกันในระดับต่ำ รหัสไม่ถูกต้องคือรหัสไม่ดีไม่ว่าจะใช้เทคนิค DI หรือไม่ก็ตาม