คำถามติดแท็ก dependency-injection

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

553 design-patterns  dependency-injection  anti-patterns  caching 

ดังนั้นฉันเริ่มโครงการใหม่ใน Java และกำลังพิจารณาใช้ Spring ทำไมฉันถึงต้องพิจารณาสปริง เพราะมีคนมากมายบอกฉันว่าฉันควรใช้ Spring! อย่างจริงจังทุกครั้งที่ฉันพยายามให้ผู้คนอธิบายว่าสปริงคืออะไรหรือทำอะไรพวกเขาไม่สามารถให้คำตอบแบบตรงกับฉันได้ ฉันได้ตรวจสอบอินโทรในเว็บไซต์ SpringSource และพวกมันซับซ้อนหรือเน้นการสอนจริง ๆ และพวกมันก็ไม่มีความคิดที่ดีว่าทำไมฉันถึงควรใช้มันหรือจะทำให้ชีวิตของฉันง่ายขึ้นได้อย่างไร บางครั้งผู้คนขว้างคำว่า "การพึ่งพา" ซึ่งทำให้ฉันสับสนมากยิ่งขึ้นเพราะฉันคิดว่าฉันมีความเข้าใจที่แตกต่างกันเกี่ยวกับความหมายของคำนั้น อย่างไรก็ตามนี่เป็นเพียงเล็กน้อยเกี่ยวกับพื้นหลังและแอพของฉัน: รับการพัฒนาใน Java ในขณะที่ทำการพัฒนาเว็บ back-end ใช่ฉันทำการทดสอบหน่วยเป็นตัน เพื่ออำนวยความสะดวกในเรื่องนี้ฉันมักจะสร้างวิธีการอย่างน้อยสองรุ่น: รุ่นที่ใช้ตัวแปรอินสแตนซ์และรุ่นที่ใช้ตัวแปรที่ส่งผ่านไปยังเมธอดเท่านั้น หนึ่งที่ใช้ตัวแปรอินสแตนซ์เรียกอีกคนหนึ่งที่จัดหาตัวแปรอินสแตนซ์ เมื่อถึงเวลาที่ต้องทดสอบหน่วยฉันใช้ Mockito เพื่อจำลองวัตถุแล้วโทรไปยังวิธีการที่ไม่ใช้ตัวแปรอินสแตนซ์ นี่คือสิ่งที่ฉันเข้าใจเสมอว่า "การฉีดพึ่งพา" แอพของฉันค่อนข้างเรียบง่ายจากมุมมอง CS โครงการขนาดเล็ก 1-2 นักพัฒนาที่จะเริ่มต้นด้วย การดำเนินการประเภท CRUD ส่วนใหญ่ที่มีการค้นหามากมายถูกโยนเข้ามาโดยทั่วไปแล้วเว็บเซอร์วิส RESTful รวมทั้งเว็บฟรอนต์เอนด์และในที่สุดก็มีลูกค้ามือถือบางส่วน ฉันกำลังคิดที่จะทำ front-end ด้วย HTML / CSS / JS / JQuery …

237 java  frameworks  dependency-injection  spring 

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

124 design-patterns  dependency-injection 

