คำถามติดแท็ก coupling

ฉันมีการสอบรูปแบบซอฟต์แวร์ในสัปดาห์นี้และหนึ่งในหัวข้อที่เราต้องศึกษาคือการมีเพศสัมพันธ์แบบ Efferent และ Afferent ฉันเข้าใจแพคเกจที่มี Ce สูง (ข้อต่อที่มีประสิทธิภาพ) ถ้ามันขึ้นอยู่กับประเภทอื่น ๆ ตัวอย่างเช่น: class Car{ Engine engine; Wheel wheel; Body body; } คลาสนี้จะมีคัปปลิ้งที่มีประสิทธิภาพสูงขึ้นอยู่กับประเภทเครื่องยนต์ล้อและตัวถัง ในขณะที่ประเภท "ล้อ" จะมี Ca สูง (การเชื่อมต่อแบบ afferent) ถ้ามีแพ็คเกจอื่น ๆ หลายอย่างขึ้นอยู่กับมัน (รถยนต์, เครื่องบิน, จักรยาน) หนึ่งในคำถามที่เป็นไปได้ในการสอบของเราคือเมื่อใดที่เอฟเฟนท์ / เอฟเฟอเรนท์มีเพศสัมพันธ์ดีหรือไม่ดี? สิ่งนี้ดูแปลกสำหรับฉันเพราะเหตุผลโปรแกรมจะต้องมีแพ็คเกจ / คลาสที่มีทั้งคู่ Efferent / Afferent สูง ไม่มีใครมีตัวอย่างของเมื่อ / ที่สูงออกหรือมีเพศสัมพันธ์ afferent ดี / …

11 design-patterns  patterns-and-practices  coupling 

ติดตามจากกระทู้นี้ฉันเริ่ม รูปแบบซิงเกิล ฉันคิดว่าชั้นเรียนของฉันเป็นอย่างไรและวิธีที่ดีที่สุดในการมีเพศสัมพันธ์แบบหลวม ๆ โปรดจำไว้ว่าฉันเป็นโปรแกรมเมอร์ใหม่ (4 เดือนในงานแรกของฉัน) และนี่เป็นข้อพิจารณาแรกที่ฉันได้รับจากสิ่งนี้และฉันกระตือรือร้นที่จะเข้าใจแนวคิดนี้ แล้วอะไรคือข้อต่อหลวม ๆ และการมีเพศสัมพันธ์อย่างหนัก? ในโครงการปัจจุบันของฉัน (และโครงการแรก) ฉันกำลังทำงานในโครงการ ac # winforms ซึ่งส่วน GUI สร้างวัตถุและ subcribes กับกิจกรรมของพวกเขาเมื่อพวกเขาถูกทริกเกอร์ GUI สร้างวัตถุอื่น (ในตัวอย่างนี้ datagridview (คลาส) ที่ฉันได้สร้างที่ล้อมรอบ DataGridview มาตรฐานและเพิ่มฟังก์ชั่นเพิ่มเติม) และแนบไปกับ GUI นี่คือการแต่งงานกันหรือไม่ดี? ฉันไม่ต้องการรับนิสัยที่ไม่ดีและเริ่มเขียนโค้ดไม่ดีดังนั้นฉันจะขอบคุณคำตอบของคุณ

11 language-agnostic  coupling 

ประเด็นหลัก เห็นการสนับสนุนที่ดีมากที่สุดแพลตฟอร์มการเขียนโปรแกรมที่ทันสมัยมีการบริหารจัดการแพคเกจ (คิดว่าgem, npm, pipฯลฯ ) ไม่ได้ทำให้ความรู้สึกในการออกแบบโปรแกรมหรือระบบจะประกอบด้วยแพคเกจการพัฒนาภายในเพื่อส่งเสริมและสร้างสถาปัตยกรรมคู่หลวม? ตัวอย่าง ตัวอย่างนี้จะสร้างแพคเกจสำหรับการเข้าถึงฐานข้อมูลรวมถึงการตรวจสอบและส่วนประกอบอื่น ๆ ของระบบ แน่นอนว่าใช้แพ็คเกจภายนอกด้วย จากนั้นระบบของคุณจะนำเข้าและใช้แพ็คเกจเหล่านี้แทนที่จะรวมรหัสไว้ในฐานรหัสของตนเอง การพิจารณา สำหรับฉันดูเหมือนว่าสิ่งนี้จะส่งเสริมการแยกรหัสและช่วยให้สามารถบำรุงรักษาได้เกือบจะเป็นแอพพลิเคชั่นบนเว็บเทียบกับเดสก์ท็อป (มีการใช้งานการอัปเดตเกือบอัตโนมัติโดยใช้ฐานรหัสเดียวสำหรับการใช้งานเดียว ดูเหมือนว่าแนวคิดการออกแบบที่สมเหตุสมผลและมีเหตุผลหรือไม่ สิ่งนี้ใช้จริง ๆ แล้วเป็นวิธีมาตรฐานในการสร้างแอพพลิเคชั่นในปัจจุบันหรือไม่?

10 design  design-patterns  architecture  packages  coupling 

บางครั้งวัตถุก็จำเป็นต้องมีการรวมกันอย่างแน่นหนา ตัวอย่างเช่นCsvFileคลาสอาจต้องทำงานอย่างแน่นหนากับCsvRecordคลาส (หรือICsvRecordอินเทอร์เฟซ) อย่างไรก็ตามจากสิ่งที่ฉันได้เรียนรู้ในอดีตหนึ่งในหลักการสำคัญของการพัฒนาที่ขับเคลื่อนด้วยการทดสอบคือ "อย่าทดสอบมากกว่าหนึ่งคลาสในเวลาเดียวกัน" หมายความว่าคุณควรใช้ICsvRecordmocks CsvRecordหรือไม่สมบูรณ์มากกว่ากรณีที่แท้จริงของ อย่างไรก็ตามหลังจากลองใช้วิธีนี้ฉันสังเกตว่าการเยาะเย้ยในCsvRecordชั้นเรียนอาจทำให้ขนดกเล็กน้อย ซึ่งทำให้ฉันเป็นหนึ่งในสองข้อสรุป: ยากที่จะเขียนการทดสอบหน่วย! นั่นคือกลิ่นรหัส! ปรับปรุงโครงสร้าง! การเย้ยหยันการพึ่งพาอาศัยกันทุกครั้งนั้นไม่สมเหตุสมผล เมื่อฉันแทนที่ mocks ของฉันด้วยCsvRecordอินสแตนซ์ที่เกิดขึ้นจริงสิ่งต่าง ๆ เป็นไปอย่างราบรื่นมากขึ้น เมื่อมองไปรอบ ๆ สำหรับความคิดของคนอื่นฉันก็สะดุดกับโพสต์บล็อกนี้ซึ่งดูเหมือนจะสนับสนุน # 2 ข้างต้น สำหรับวัตถุที่อยู่คู่กันอย่างเป็นธรรมชาติเราไม่ควรกังวลกับการล้อเลียน ฉันจะออกนอกเส้นทาง? มีข้อเสียข้อสันนิษฐาน # 2 ข้างต้นหรือไม่ ฉันควรจะคิดเกี่ยวกับการปรับโครงสร้างการออกแบบใหม่หรือไม่?

10 tdd  coupling  mocking 

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

9 architecture  rest  enterprise-architecture  microservices  coupling