ทำไมรูปแบบการฉีดพึ่งพาไม่รวมอยู่ในแก๊งสี่


37

ทำไมรูปแบบฉีดพึ่งพาไม่ incluided ในแก๊งสี่ ? GOF ทำการทดสอบอัตโนมัติอย่างกว้างขวางล่วงหน้าหรือไม่? ตอนนี้การฉีดแบบพึ่งพานั้นถือเป็นรูปแบบหลักหรือไม่?


18
.. เพราะ "การฉีดพึ่งพา" ไม่ใช่รูปแบบ!
Dipan Mehta


14
ทุกสิ่งที่เกิดขึ้นซ้ำ ๆ นั้นเป็นรูปแบบของการทำซ้ำ องค์ประกอบการออกแบบทั้งหมด (ที่ไม่ซ้ำกันความคิดบ้า) เป็น "รูปแบบ"
S.Lott

3
คำตอบที่ยาวเหล่านี้อาจทำให้เข้าใจผิดเนื่องจากพวกเขาต้องการตรวจสอบคำถาม ในขณะที่ดังกล่าวการฉีดพึ่งพาไม่ใช่รูปแบบการออกแบบ มันเป็น "กลไก" สำหรับการสร้างอินสแตนซ์ของวัตถุโดยทั่วไปจะจัดการโดยกรอบงาน
Nazar Merza

1
ฉีดพึ่งพาเป็นรูปแบบ มันตรงข้ามกับรูปแบบของตัวค้นหาบริการ อ่านฟาวเลอร์ผู้เป็นคนบัญญัติศัพท์ ฉันไม่รู้แน่ชัดว่ามีผู้คนมากมายที่สนับสนุนเรื่องไร้สาระเช่นนี้
James

คำตอบ:


100

ฉันเป็นบรรณาธิการของนิตยสารSoftware Developmentเมื่อหนังสือ Gang of Four ออกมาและฉันสามารถพูดได้อย่างมั่นใจว่าการทดสอบหน่วยไม่ใช่การปฏิบัติที่แพร่หลายในปี 1994 เมื่อรูปแบบการออกแบบถูกตีพิมพ์ครั้งแรก

ในปี 1994 C ++ เป็นภาษาเชิงวัตถุที่ใช้กันมากที่สุดและคนส่วนใหญ่เขียนโปรแกรมมันมาจากพื้นหลัง C หนึ่งใน "ความคิดในวัตถุ" ที่ผู้คนไม่มีก็คือความคิดที่ว่าจุดเข้านับร้อยหรือนับพันในโปรแกรมของคุณ main()คุณคิดเกี่ยวกับ หากคุณทำงานในโครงการขนาดใหญ่คุณอาจมี makefile (มักจะค่อนข้างละเอียด) เพื่อสร้างโปรแกรมแบบโมดูล แต่ "การทดสอบหน่วย"? เริ่มต้นกระบวนการสร้างบริบทหน่วยความจำที่จำเป็นดำเนินการและฉีกมันลงบนพื้นฐานต่อวิธี ? มันรุนแรงมาก

Java ทำให้การโปรแกรมหลายจุดเริ่มต้นชัดเจนขึ้น เมื่อถึงเวลาของ Dot-Com ดั้งเดิมการทดสอบหน่วยเป็นเทคนิคที่รู้จักกันดี แต่จริงๆแล้ว JUnit (ประมาณปี 2001?) ที่ทำให้เกิดเพลิงไหม้และกลายเป็นแนวปฏิบัติสากล

แม้ว่ากลยุทธ์และแนวคิดทั่วไปของการเขียนโปรแกรมไปยังอินเทอร์เฟซเป็นส่วนหนึ่งของ GoF และจิตวิญญาณยุคกลางยุค 90 ความคิดของการฉีดเข้ามาค่อนข้างช้าไปงานเลี้ยง (ประมาณ '03 -'05?) จริง ๆ แล้วขนสีเทาของฉันยังค่อนข้างสงสัยเกี่ยวกับแง่มุมของ DI ("ลงสนามหญ้าของฉันคุณต้องกำหนดค่าไฟล์!")


17
ฉันเสียใจที่ฉันมีเพียงหนึ่งคะแนนเท่านั้นที่จะได้รับคำตอบที่เฉียบแหลม

@Larry OBrien: การสแกนเพื่อลงทะเบียนตามหลักการประชุมทำให้รหัสการกำหนดค่าง่ายขึ้นอย่างมากและกำจัดการตั้งค่า xml ในคอนเทนเนอร์ ioc
quentin-starin

4
ฉันต้องการเพิ่มการฉีดพึ่งพาที่แกนกลางของมันไม่พึ่งพาไฟล์การกำหนดค่าเลย คุณสามารถทำได้ด้วยมือซึ่งทำให้ใช้งานง่ายและยังคงเป็นวิธีที่ยืดหยุ่นมาก
marco-fiset

31

พวกเขาเรียกมันกลยุทธ์

กลยุทธ์ของพวกเขาดูเหมือนจะมีคุณสมบัติทั้งหมดของการฉีดพึ่งพาโดยไม่มีชื่อที่ซับซ้อนทำให้เกิดเสียง


16
-1 ขออภัย! รูปแบบกลยุทธ์ไม่มีส่วนเกี่ยวข้องกับการฉีดพึ่งพา
Dipan Mehta


14
@Dipan: ก่อนที่จะลงคะแนนนี้คุณควรคิดเกี่ยวกับคำตอบห้านาที
Doc Brown

