ชุมชนโปรแกรมเมอร์ถกเถียงความผิดพลาดของ Object-Oriented Programming ที่ยาวนาน 35 ปี หลังจากการวิเคราะห์ประวัติศาสตร์ของ Casey Muratori

ทีมชุมชน BigGo
ชุมชนโปรแกรมเมอร์ถกเถียงความผิดพลาดของ Object-Oriented Programming ที่ยาวนาน 35 ปี หลังจากการวิเคราะห์ประวัติศาสตร์ของ Casey Muratori

การนำเสนอของ Casey Muratori เรื่อง The Big OOPs: Anatomy of a Thirty-Five Year Mistake ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนโปรแกรมเมอร์เกี่ยวกับสมมติฐานพื้นฐานที่อยู่เบื้องหลัง object-oriented programming (OOP) การบรรยายที่ยาวเกือบสองชั่วโมงนี้ได้ติดตามการพัฒนาทางประวัติศาสตร์ของ OOP ตั้งแต่ปี 1963 ถึง 1998 โดยโต้แย้งว่าแนวทางเฉพาะในการจัดระเบียบโค้ดได้สร้างความซับซ้อนที่ไม่จำเป็นในการพัฒนาซอฟต์แวร์มาเป็นเวลาหลายทศวรรษ

ข้อโต้แย้งหลัก: Domain Model Hierarchies เป็นความผิดพลาด

วิทยานิพนธ์หลักของ Muratori มุ่งเน้นไปที่สิ่งที่เขาเรียกว่า compile-time hierarchy of encapsulation that matches the domain model ซึ่งหมายถึงการปฏิบัติทั่วไปในการจัดระเบียบคลาสโค้ดให้สะท้อนความสัมพันธ์ในโลกแห่งความเป็นจริง เช่น การมีคลาส Car สืบทอดจากคลาส Vehicle ซึ่งสืบทอดจากคลาส Transportation การอย่างชุมชนเผยให้เห็นว่านักพัฒนาหลายคนได้รับการสอนแนวทางนี้ว่าเป็นวิธีที่ถูกต้องในการทำ OOP โดยการสืบทอดแสดงถึงความสัมพันธ์เชิงความหมาย is-a จากโดเมนปัญหา

การบรรยายได้ติดตามแนวทางนี้ย้อนกลับไปยัง Simula ซึ่งมันมีเหตุผลเพราะภาษานี้ถูกออกแบบมาสำหรับการจำลอง อย่างไรก็ตาม เมื่อแนวคิดเหล่านี้ย้ายไปยัง C++ และต่อมา Java พวกมันกลายเป็นการปฏิบัติสากลที่ใช้กับปัญหาซอฟต์แวร์ทั้งหมด โดยไม่คำนึงว่าการสร้างแบบจำลองโดเมนจะเหมาะสมหรือไม่

ไทม์ไลน์ประวัติศาสตร์ของการพัฒนา OOP:

  • 1963: แนวคิด ECS เริ่มต้นปรากฏใน Sketchpad
  • 1967: Simula 67 แนะนำคลาสและฟังก์ชันเสมือน
  • 1980s-1990s: C++ ทำให้ลำดับชั้นของโมเดลโดเมนเป็นที่นิยม
  • 1998: Thief: The Dark Project แสดงให้เห็นสถาปัตยกรรม ECS สมัยใหม่
  • ปัจจุบัน: เกมเอนจินอย่าง Unity และ Unreal นำรูปแบบ ECS มาใช้

Entity Component Systems: ทางเลือกที่สูญหายไป

ส่วนสำคัญของการอภิปรายชุมชนมุ่งเน้นไปที่ Entity Component Systems (ECS) ซึ่ง Muratori นำเสนอเป็นทางเลือกที่มีอยู่ตั้งแต่ปี 1963 แต่ถูกลืมไปส่วนใหญ่ ECS จัดระเบียบโค้ดรอบความสามารถในการคำนวณมากกว่าลำดับชั้นโดเมน แทนที่จะมีการสืบทอดคลาสที่แข็งแกร่ง entities จะประกอบด้วยคอมโพเนนต์ที่สามารถเพิ่มหรือลบได้แบบไดนามิก โดยมีระบบที่ทำงานกับ entities ที่มีการรวมกันของคอมโพเนนต์เฉพาะ

นักพัฒนาเกมในการอภิปรายสังเกตว่า ECS ได้รับความนิยมมากขึ้นในสาขาของพวกเขา โดยเอนจิ้นหลักอย่าง Unity และ Unreal Engine ได้นำรูปแบบเหล่านี้มาใช้ แนวทางนี้ช่วยให้มีโค้ดที่ยืดหยุ่นและบำรุงรักษาได้มากขึ้น โดยเฉพาะในระบบที่ซับซ้อนซึ่งอ็อบเจ็กต์ต้องแสดงพฤติกรรมหลายอย่างที่ไม่เข้ากับหมวดหมู่ลำดับชั้นอย่างเรียบร้อย

