Why Such Similar Names for Coupling Metrics? (ทำไม metric ของ coupling ถึงมีชื่อคล้ายกันขนาดนี้)

ทำไม metric สำคัญสองตัวในโลกสถาปัตยกรรมที่แทนแนวคิด ตรงข้ามกัน ถึงมีชื่อที่แทบจะเหมือนกัน ต่างกันแค่สระที่ฟังดูคล้ายกันที่สุด? คำเหล่านี้มาจากหนังสือ Structured Design Yourdon และ Constantine ยืมแนวคิดจากคณิตศาสตร์มาบัญญัติคำว่า afferent และ efferent coupling ที่กลายเป็นคำสามัญในปัจจุบัน จริง ๆ แล้วควรจะเรียกว่า incoming และ outgoing coupling มากกว่า แต่ผู้เขียนเลือกความสมมาตรทางคณิตศาสตร์มากกว่าความชัดเจน นักพัฒนาจึงคิดค้นวิธีจำหลายแบบขึ้นมาช่วย ตัวอย่างเช่น a มาก่อน e ในตัวอักษรภาษาอังกฤษ เช่นเดียวกับที่ incoming มาก่อน outgoing ตัวอักษร e ใน efferent ตรงกับตัวอักษรแรกของคำว่า exit ซึ่งช่วยให้จำได้ว่ามันแทนการเชื่อมต่อขาออก

Core Metrics (metric หลัก)

แม้ component coupling จะมีคุณค่าดิบต่อสถาปนิกอยู่แล้ว แต่ยังมี metric ที่แตกยอดออกมาอีกหลายตัวที่ช่วยให้ประเมินได้ลึกซึ้งยิ่งขึ้น metric ที่กล่าวถึงในหัวข้อนี้ถูกสร้างขึ้นโดยวิศวกรซอฟต์แวร์ Robert C. Martin และใช้ได้กว้างขวางกับภาษาเชิงวัตถุส่วนใหญ่

Abstractness คืออัตราส่วนของ artifact แบบ abstract (abstract class, interface และอื่น ๆ) ต่อ artifact แบบ concrete (implementation) metric Abstractness วัดระดับความเป็นนามธรรมของโค้ดเบสเทียบกับการ implement ตัวอย่างเช่น ปลายด้านหนึ่งของสเกลคือโค้ดเบสที่ไม่มี abstraction เลย มีแค่ฟังก์ชันขนาดใหญ่ตัวเดียว (เช่น method main() ตัวเดียว) ส่วนอีกปลายหนึ่งของสเกลคือโค้ดเบสที่มี abstraction มากเกินไป จนนักพัฒนาเข้าใจได้ยากว่าสิ่งต่าง ๆ เชื่อมต่อกันอย่างไร (ตัวอย่างเช่น นักพัฒนาต้องใช้เวลานานกว่าจะเข้าใจว่าจะใช้ abstract class AbstractSingletonProxyFactoryBean อย่างไร เนื่องจากมันมีชั้นของ abstraction ซ้อนกันหลายชั้นและชื่อที่กำกวม)

สูตรของ Abstractness ปรากฏใน Equation 3-3

Equation 3-3. Abstractness

A \= ∑ m a ∑ m c + ∑ m a

สถาปนิกคำนวณ Abstractness โดยหาอัตราส่วนของผลรวม artifact แบบ abstract ต่อผลรวมของ artifact แบบ concrete และ abstract รวมกัน ในสมการนี้ m a แทนองค์ประกอบแบบ abstract (interface หรือ abstract class) ภายใน module และ m c แทนองค์ประกอบแบบ concrete (คลาสที่ไม่ใช่ abstract) metric นี้พิจารณาเกณฑ์เดียวกัน วิธีที่ง่ายที่สุดในการจินตนาการภาพ metric นี้คือลองนึกถึงแอปพลิเคชันที่มีโค้ด 5,000 บรรทัด ทั้งหมดอยู่ใน method main() เดียว ตัวเศษของ Abstractness จะเป็น 1 ในขณะที่ตัวส่วนจะเป็น 5,000 ทำให้ได้คะแนน Abstractness เกือบเป็น 0 นี่คือวิธีที่ metric นี้วัดสัดส่วนของ abstraction ในโค้ด

