เมื่อใดที่ Efferent / Afferent coupling ดีหรือไม่ดี


11

ฉันมีการสอบรูปแบบซอฟต์แวร์ในสัปดาห์นี้และหนึ่งในหัวข้อที่เราต้องศึกษาคือการมีเพศสัมพันธ์แบบ Efferent และ Afferent

ฉันเข้าใจแพคเกจที่มี Ce สูง (ข้อต่อที่มีประสิทธิภาพ) ถ้ามันขึ้นอยู่กับประเภทอื่น ๆ

ตัวอย่างเช่น:

class Car{
    Engine engine;
    Wheel wheel;
    Body body;
}

คลาสนี้จะมีคัปปลิ้งที่มีประสิทธิภาพสูงขึ้นอยู่กับประเภทเครื่องยนต์ล้อและตัวถัง

ในขณะที่ประเภท "ล้อ" จะมี Ca สูง (การเชื่อมต่อแบบ afferent) ถ้ามีแพ็คเกจอื่น ๆ หลายอย่างขึ้นอยู่กับมัน (รถยนต์, เครื่องบิน, จักรยาน)

หนึ่งในคำถามที่เป็นไปได้ในการสอบของเราคือเมื่อใดที่เอฟเฟนท์ / เอฟเฟอเรนท์มีเพศสัมพันธ์ดีหรือไม่ดี? สิ่งนี้ดูแปลกสำหรับฉันเพราะเหตุผลโปรแกรมจะต้องมีแพ็คเกจ / คลาสที่มีทั้งคู่ Efferent / Afferent สูง

ไม่มีใครมีตัวอย่างของเมื่อ / ที่สูงออกหรือมีเพศสัมพันธ์ afferent ดี / ไม่ดี?

ขอบคุณมาก!


4
ถ้าเพียง แต่พวกเขาเลือกคำศัพท์ที่สับสนมากขึ้นซึ่งฟังดูเหมือนกันมากขึ้น ...
user949300

คำตอบ:


11

การประเมินการเชื่อมต่อแบบ Afferent นั้นสามารถประเมินได้ง่ายที่สุดในแง่ของความเจ็บปวดที่เกิด / บันทึกเนื่องจากความจำเป็นในการเปลี่ยนแปลงหรือความเป็นไปได้ ตัวอย่างเช่นใช้คลาสล้อของคุณและสมมติว่ามีโมดูลอื่น ๆ มากมายที่ใช้เพื่อสร้างยานพาหนะประเภทต่าง ๆ ถ้าระดับล้อมีความเสถียรอย่างยิ่งการมีเพศสัมพันธ์แบบนี้จะเป็นประโยชน์เนื่องจากยานพาหนะต้องการล้อและพวกเขากำลังใช้ล้อที่เชื่อถือได้ หากในอีกทางหนึ่งระดับล้อมีความผันผวนในแง่ของการบำรุงรักษาการมีเพศสัมพันธ์แบบ afferent นี้จะเป็นจุดปวดในขณะที่คุณแนะนำการเปลี่ยนแปลงที่ผิดพลาดซ้ำ ๆ กับรหัสจำนวนมาก

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

เมื่อพูดถึงสถาปัตยกรรม / การออกแบบสิ่งที่คุณต้องพิจารณาจริงๆคือการแลกเปลี่ยนที่ไม่สิ้นสุดและตัวชี้วัดเหล่านี้ไม่แตกต่างกัน หากคุณต้องการหาตัวอย่างของสิ่งที่ดีหรือไม่ดีให้เล่นเกม "ถ้า" ลองนึกภาพตัวอย่างและพูดว่า "จะทำอย่างไรถ้าฉันต้องการทำ X - มันจะดูดมากแค่ไหน?" สำหรับ X ที่คำตอบคือ "มาก" คุณมีข้อเสียและสำหรับ X ที่คำตอบคือ "ที่จริงแล้วง่ายมาก" คุณมีข้อได้เปรียบ


5

การพูดโดยทั่วไปข้อต่อหลวม:

บวก : ปกป้องส่วนหนึ่งของระบบจากการเปลี่ยนแปลงในสิ่งที่มันขึ้นอยู่กับ (การมีเพศสัมพันธ์กัน)

เชิงลบ : ความสัมพันธ์อาจยากต่อการเข้าใจ

ตัวอย่างเช่นถ้าฉันกำลังพัฒนาระบบที่ใช้ HTTTP ฉันจะตัดสินใจว่าฉันต้องแนบ HTTP อย่างแน่นหนาหรือหลวม ๆ หากฉันคิดว่าระบบมีแนวโน้มที่จะเปลี่ยนไปใช้โปรโตคอลอื่นฉันอาจเลือกที่จะคับคู่กับมันอย่างหลวม ๆ ในขณะที่ถ้าฉันยอมรับว่า HTTP เป็นโปรโตคอลของฉัน

พิจารณาว่าความซับซ้อนบางอย่างใน WS * อยู่ในการแยกตัวจาก HTTP เป็นโปรโตคอล


คำตอบที่ชาญฉลาด แต่ฉันไม่เห็นว่ามันเกี่ยวข้องกับคำถามอย่างไรซึ่งเกี่ยวกับการมีเพศสัมพันธ์ที่ออกมา / afferent และการมีเพศสัมพันธ์ไม่แน่น / หลวม
lbalazscs

คุณถูกต้อง @lbalazscs ไม่รู้เลยว่าทำไมฉันตอบโดยไม่ตอบคำถาม!
jayraynet

1

ซึ่งนำเข้ามายังศูนย์กลาง

หากบางสิ่งบางอย่างใช้สิ่งของต่าง ๆ จำนวนมาก (ข้อต่อ afferent จำนวนมาก) ก็อาจเป็นไปได้ที่จะทำลายหากสิ่งเหล่านั้นเปลี่ยนแปลง

ความไม่แน่นอน = 1

ป้อนคำอธิบายรูปภาพที่นี่

ที่นำออกจากศูนย์กลาง

หากมีบางสิ่งถูกใช้โดยกลุ่มของสิ่งต่าง ๆ (ข้อต่อที่มีจำนวนมาก) ก็อาจเป็นไปได้ที่จะทำลายสิ่งต่าง ๆ มากมายหากมีการเปลี่ยนแปลง

ความไม่แน่นอน = 0

ป้อนคำอธิบายรูปภาพที่นี่

ความมั่นคง

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

ดังนั้นการมีเพศสัมพันธ์ที่มีประสิทธิภาพสูงและการมีเพศสัมพันธ์ต่ำจะทำให้เกิดความมั่นคง (ในบางสิ่งที่ยากที่จะเปลี่ยนแปลงเพราะมันจะทำให้สิ่งของแตกต่างกัน) สิ่งที่ตรงกันข้ามจะทำให้เกิดความไม่แน่นอน (ในสิ่งที่ง่ายต่อการเปลี่ยนแปลง .

ข้อต่อข้อต่อจำนวนมากอาจเป็นตัวบ่งชี้ว่าการออกแบบของคุณไม่มีความสำคัญ - มันใช้สิ่งต่าง ๆ มากมายดังนั้นมันอาจจะขาดความรับผิดชอบที่ชัดเจนและเป็นเอกเทศ

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

หลักการบทคัดย่อที่เสถียร

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

การใช้ซ้ำได้กับการใช้ซ้ำ

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.