การเปรียบเทียบกระบวนทัศน์การเขียนโปรแกรมหลัก:

แนวทาง การจัดระเบียบ ความยืดหยุ่น กรณีการใช้งาน
OOP แบบดั้งเดิม ลำดับชั้นโดเมน (Car → Vehicle) ต่ำ - การสืบทอดแบบเข้มงวด แอปพลิเคชันธุรกิจ, ซอฟต์แวร์ยุคแรก
Entity Component Systems ความสามารถเชิงคำนวณ สูง - การประกอบแบบไดนามิก เกม, การจำลอง, ระบบที่ซับซ้อน
Functional Programming ฟังก์ชันทางคณิตศาสตร์ สูง - ฟังก์ชันที่ประกอบได้ การประมวลผลข้อมูล, ระบบพร้อมกัน
Procedural Programming การดำเนินการตามลำดับ ปานกลาง - ฟังก์ชันแบบโมดูลาร์ การเขียนโปรแกรมระบบ, ยูทิลิตี้

ชุมชนแบ่งแยกเกี่ยวกับคุณค่าของ OOP

ชุมชนโปรแกรมเมอร์ดูเหมือนจะแบ่งแยกเกี่ยวกับว่า OOP เองเป็นปัญหาหรือเพียงแค่การใช้งานเฉพาะของมัน นักพัฒนาบางคนแบ่งปันประสบการณ์การถูกวิพากษ์วิจารณ์สำหรับการตั้งคำถามกับความเป็นมาตรฐานของ OOP ในช่วงอาชีพของพวกเขา โดยอธิบายสถานการณ์ที่พวกเขาถูกมองว่ามีทักษะน้อยกว่าสำหรับการชอบแนวทางเชิงฟังก์ชันหรือเชิงขั้นตอน

ผมบ่นเกี่ยวกับ OOP มากตลอด 25 ปีในฐานะนักพัฒนา... เมื่อผมเริ่มบ่นกับเพื่อนร่วมงานเกี่ยวกับความรู้สึกของผม ผมถูกแยกออกและถูกกล่าวหาว่า 'ไม่มีทักษะที่แข็งแกร่งพอ'

อย่างไรก็ตาม คนอื่นๆ โต้แย้งว่าปัญหาไม่ใช่ OOP ในฐานะกระบวนทัศน์ แต่เป็นวิธีการสอนและใช้งาน พวกเขาชี้ให้เห็นว่าภาษาอย่าง Python และแม้แต่ C++ อนุญาตให้ใช้สไตล์การเขียนโปรแกรมหลายแบบ และ polymorphism และ encapsulation ยังคงเป็นเครื่องมือที่มีค่าเมื่อใช้อย่างเหมาะสม

การถกเถียงทางเทคนิคเกี่ยวกับการใช้งานภาษา

เรื่องรองที่น่าสนใจในการอภิปรายชุมชนเกี่ยวข้องกับการถกเถียงเกี่ยวกับสิ่งที่ถือเป็น object-oriented programming ในระดับภาษา บางคนโต้แย้งว่าภาษาอย่าง Python เป็น object-oriented โดยธรรมชาติเพราะทุกอย่างถูกใช้งานเป็นอ็อบเจ็กต์ภายใน ในขณะที่คนอื่นๆ ยืนยันว่ารายละเอียดการใช้งานสำคัญน้อยกว่ารูปแบบการเขียนโปรแกรมที่นักพัฒนาใช้

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

บทสรุป

การวิเคราะห์ประวัติศาสตร์ของ Muratori ได้กระตุ้นประสาทในชุมชนโปรแกรมเมอร์อย่างชัดเจน โดยยืนยันประสบการณ์ที่นักพัฒนาหลายคนมีกับลำดับชั้น OOP ที่ซับซ้อนเกินไป ขณะเดียวกันก็กระตุ้นให้มีการไตร่ตรองเกี่ยวกับทางเลือกที่ดีกว่า การอภิปรายชี้ให้เห็นว่าแม้เครื่องมือ OOP อย่าง polymorphism และ encapsulation ยังคงมีค่า แต่อุตสาหกรรมอาจกำลังเคลื่อนไปจากแนวทางการสร้างแบบจำลองโดเมนที่แข็งแกร่งไปสู่รูปแบบสถาปัตยกรรมที่ยืดหยุ่นมากขึ้นอย่าง ECS และเทคนิคการเขียนโปรแกรมเชิงฟังก์ชัน

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

อ้างอิง: The Big OOPs: Anatomy of a Thirty-Five Year Mistake