metric ที่แตกยอดมาอีกตัวคือ Instability ซึ่งนิยามเป็นอัตราส่วนของ efferent coupling ต่อผลรวมของทั้ง efferent และ afferent coupling ดังแสดงใน Equation 3-4

Equation 3-4. Instability

I \= C e C e + C a

ในสมการนี้ c e แทน efferent (หรือ outgoing) coupling และ c a แทน afferent (หรือ incoming) coupling

metric Instability กำหนด ความผันผวน (volatility) ของโค้ดเบส โค้ดเบสที่แสดงระดับ instability สูงจะพังได้ง่ายกว่าเมื่อมีการเปลี่ยนแปลง เนื่องจากมี coupling สูง ตัวอย่างเช่น หากคลาสหนึ่งเรียกคลาสอื่นจำนวนมากเพื่อกระจายงาน คลาสที่เรียกจะเสี่ยงพังง่ายหากมี method ที่ถูกเรียกตัวใดตัวหนึ่งเปลี่ยนแปลง

Distance from the Main Sequence (ระยะห่างจาก Main Sequence)

หนึ่งใน metric แบบองค์รวม (holistic) ไม่กี่ตัวที่สถาปนิกมีไว้ใช้วิเคราะห์โครงสร้างสถาปัตยกรรมคือ Distance from the Main Sequence ซึ่งเป็น metric ที่แตกยอดมาจาก Instability และ Abstractness ดังแสดงใน Equation 3-5

Equation 3-5. Distance from the Main Sequence

D \= | A + I - 1 |

ในสมการนี้ A \= Abstractness และ I \= Instability

โปรดสังเกตว่าทั้ง Abstractness และ Instability เป็นเศษส่วนที่ผลลัพธ์จะอยู่ระหว่าง 0 ถึง 1 เสมอ (ยกเว้นบางกรณีที่สุดโต่ง) ดังนั้น เมื่อพลอตความสัมพันธ์นี้ออกมาจะได้กราฟตาม Figure 3-2

Figure 3-2. Main sequence กำหนดความสัมพันธ์ในอุดมคติระหว่าง Abstractness และ Instability

metric Distance จินตนาการถึงความสัมพันธ์ในอุดมคติระหว่าง Abstractness และ Instability คลาสที่ตกอยู่ใกล้เส้นในอุดมคตินี้จะมีสัดส่วนที่ดีระหว่างสองปัจจัยที่ขัดแย้งกันนี้ ตัวอย่างเช่น การพลอตกราฟของคลาสหนึ่ง ๆ ช่วยให้นักพัฒนาคำนวณ metric Distance from the Main Sequence ได้ ดังแสดงใน Figure 3-3

Figure 3-3. Distance from the Main Sequence แบบ normalize สำหรับคลาสหนึ่ง ๆ

metric ใน Figure 3-3 พลอตคลาสที่พิจารณาอยู่ แล้ววัดระยะห่างจากเส้นในอุดมคติ ยิ่งใกล้เส้นมากเท่าไร คลาสนั้นก็ยิ่งมีความสมดุลที่ดีมากขึ้นเท่านั้น คลาสที่ตกไปไกลเกินไปทางมุมขวาบนจะเข้าสู่สิ่งที่สถาปนิกเรียกว่า Zone of Uselessness คือ โค้ดที่เป็นนามธรรมมากเกินไปจนใช้งานยาก ในทางกลับกัน โค้ดที่ตกไปในมุมซ้ายล่าง ดังแสดงใน Figure 3-4 จะเข้าสู่ Zone of Pain คือ โค้ดที่มี implementation มากเกินไปและ abstraction ไม่พอ จนเปราะบางและดูแลรักษายาก

Figure 3-4. Zone of Uselessness และ Zone of Pain

หลายแพลตฟอร์มมีเครื่องมือสำหรับคำนวณค่าเหล่านี้ ซึ่งช่วยสถาปนิกเวลาวิเคราะห์โค้ดเบสเพื่อทำความคุ้นเคย เตรียมตัวสำหรับการย้ายระบบ หรือประเมิน technical debt