เมื่อไหร่ใช้ composition เมื่อไหร่ใช้ inheritance

ทำไมเรายังต้องคุยเรื่องนี้กันอีกนะ

สรุปแบบขี้เกียจอ่าน

โดยมุมมองจาก Emergent Design

• Inherit เมื่อต้องการบังคับว่า ทั้งหมดเหมือนเดิมยกเว้นจุดเล็กๆ
• Composite เมื่อต้องการตัดจุดหนึ่งออกมาจากส่วนเดิมที่สามารถมี implementation หลายแบบ (encapsulate variations)
• Composite over Inheritance เพราะปัญหาการออกแบบจำนวนมาก เป็นการลดความซับซ้อนโดยการ encapsulate variations
• ใช้ Commonality-Variability Analysis เสมอเวลาออกแบบ อย่ารีบ encapsulate สิ่งที่ยังไม่จำเป็น(ด้วย composite)

Inheritance มาจากไหน

มักเกิดจากการที่เราเอาของเดิม มา “แก้นิดเดียว” ให้ได้การทำงานตามต้องการ เช่น เรามีโปรแกรมนึง อ่านจากไฟล์ ประมวลผล แล้วพิมพ์ออกหน้าจอ ซึ่งต่อมาต้องการให้พิมพ์ออกเครื่องพิมพ์ด้วย

แบบนี้เรากำลังบอกคนอื่นว่า มีโปรแกรมอยู่แล้ว มีอีกตัวนึงซึ่งเหมือนตัวเดิมเลยแค่แก้ตอนเขียนเป็นเขียนไฟล์แทน ซึ่งไม่น่าจะตรงกับสิ่งที่เราจะสื่อ

แปลงเป็น Composite

สิ่งที่เราต้องการจะสื่อ น่าจะเป็นว่า มีโปรแกรมอยู่ตัวเดียว แต่มีการเขียนออกไปได้สองทางคือ 1. หน้าจอ 2. เครื่องพิมพ์

ซึ่งก็คือ การ encapsulate การ write ออกมาต่างหากแบบนี้

เมื่อไหร่ใช้ Inhertance

ในอีกมุมนึง ถ้าเราอยากจะบอกว่า โปรแกรมของเราต้องมีการทำงานตามลำดับนี้

1. อ่าน 2. ประมวลผล 3. เขียน

และเราบังคับให้โปรแกรมอื่นๆอีกหลายอัน ที่ออกมาจากต้นแบบของเราจะมีลำดับตามที่กำหนดข้างบน แต่มีส่วน (2. ประมวลผล) เท่านั้นที่ต่างกัน จะได้แบบนี้

ทำไมเรายังต้องคุยเรื่องนี้กันอีกนะ

ทำไมเราไม่ทำ Commonality-Variability Analysis อย่างสม่ำเสมอ แล้วจะชัดเองว่าควรทำอะไร โดยเน้นความเข้าใจตรงกับโปรแกรมเมอร์คนอื่นๆว่าเราต้องการซ่อนความซับซ้อนไว้ตรงไหน

ของบางอย่างที่เหมาะกับ inheritance นานๆไปซับซ้อนขึ้นอาจจะเหมาะกับ composite มากกว่าก้อได้ (มักจะไม่ไปในทางกลับกัน)

ในอีกมุมนึง ถ้าของยังไม่มี variation จะไปรีบไปตัดออกมาก็จะเป็นการเพิ่มความซับซ้อนให้กับโปรแกรมเปล่าๆ