ชุมชน Python กำลังมีการอภิปรายอย่างเข้มข้นเกี่ยวกับเมื่อไหร่ที่ควรใช้ classes และเมื่อไหร่ที่ทางเลือกที่เรียบง่ายกว่าอาจจะดีกว่า แม้ว่า classes จะเป็นฟีเจอร์ที่ทรงพลังของความสามารถการเขียนโปรแกรมเชิงวัตถุของ Python แต่นักพัฒนาหลายคนโต้แย้งว่ามักจะถูกใช้มากเกินไป โดยเฉพาะอย่างยิ่งโดยโปรแกรมเมอร์ที่มาจากภาษาอื่นๆ เช่น Java
 |
|---|
| ภาพนี้เน้นภาษาโปรแกรม Python ซึ่งมักถูกพูดถึงในบริบทของการใช้ classes เทียบกับทางเลือกที่ง่ายกว่า |
ข้อโต้แย้งต่อการใช้ Classes มากเกินไป
นักพัฒนา Python ที่มีประสบการณ์หลายคนแสดงความหงุดหงิดต่อการใช้ class อย่างไม่จำเป็น ความรู้สึกนี้แรงกล้าเป็นพิเศษในหมู่ผู้ที่เคยเห็น classes ถูกใช้ผิดๆ ในโปรเจกต์โอเพนซอร์ส นักพัฒนาคนหนึ่งระบุว่าพวกเขารู้สึกหดหู่ทันทีเมื่อเห็นคำสำคัญ class เนื่องจากได้เห็นกรณีที่โซลูชันที่เรียบง่ายกว่าจะทำงานได้ดีกว่ามากเกินไป
ข้อโต้แย้งหลักมุ่งเน้นไปที่ปรัชญาของ Python ที่เน้นความเรียบง่าย เมื่องานเกี่ยวข้องกับการกระทำเดียวหรือการดำเนินการที่ไม่มีสถานะ การห่อหุ้มด้วย class มักจะเพิ่มความซับซ้อนที่ไม่จำเป็น ฟังก์ชันซึ่งเป็นพลเมืองชั้นหนึ่งใน Python มักจะให้โซลูชันที่สะอาดกว่า
โครงสร้างข้อมูล: Classes เทียบกับทางเลือกที่มีอยู่แล้ว
การถกเถียงกลายเป็นเรื่องน่าสนใจเป็นพิเศษเมื่อพูดถึงคอนเทนเนอร์ข้อมูล แม้ว่า classes แบบดั้งเดิมจะทำงานได้สำหรับการเก็บข้อมูล แต่ Python มีทางเลือกอื่นหลายตัวที่สร้างโค้ดเทมเพลตน้อยกว่า Named tuples และ dataclasses จะสร้างเมธอดที่มีประโยชน์เช่นการแสดงสตริงและการดำเนินการเปรียบเทียบโดยอัตโนมัติโดยไม่ต้องใช้การใช้งานด้วยตนเอง
อย่างไรก็ตาม ชุมชนแบ่งออกเป็นสองฝ่ายในแนวทางนี้ นักพัฒนาบางคนโต้แย้งว่าการใช้โครงสร้างข้อมูลแบบง่ายๆ เช่น dictionaries สร้างการเขียนโปรแกรมแบบไม่มีสคีมาที่กลายเป็นหนี้ทางเทคนิคเมื่อโปรเจกต์เติบโต พวกเขาชอบโครงสร้างที่ชัดเจนที่ classes ให้ แม้แต่สำหรับคอนเทนเนอร์ข้อมูลแบบง่าย
มันใช้ได้ดีสำหรับสคริปต์เล็กๆ ที่ใช้ครั้งเดียว แต่เมื่อความซับซ้อนของซอฟต์แวร์เติบโต สคีมาที่ไม่ชัดเจน (และมักจะไม่มีเอกสารเลย) จะกลายเป็นหนี้ทางเทคนิค
การเปรียบเทียบทางเลือกของ Class
| กรณีการใช้งาน | Traditional Class | ทางเลือกที่แนะนำ | ประโยชน์ |
|---|---|---|---|
| การเก็บข้อมูลแบบง่าย | เมธอด __init__ แบบกำหนดเอง |
namedtuple หรือ @dataclass |
สร้างเมธอดอัตโนมัติ โค้ดซ้ำซากน้อยลง |
| การดำเนินการแบบไม่มีสถานะ | Class ที่มี @staticmethod |
ฟังก์ชันธรรมดา | เรียบง่าย เป็น Pythonic มากกว่า |
| การจัดกลุ่มค่าคงที่ | Class ที่มี class variables | ค่าคงที่ระดับโมดูล | ใช้ประโยชน์จากระบบโมดูลของ Python |
| การจัดการสถานะแบบง่าย | Class ที่มี instance variables | dict หรือ list ในตัว |
ตรงไปตรงมา ไม่มีการแยกชั้นที่ไม่จำเป็น |
ข้อโต้แย้งเรื่อง Typing และเอกสาร
ส่วนสำคัญของการอภิปรายมุ่งเน้นไปที่ type hints และเอกสารโค้ด นักพัฒนาที่ทำงานในโปรเจกต์ขนาดใหญ่มักจะชอบ classes เพราะมันให้ข้อมูลประเภทที่ชัดเจนและทำหน้าที่เป็นเอกสารที่มีชีวิต แนวทางที่ใช้ Dictionary แม้ว่าจะเรียบง่ายกว่าในตอนแรก แต่อาจจะกลายเป็นเรื่องยากที่จะดูแลรักษาเมื่อโค้ดเบสขยายตัว
สิ่งนี้นำไปสู่การประนีประนอมที่น่าสนใจ นักพัฒนาบางคนเริ่มต้นด้วยโครงสร้างแบบง่ายระหว่างการสร้างต้นแบบ จากนั้นจึงทำให้มันแข็งแกร่งขึ้นเป็น classes เมื่อสคีมาชัดเจนขึ้น คนอื่นๆ ใช้เครื่องมือเช่น Pydantic ซึ่งให้การตรวจสอบและความปลอดภัยของประเภทในขณะที่ยังคงความเรียบง่ายที่ dataclasses นำเสนอ
เมื่อไหร่ที่ Classes สมเหตุสมผลจริงๆ
แม้จะมีการวิพากษ์วิจารณ์ แต่ชุมชนยอมรับว่า classes มีที่ยืนของมัน มันมีค่าเป็นพิเศษสำหรับโครงสร้างข้อมูลที่ซับซ้อนเช่น Pandas DataFrames ที่การรวมกันของข้อมูลและพฤติกรรมสนับสนุนแนวทางเชิงวัตถุ การพัฒนาเกมเป็นอีกพื้นที่หนึ่งที่ classes สร้างแบบจำลองเอนทิตีที่มีทั้งสถานะและพฤติกรรมได้อย่างเป็นธรรมชาติ
ข้อมูลเชิงลึกสำคัญจากการอภิปรายคือความยืดหยุ่นของ Python ช่วยให้นักพัฒนาเลือกเครื่องมือที่เหมาะสมสำหรับแต่ละสถานการณ์ แทนที่จะใช้ classes เป็นค่าเริ่มต้นเพราะมันมีอยู่ ชุมชนสนับสนุนให้คิดว่าทางเลือกที่เรียบง่ายกว่าอาจจะเหมาะสมกว่าหรือไม่
เมื่อไหร่ควรใช้ Classes เทียบกับทางเลือกอื่น
ใช้ Classes เมื่อ:
- ต้องการรวม state และ behavior เข้าด้วยกัน
- Objects มี methods ที่ชัดเจนซึ่งเกี่ยวข้องกับข้อมูลของตัวเอง
- ต้องการสร้างแบบจำลองโครงสร้างที่ซับซ้อนและเป็นลำดับชั้น
- ต้องการ inheritance และ composition
- ทำงานกับระบบขนาดใหญ่และซับซ้อนที่ต้องการ schemas ที่ชัดเจน
ใช้ทางเลือกอื่นเมื่อ:
- เก็บข้อมูลง่ายๆ โดยไม่มี behavior ที่ซับซ้อน
- ดำเนินการ utility operations แบบ stateless
- จัดกลุ่ม constants ที่เกี่ยวข้องกัน
- จัดการ state แบบง่ายๆ ที่เปลี่ยนแปลงได้
- ทำ prototype หรือเขียน scripts เล็กๆ
บทสรุป
การถกเถียงสะท้อนปรัชญาที่กว้างขึ้นของ Python ที่มีหลายวิธีในการแก้ปัญหาในขณะที่สนับสนุนให้นักพัฒนาเลือกแนวทางที่อ่านได้และดูแลรักษาได้มากที่สุด แม้ว่า classes จะยังคงสำคัญสำหรับสถานการณ์ที่ซับซ้อน แต่ชุมชนให้ความสำคัญกับความเรียบง่ายและทางเลือกที่มีอยู่แล้วสำหรับงานที่ตรงไปตรงมามากขึ้น การอภิปรายทำหน้าที่เป็นการเตือนใจว่าโค้ด Python ที่ดีมักจะหมายถึงการรู้ว่าเมื่อไหร่ไม่ควรใช้ฟีเจอร์บางอย่าง แม้ว่าจะมีให้ใช้ก็ตาม
หมายเหตุ: Dataclasses ในทางเทคนิคยังคงเป็น classes แต่ใช้ decorators เพื่อสร้างเมธอดทั่วไปโดยอัตโนมัติ ลดโค้ดเทมเพลต
อ้างอิง: You might not need a Python class