การฉีดพึ่งพา (DI) เป็นรูปแบบที่รู้จักกันดีและทันสมัย วิศวกรส่วนใหญ่ทราบถึงข้อดีของมันเช่น: ทำให้การแยกในการทดสอบหน่วยเป็นไปได้ / ง่าย การกำหนดการขึ้นต่อกันของคลาสอย่างชัดเจน ยกตัวอย่างเช่นการออกแบบที่ดี ( หลักการความรับผิดชอบเดี่ยว (SRP)) เปิดใช้งานการสลับการใช้งานอย่างรวดเร็ว ( DbLoggerแทนที่จะConsoleLoggerเป็นตัวอย่าง) ฉันคิดว่ามีฉันทามติอุตสาหกรรมที่ DI เป็นรูปแบบที่ดีมีประโยชน์ ไม่มีการวิจารณ์มากเกินไปในขณะนี้ ข้อเสียที่กล่าวถึงในชุมชนมักจะน้อย บางส่วนของพวกเขา: เพิ่มจำนวนคลาส สร้างอินเตอร์เฟสที่ไม่จำเป็น ขณะนี้เราหารือเกี่ยวกับการออกแบบสถาปัตยกรรมกับเพื่อนร่วมงานของฉัน เขาค่อนข้างอนุรักษ์นิยม แต่เปิดใจ เขาชอบตั้งคำถามกับสิ่งต่าง ๆ ซึ่งฉันคิดว่าดีเพราะหลาย ๆ คนในวงการไอทีแค่คัดลอกเทรนด์ล่าสุดทำซ้ำข้อดีและโดยทั่วไปแล้วไม่คิดมากเกินไป - อย่าวิเคราะห์ลึกเกินไป สิ่งที่ฉันต้องการถามคือ: เราควรใช้การฉีดพึ่งพาเมื่อเรามีเพียงหนึ่งการดำเนินการ? เราควรห้ามการสร้างวัตถุใหม่ยกเว้นภาษา / กรอบงานหรือไม่? การฉีดความคิดที่ไม่ดีในการนำไปใช้งานเพียงครั้งเดียว (สมมติว่าเรามีการนำไปใช้เพียงครั้งเดียวดังนั้นเราจึงไม่ต้องการสร้างอินเทอร์เฟซ "ว่างเปล่า") ถ้าเราไม่ได้วางแผนทดสอบหน่วยเฉพาะชั้นเรียนหรือไม่

118 design-patterns  architecture  dependency-injection 

ฉันได้เห็นการอ้างอิงจำนวนมากของ Dependency Injection (DI) & Inversion Of Control (IOC) แต่ฉันไม่รู้จริง ๆ ว่ามีความแตกต่างระหว่างพวกเขาหรือไม่ ฉันต้องการเริ่มใช้หนึ่งหรือทั้งสองอย่าง แต่ฉันสับสนเล็กน้อยว่ามันแตกต่างกันอย่างไร

117 dependency-injection  inversion-of-control 

