งานวิจัยปี 1998 ที่เสนอ Extensible Visitor pattern เพื่อเชื่อมโยงการเขียนโปรแกรมแบบฟังก์ชันและเชิงวัตถุได้จุดประกายการอภิปรายเกี่ยวกับความท้าทายพื้นฐานในการออกแบบภาษาโปรแกรมมิ่งอีกครั้ง งานวิจัยนี้แก้ไขปัญหาที่เรียกว่า expression problem ซึ่งเป็นความยากลำบากในการขยายทั้งประเภทข้อมูลและการดำเนินการโดยไม่ต้องแก้ไขโค้ดที่มีอยู่
บริบทเส้นเวลา (1998)
- Java มีอยู่แล้วแต่ยังไม่มี generics
- Scala ยังไม่ได้ถูกสร้างขึ้น
- Haskell implementations มีอยู่แล้วแต่มีข้อจำกัดด้านประสิทธิภาพ
- Common Lisp Object System ( CLOS ) มีอยู่แล้วตั้งแต่ช่วงทศวรรษ 1980
ความท้าทายหลักในการเขียนโปรแกรม
งานวิจัยนี้จัดการกับปัญหาที่ยังคงอยู่ในการพัฒนาซอฟต์แวร์ คือ วิธีการขยายโปรแกรมในสองมิติพร้อมกัน การเขียนโปรแกรมแบบฟังก์ชันเก่งในการเพิ่มการดำเนินการใหม่ให้กับประเภทข้อมูลที่มีอยู่ ในขณะที่การเขียนโปรแกรมเชิงวัตถุทำให้การเพิ่มประเภทข้อมูลใหม่เป็นเรื่องง่าย อย่างไรก็ตาม วิธีการทั้งสองไม่สามารถจัดการกับการขยายทั้งสองอย่างได้อย่างราบรื่นโดยไม่ต้องเปลี่ยนแปลงโค้ดที่มีอยู่
Extensible Visitor pattern ที่เสนอพยายามรวมจุดแข็งของทั้งสองแนวทาง โดยจัดระเบียบเครื่องมือในรูปแบบฟังก์ชันขณะใช้เทคนิคเชิงวัตถุเพื่อให้บรรลุการขยายข้อมูล
การเปรียบเทียบกระบวนทัศน์การเขียนโปรแกรม
| แนวทาง | จุดแข็ง | ข้อจำกัด |
|---|---|---|
| Functional Programming | เพิ่มการดำเนินการใหม่ได้ง่าย | ขยายชนิดข้อมูลได้ยาก |
| Object-Oriented Programming | เพิ่มชนิดข้อมูลใหม่ได้ง่าย | เพิ่มการดำเนินการข้ามชนิดข้อมูลได้ยาก |
| Extensible Visitor Pattern | พยายามขยายทั้งสองแบบ | การใช้งานที่ซับซ้อน |
| CLOS Generic Functions | Multiple dispatch, ฟังก์ชันภายนอก | ต้องใช้ระบบนิเวศ Lisp |
คำถามจากชุมชนเกี่ยวกับงานที่มีอยู่ก่อนหน้า
นักพัฒนาตั้งคำถามว่าวิธีแก้ปัญหาปี 1998 มองข้ามเทคโนโลยีที่มีอยู่แล้วหรือไม่ Common Lisp Object System ( CLOS ) จากช่วงทศวรรษ 1980 มี generic functions และความสามารถ multiple dispatch อยู่แล้วที่แก้ไขความท้าทายด้านการขยายที่คล้ายกัน CLOS วาง generic functions ไว้นอกคำจำกัดความของคลาส ทำให้สามารถเพิ่มฟังก์ชันใหม่ได้โดยไม่ต้องแก้ไขคลาสที่มีอยู่
สมาชิกชุมชนบางคนสังเกตว่า type classes ของ Haskell ซึ่งมีอยู่ก่อนปี 1998 เสนอวิธีแก้ปัญหาอื่นสำหรับการเชื่อมโยงประเภทแบบเปิด Type classes จัดการกับความท้าทายในการขยายชุดประเภทที่งานวิจัยอธิบายไว้โดยเฉพาะ
ข้อกังวลเชิงปฏิบัติเกี่ยวกับการขยายโค้ด
ไม่ใช่ทุกคนที่ยอมรับปรัชญาไม่แก้ไขโค้ดที่มีอยู่เลย นักวิจารณ์โต้แย้งว่าการเพิ่มแพตช์ใหม่อย่างต่อเนื่องโดยไม่เคย refactor นำไปสู่โค้ดเบสที่ซับซ้อนและดูแลรักษายากมากขึ้น
หากคุณยืนยันที่จะทำทุกอย่างโดยไม่แก้ไขโค้ดที่มีอยู่ สิ่งที่คุณกำลังทำคือการโยนแพตช์โคลนใหม่ลงบนลูกโคลนที่กำลังเติบโต และลูกโคลนนั้นไม่เหมือนกับสิ่งที่คุณจะพัฒนาหากคุณต้องนำความต้องการปัจจุบันทั้งหมดมาใช้ในกระดานเปล่า
มุมมองนี้แนะนำว่าบางครั้งการแก้ไขและปรับปรุงโค้ดที่มีอยู่ให้ผลลัพธ์ที่ดีกว่าการหาทางแก้ไขข้อจำกัดผ่าน design patterns ที่ซับซ้อน
วิวัฒนาการของภาษาสมัยใหม่
การอภิปรายเน้นให้เห็นว่าภาษาโปรแกรมมิ่งได้พัฒนาไปอย่างไรตั้งแต่ปี 1998 Java มีอยู่แล้วแต่ยังขาด generics Scala ยังไม่ถูกสร้างขึ้น และฟีเจอร์ภาษาสมัยใหม่หลายอย่างที่แก้ไขปัญหาการขยายยังอยู่ระหว่างการพัฒนา ภาษาในปัจจุบันเสนอวิธีแก้ปัญหาที่ซับซ้อนมากขึ้นสำหรับความท้าทายในการออกแบบพื้นฐานเหล่านี้ ทำให้วิธีการในอดีตบางอย่างมีความเกี่ยวข้องน้อยลง
การถกเถียงที่ยังคงดำเนินอยู่แสดงให้เห็นว่าคำถามหลักในการออกแบบภาษาโปรแกรมมิ่งยังคงเป็นพื้นที่ที่มีการวิจัยและอภิปรายอย่างต่อเนื่อง แม้จะผ่านไปหลายทศวรรษหลังจากข้อเสนอเริ่มแรก
อ้างอิง: Synthesizing Object-Oriented and Functional Design to Promote Re-Use