6
เป็นความจริงที่ว่าการพึ่งพาการฉีดนั้นถือได้ว่าคล้ายกับรูปแบบกลยุทธ์ แต่เมื่อคนพูดว่าการฉีดขึ้นต่อกันพวกเขามักจะหมายถึง Inversion of Control ซึ่งฉันคิดว่าแตกต่างจาก Strategy มากขึ้น (esp. IoC container)
MattDavey

8
DI เป็นรูปแบบที่สร้างสรรค์มากขึ้น มันสร้างและฉีดกลยุทธ์ บอกว่ามันเป็นกลยุทธ์เพียงครึ่งหนึ่งของความจริง DI เป็นรูปแบบ microkernel มากกว่า! ฉันไม่อยากจะเชื่อเลยว่าคนโหวตขึ้น กลยุทธ์เป็นเหมือนลักษณะของ DI ที่ดีไม่ใช่ความจำเป็น
Falcon

0

ฉันคิดว่าการพึ่งพาการฉีดมีความเกี่ยวข้องมากขึ้นเมื่อแยกการใช้งานในระดับชั้น พื้นที่ที่เราคิดเกี่ยวกับการฉีดพึ่งพาคือการทดสอบหน่วย และคำแนะนำก่อนวันที่ของคุณดูเหมือนจะถูกต้อง ถ้าแก๊งจะรวบรวมและแยกรูปแบบในปี 2555 จะต้องมีการฉีดที่ต้องพึ่งพา

กลยุทธ์อาจเกิดขึ้นในการสนทนา แต่กลยุทธ์ไม่ได้พูดถึงการฉีดพึ่งพา แต่เมื่อใช้รูปแบบกลยุทธ์ในโครงการเดียวหรือ dll (คลาสและอินเทอร์เฟซทั้งหมดยังคงอยู่ในโครงการเดียว) ปรากฏว่าเรากำลังทำการฉีดพึ่งพา ในความเป็นจริงเราไม่ได้

ตอนนี้ถ้าคลาสและส่วนต่อประสานที่กล่าวถึงในรูปแบบกลยุทธ์ถูกแยกออกจากโครงการหรือชั้นต่างๆเราจะต้องใช้เทคนิคการฉีดพึ่งพา เราสามารถใช้ไฟล์การกำหนดค่าความเป็นเอกภาพ แต่รูปแบบกลยุทธ์ไม่ได้บอกว่าจะฉีดการพึ่งพา

หากมีรูปแบบที่คล้ายกับการฉีดขึ้นอยู่กับอย่างใกล้ชิดมันเป็นรูปแบบวิธีการโรงงานบทคัดย่อ รูปแบบนี้สามารถใช้ภายในรูปแบบกลยุทธ์เพื่อฉีดการพึ่งพา


2
สิ่งนี้ไม่ตอบคำถาม โปรดอ่านคำถามเดิมแทนที่จะตอบกลับคำตอบอื่น ๆ :)
Andres F.

-4

คำตอบกลยุทธ์ถูกต้อง 100% ฉันขึ้นคะแนน แต่สามารถแสดงความคิดเห็นได้

"กลยุทธ์ช่วยให้อัลกอริทึมแตกต่างจากลูกค้าที่ใช้ [1] กลยุทธ์เป็นหนึ่งในรูปแบบที่รวมอยู่ในรูปแบบการออกแบบหนังสือที่มีอิทธิพลโดย Gamma และคณะที่นิยมแนวคิดของการใช้รูปแบบเพื่ออธิบายการออกแบบซอฟต์แวร์"

รูปแบบการออกแบบไม่ได้ขึ้นอยู่กับการใช้งาน การพึ่งพาการฉีดจะดำเนินการโดยใช้รูปแบบกลยุทธ์ หากเราตั้งชื่อแต่ละรูปแบบตามกรณีการใช้งานเราจะต้องเปลี่ยนชื่อรูปแบบจำนวนมาก

รูปแบบที่เก็บไม่ใช่รูปแบบใหม่เป็นรูปแบบเทมเพลต

"ในวิธีเทมเพลตของรูปแบบการออกแบบนี้ขั้นตอนวิธีหนึ่งขั้นหรือมากกว่านั้นสามารถถูกแทนที่โดยคลาสย่อยเพื่อให้มีพฤติกรรมที่แตกต่างกันในขณะที่มั่นใจได้ว่าอัลกอริทึมที่ครอบคลุมนั้นยังคงปฏิบัติตามอยู่"

บ่อยครั้งที่รูปแบบนั้นมีหลายรูปแบบรวมกันและตั้งชื่อเช่นรูปแบบ MVC

GOF ไม่มีอินเทอร์เฟซสำหรับคลาสเพียว Abstract และยังใช้ประโยชน์จากความสามารถของ C ++ ในการสืบทอดจากคลาสมากกว่าหนึ่งคลาส


1
จุดประสงค์ของรูปแบบมีความสำคัญอย่างยิ่งในการแยกแยะ ในบรรดารูปแบบ GoF นั้น Adapter และ Proxy เป็นตัวอย่างที่ดี - มีรูปแบบเดียวกัน แต่มีจุดประสงค์ที่แตกต่างกัน ฉันยังไม่เห็นด้วยกับการยืนยันของคุณว่า DI ดำเนินการโดยใช้กลยุทธ์ กลยุทธ์มีความเฉพาะเจาะจงมากขึ้นในวัตถุประสงค์และวิธีการใช้วัตถุที่กำหนดค่าดังนั้นจึงสมเหตุสมผลมากกว่าที่จะกล่าวว่ากลยุทธ์ได้รับการติดตั้งด้วย DI
Jules
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.