ฉันกำลังอ่านเกี่ยวกับการฉีดพึ่งพา (DI) สำหรับฉันมันเป็นสิ่งที่ซับซ้อนมากที่ต้องทำขณะที่ฉันอ่านมันคือการอ้างอิงการกลับตัวควบคุม (IoC) เช่นกันและฉันรู้สึกว่าฉันจะต้องเดินทาง นี่คือความเข้าใจของฉัน: แทนที่จะสร้างแบบจำลองในคลาสที่ใช้งานคุณส่ง (ฉีด) โมเดล (เต็มไปด้วยคุณสมบัติที่น่าสนใจ) ไปยังตำแหน่งที่ต้องการ (ไปยังคลาสใหม่ซึ่งอาจใช้เป็นพารามิเตอร์ใน ตัวสร้าง) สำหรับฉันนี่เป็นเพียงการโต้แย้ง ฉันต้องคิดถึงจุดที่เข้าใจ บางทีมันอาจจะชัดเจนมากขึ้นกับโครงการขนาดใหญ่? ความเข้าใจของฉันไม่ใช่ -Di (ใช้รหัสเทียม): public void Start() { MyClass class = new MyClass(); } ... public MyClass() { this.MyInterface = new MyInterface(); } และ DI ก็จะเป็น public void Start() { MyInterface myInterface = new MyInterface(); …

109 dependency-injection 

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

107 dependency-injection  ioc-containers  service-locator 

ฉันเข้าใจถึงคุณค่าของการทดสอบอัตโนมัติและใช้งานได้ทุกที่ที่ปัญหามีการระบุไว้อย่างดีพอที่จะทำให้เกิดกรณีทดสอบที่ดี ฉันสังเกตเห็นว่าบางคนที่นี่และใน StackOverflow เน้นการทดสอบเพียงหน่วยเดียวไม่ใช่การพึ่งพา ที่นี่ฉันไม่เห็นประโยชน์ การเยาะเย้ย / การขัดถูเพื่อหลีกเลี่ยงการทดสอบการพึ่งพาเพิ่มความซับซ้อนให้กับการทดสอบ มันเพิ่มความยืดหยุ่นในการประดิษฐ์ / การแยกชิ้นส่วนข้อกำหนดในรหัสการผลิตของคุณเพื่อรองรับการเยาะเย้ย (ฉันไม่เห็นด้วยกับใครก็ตามที่บอกว่าสิ่งนี้ส่งเสริมการออกแบบที่ดีเขียนโค้ดพิเศษแนะนำสิ่งต่าง ๆ เช่นกรอบการฉีดพึ่งพาหรือเพิ่มความซับซ้อนให้กับโค้ดเบสของคุณเพื่อให้สิ่งที่ยืดหยุ่น / pluggable / extensible / decoupled การออกแบบที่ดี.) ประการที่สองการทดสอบการพึ่งพาหมายความว่ารหัสระดับต่ำที่สำคัญที่ใช้ในทุกที่ได้รับการทดสอบด้วยอินพุตนอกเหนือจากที่ผู้เขียนการทดสอบคิดอย่างชัดเจน ฉันได้พบข้อบกพร่องมากมายในการทำงานระดับต่ำโดยใช้การทดสอบหน่วยในการทำงานระดับสูงโดยไม่ต้องเยาะเย้ยการทำงานระดับต่ำที่มันขึ้นอยู่กับ โดยหลักการแล้วสิ่งเหล่านี้จะถูกค้นพบโดยการทดสอบหน่วยสำหรับฟังก์ชั่นระดับต่ำ แต่กรณีพลาดมักเกิดขึ้นเสมอ ด้านนี้คืออะไร? เป็นสิ่งสำคัญจริง ๆ ที่การทดสอบหน่วยไม่ได้ทดสอบการพึ่งพาของมันด้วย? ถ้าเป็นเช่นนั้นทำไม แก้ไข: ฉันสามารถเข้าใจคุณค่าของการเยาะเย้ยการพึ่งพาภายนอกเช่นฐานข้อมูลเครือข่ายบริการเว็บ ฯลฯ (ขอบคุณ Anna Lear สำหรับการจูงใจให้ฉันชี้แจงสิ่งนี้) ฉันหมายถึงการพึ่งพาภายในเช่นคลาสอื่น ๆ ฟังก์ชั่นคงที่ ฯลฯ ที่ไม่มีการพึ่งพาภายนอกโดยตรง

103 testing  unit-testing  dependency-injection  mocking 

แจ้งให้ทราบว่าฉันเป็นแฟนตัวยงของการฉีด (DI) และการทดสอบอัตโนมัติ ฉันสามารถพูดได้ทั้งวันเกี่ยวกับเรื่องนี้ พื้นหลัง เมื่อเร็ว ๆ นี้ทีมงานของเราเพิ่งได้รับโครงการขนาดใหญ่ที่จะสร้างขึ้นใหม่ทั้งหมด มันเป็นแอปพลิเคชั่นเชิงกลยุทธ์ที่มีความต้องการทางธุรกิจที่ซับซ้อน แน่นอนฉันต้องการให้มันดีและสะอาดซึ่งสำหรับฉันหมายถึง: บำรุงรักษาและทดสอบได้ ดังนั้นฉันต้องการใช้ DI ความต้านทาน ปัญหาเกิดขึ้นในทีมของเรา DI คือข้อห้าม มันถูกนำขึ้นมาสองสามครั้ง แต่พระเจ้าไม่เห็นด้วย แต่นั่นก็ไม่ได้ทำให้ฉันท้อแท้ ย้ายของฉัน สิ่งนี้อาจฟังดูแปลก แต่ห้องสมุดบุคคลที่สามมักไม่ได้รับการอนุมัติจากทีมสถาปนิกของเรา (คิดว่า: "อย่าพูดถึงUnity , Ninject , NHibernate , MoqหรือNUnitเพื่อมิให้ฉันตัดนิ้ว" ดังนั้นแทนที่จะใช้คอนเทนเนอร์ DI ที่สร้างไว้ฉันจึงเขียนคอนเทนเนอร์ที่แสนง่าย โดยทั่วไปจะเชื่อมโยงการพึ่งพาทั้งหมดของคุณเมื่อเริ่มต้นใช้งานฉีดการพึ่งพาใด ๆ (คอนสตรัคเตอร์ / คุณสมบัติ) และกำจัดวัตถุที่ใช้แล้วทิ้งใด ๆ ที่ส่วนท้ายของคำขอเว็บ มันเบามากและทำในสิ่งที่เราต้องการ จากนั้นฉันก็ขอให้พวกเขาทบทวนมัน การตอบสนอง ดีที่จะทำให้มันสั้น ฉันได้พบกับการต่อต้านอย่างหนัก อาร์กิวเมนต์หลักคือ "เราไม่จำเป็นต้องเพิ่มความซับซ้อนของเลเยอร์นี้ลงในโครงการที่มีความซับซ้อนอยู่แล้ว" นอกจากนี้ …

95 dependency-injection 

เมื่อออกแบบระบบฉันมักจะประสบกับปัญหาการมีโมดูลจำนวนมาก (การบันทึก, acces ฐานข้อมูล, ฯลฯ ) ถูกใช้โดยโมดูลอื่น ๆ คำถามคือฉันจะไปเกี่ยวกับการให้ส่วนประกอบเหล่านี้กับส่วนประกอบอื่น ๆ ได้อย่างไร คำตอบสองคำตอบที่ดูเหมือนจะเป็นไปได้คือการฉีดขึ้นรูปหรือใช้รูปแบบของโรงงาน อย่างไรก็ตามทั้งคู่ดูเหมือนผิด: โรงงานทำการทดสอบความเจ็บปวดและไม่อนุญาตให้สลับการใช้งานได้ง่าย พวกเขายังไม่ได้อ้างอิงที่ชัดเจน (เช่นคุณกำลังตรวจสอบวิธีการโดยไม่คำนึงถึงความจริงที่ว่ามันเรียกวิธีการที่เรียกวิธีการที่เรียกวิธีการที่ใช้ฐานข้อมูล) การฉีด Dependecy จะสร้างรายการอาร์กิวเมนต์ตัวสร้างอย่างหนาแน่นและทำให้มีบางแง่มุมทั่วโค้ดของคุณ สถานการณ์ทั่วไปคือที่คอนสตรัคเตอร์ของคลาสมากกว่าครึ่งมีลักษณะเช่นนี้(....., LoggingProvider l, DbSessionProvider db, ExceptionFactory d, UserSession sess, Descriptions d) นี่เป็นสถานการณ์ทั่วไปที่ฉันมีปัญหากับ: ฉันมีคลาสยกเว้นซึ่งใช้คำอธิบายข้อผิดพลาดที่โหลดจากฐานข้อมูลโดยใช้แบบสอบถามที่มีพารามิเตอร์ของการตั้งค่าภาษาผู้ใช้ซึ่งอยู่ในวัตถุเซสชันผู้ใช้ ดังนั้นเพื่อสร้างข้อยกเว้นใหม่ฉันต้องการคำอธิบายซึ่งต้องการเซสชันฐานข้อมูลและเซสชันผู้ใช้ ดังนั้นฉันถึงวาระที่จะลากวัตถุเหล่านี้ทั้งหมดในวิธีการทั้งหมดของฉันในกรณีที่ฉันอาจต้องโยนข้อยกเว้น ฉันจะจัดการปัญหาดังกล่าวได้อย่างไร?

81 design  dependency-injection  dependencies 

ฉันรู้ว่านี่คือการอภิปรายที่ร้อนแรงและความคิดเห็นมีแนวโน้มที่จะเปลี่ยนแปลงไปตามกาลเวลาเพื่อแนวทางการปฏิบัติที่ดีที่สุด ผมเคยใช้เฉพาะการฉีดฟิลด์สำหรับชั้นเรียนของฉันจนผมเริ่มอ่านบนบล็อกที่แตกต่างกัน (EXS: petrikainulainenและschauderhaftและฟาวเลอร์ ) เกี่ยวกับประโยชน์ของการฉีดสร้าง ฉันได้เปลี่ยนวิธีการของฉันที่จะใช้การฉีดคอนสตรัคสำหรับการพึ่งพาที่จำเป็นและการฉีด Setter สำหรับการพึ่งพาตัวเลือก อย่างไรก็ตามเมื่อไม่นานมานี้ฉันได้มีการถกเถียงกับผู้เขียน JMockit ซึ่งเป็นกรอบการเยาะเย้ยซึ่งเขาเห็นว่าการสร้างคอนสตรัคเตอร์และสุนัขเซทเทอร์เตอร์เป็นการปฏิบัติที่ไม่ดีและบ่งชี้ว่าชุมชน JEE เห็นด้วยกับเขา ในโลกปัจจุบันมีวิธีที่เหมาะสมกว่าในการฉีดหรือไม่? การฉีดภาคสนามเป็นที่ต้องการหรือไม่? หลังจากเปลี่ยนไปใช้คอนสตรัคเตอร์ฉีดจากการฉีดภาคสนามในช่วงสองสามปีที่ผ่านมาฉันพบว่ามันชัดเจนกว่าที่จะใช้ แต่ฉันสงสัยว่าฉันควรตรวจสอบมุมมองของฉันอีกครั้งหรือไม่ ผู้เขียนJMockit (Rogério Liesenfeld)มีความเชี่ยวชาญใน DI อย่างชัดเจนดังนั้นฉันรู้สึกผูกพันที่จะต้องทบทวนวิธีการของฉันเนื่องจากเขารู้สึกอย่างยิ่งกับการฉีดคอนสตรัคเตอร์ / สุนัขเซทเตอร์

61 java  dependency-injection  java-ee 

ในช่วงไม่กี่ปีที่ผ่านมาเราได้ค่อยๆเปลี่ยนไปใช้โค้ดที่ดีขึ้นอย่างค่อยเป็นค่อยไปในเวลาไม่กี่ก้าว ในที่สุดเราก็เริ่มที่จะเปลี่ยนไปใช้สิ่งที่คล้ายกับ SOLID อย่างน้อยที่สุด แต่เรายังไม่ถึงจุดนั้น นับตั้งแต่ทำการสลับหนึ่งในข้อร้องเรียนที่ใหญ่ที่สุดจากนักพัฒนาคือพวกเขาไม่สามารถยืนทบทวนและตรวจสอบไฟล์หลายสิบไฟล์ซึ่งก่อนหน้านี้ทุกงานต้องการเพียงผู้พัฒนาที่สัมผัส 5-10 ไฟล์ ก่อนที่จะเริ่มสวิตช์สถาปัตยกรรมของเราได้รับการจัดระเบียบอย่างดีดังต่อไปนี้ (ให้สิทธิ์โดยมีหนึ่งหรือสองไฟล์ที่มีขนาดมากกว่าหนึ่งคำสั่ง): Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI ไฟล์ฉลาดทุกอย่างเป็นเส้นตรงและกะทัดรัดอย่างเหลือเชื่อ เห็นได้ชัดว่ามีการทำสำเนารหัสจำนวนมากการมีเพศสัมพันธ์อย่างแน่นหนาและปวดหัวอย่างไรก็ตามทุกคนสามารถเข้าไปสำรวจและคิดออกได้ สามเณรที่สมบูรณ์ผู้ที่ไม่เคยเปิด Visual Studio …

49 c#  coding-style  dependency-injection  solid  single-responsibility 

ฉันได้ดูคำว่า constructor injection และการพึ่งพาในขณะที่อ่านบทความเกี่ยวกับรูปแบบการออกแบบ (Service locator) เมื่อฉันไปเกี่ยวกับการฉีดคอนสตรัคเตอร์ฉันได้ผลลัพธ์ที่ไม่ชัดเจนซึ่งทำให้ฉันเช็คอินที่นี่ ตัวสร้างการฉีดคืออะไร? นี่เป็นการฉีดแบบพึ่งพาหรือไม่? ตัวอย่างที่ยอมรับได้จะเป็นความช่วยเหลือที่ดี! แก้ไข กลับมาที่คำถามนี้อีกครั้งหลังจากผ่านไปหนึ่งสัปดาห์ฉันจะเห็นว่าฉันหลงทางได้อย่างไร ... ในกรณีที่มีใครปรากฏขึ้นที่นี่ฉันจะอัปเดตคำถามโดยมีการเรียนรู้เล็กน้อยของฉัน กรุณาอย่าลังเลที่จะแสดงความคิดเห็น / ถูกต้อง คอนสตรัคเตอร์การฉีดและการฉีดคุณสมบัติเป็นสองประเภทของการพึ่งพาการฉีด

47 c#  dependency-injection 

เพื่อนร่วมงานของฉันชอบพูดว่า "การบันทึก / การแคช / ฯลฯ เป็นข้อกังวลข้าม" จากนั้นดำเนินการใช้ซิงเกิลที่เกี่ยวข้องทุกที่ พวกเขารัก IoC และ DI มันเป็นข้อแก้ตัวที่ถูกต้องหรือไม่ที่จะทำลายหลักการของ SOLI D ?

43 dependency-injection  solid  anti-patterns  singleton 

ฉันกำลังพยายามหา SOLID อยู่ ดังนั้นหลักการการพึ่งพาการพึ่งพาจึงหมายความว่าสองคลาสใด ๆ ควรสื่อสารผ่านอินเทอร์เฟซไม่ใช่โดยตรง ตัวอย่าง: หากclass Aมีวิธีที่คาดว่าตัวชี้ไปยังวัตถุของการพิมพ์แล้ววิธีนี้ควรจริงคาดว่าวัตถุของการพิมพ์class B abstract base class of Bสิ่งนี้จะช่วยในการเปิด / ปิดเช่นกัน โดยมีเงื่อนไขว่าฉันเข้าใจที่ถูกต้องคำถามของฉันจะเป็นมันเป็นวิธีที่ดีที่จะใช้นี้ทั้งหมดปฏิสัมพันธ์ชั้นเรียนหรือฉันควรพยายามที่จะคิดในแง่ของชั้น ? เหตุผลที่ฉันสงสัยก็เพราะเราจ่ายราคาบางอย่างสำหรับการทำตามหลักการนี้ บอกว่าฉันต้องใช้คุณสมบัติZนี้ หลังจากการวิเคราะห์ผมสรุปได้ว่าคุณลักษณะที่Zประกอบด้วยฟังก์ชั่นA, และB Cฉันจะสร้างซุ้มระดับZที่ผ่านอินเตอร์เฟซที่ใช้เรียนA, และB Cฉันเริ่มต้นการเข้ารหัสและการดำเนินการในบางจุดที่ผมทราบดีว่างานที่Zจริงประกอบด้วยฟังก์ชั่นA, และB Dตอนนี้ฉันต้องทำให้เสียCอินเตอร์เฟส, Cคลาสต้นแบบและเขียนDอินเตอร์เฟสและคลาสแยกกัน หากไม่มีอินเทอร์เฟซจะต้องเปลี่ยนคลาสเท่านั้น กล่าวอีกนัยหนึ่งคือการเปลี่ยนแปลงบางสิ่งฉันต้องเปลี่ยน 1. ผู้โทร 2. ส่วนต่อประสาน 3. การประกาศ 4. การดำเนินการ ในไพ ธ อนการใช้งานร่วมกันโดยตรงฉันจะต้องเปลี่ยนเฉพาะการใช้งานเท่านั้น

43 design  dependency-injection  solid