คำถามติดแท็ก design-by-contract

9
เหตุใดจึงมีการสนับสนุนที่ จำกัด สำหรับ Design by Contract ในภาษาการเขียนโปรแกรมที่ทันสมัยที่สุด?
ฉันเพิ่งค้นพบการออกแบบตามสัญญา (DbC) และฉันพบว่ามันเป็นวิธีที่น่าสนใจอย่างยิ่งในการเขียนโค้ด เหนือสิ่งอื่นใดดูเหมือนว่าจะนำเสนอ: เอกสารที่ดีกว่า เนื่องจากสัญญาเป็นเอกสารจึงเป็นไปไม่ได้ที่จะล้าสมัย นอกจากนี้เนื่องจากสัญญาระบุว่าสิ่งที่รูทีนทำจะช่วยสนับสนุนการใช้ซ้ำได้ การดีบักง่ายขึ้น เนื่องจากการทำงานของโปรแกรมหยุดทันทีที่สัญญาล้มเหลวข้อผิดพลาดจึงไม่สามารถเผยแพร่ได้และการละเมิดการยืนยันที่เฉพาะเจาะจงน่าจะถูกเน้น สิ่งนี้ให้การสนับสนุนในระหว่างการพัฒนาและในระหว่างการบำรุงรักษา การวิเคราะห์เชิงสถิตที่ดีขึ้น DbC นั้นเป็นเพียงการนำตรรกะของ Hoare มาใช้และควรใช้หลักการเดียวกันนี้ ค่าใช้จ่ายในการเปรียบเทียบดูเหมือนจะค่อนข้างเล็ก: พิมพ์ลายนิ้วมือพิเศษ เนื่องจากสัญญาต้องถูกสะกดออกมา ใช้เวลาฝึกอบรมจำนวนหนึ่งเพื่อให้คุ้นเคยกับสัญญาการเขียน ตอนนี้การทำความคุ้นเคยกับ Python เป็นหลักฉันตระหนักว่าในความเป็นจริงเป็นไปได้ที่จะเขียนเงื่อนไขเบื้องต้น (เพียงแค่โยนข้อยกเว้นสำหรับอินพุตที่ไม่เหมาะสม) และเป็นไปได้ที่จะใช้การยืนยันเพื่อทดสอบ postconditions อีกครั้ง แต่มันเป็นไปไม่ได้ที่จะจำลองคุณสมบัติบางอย่างเช่น 'เก่า' หรือ 'ผลลัพธ์' โดยไม่ต้องใช้เวทมนตร์พิเศษที่ในที่สุดจะได้รับการพิจารณาว่าไม่เป็น Pythonic (นอกจากนี้ยังมีห้องสมุดเพียงไม่กี่แห่งที่ให้การสนับสนุน แต่ท้ายที่สุดฉันได้รับความรู้สึกว่ามันผิดที่จะใช้พวกเขาเนื่องจากนักพัฒนาส่วนใหญ่ทำไม่ได้) ฉันคิดว่ามันเป็นปัญหาที่คล้ายกันสำหรับภาษาอื่น ๆ ทั้งหมด (ยกเว้นแน่นอน ไอเฟล) สัญชาตญาณของฉันบอกฉันว่าการขาดการสนับสนุนต้องเป็นผลมาจากการปฏิเสธการฝึกฝน แต่การค้นหาทางออนไลน์นั้นไม่ประสบผลสำเร็จ ฉันสงสัยว่าบางคนสามารถอธิบายได้ว่าทำไมภาษาสมัยใหม่ส่วนใหญ่จึงให้การสนับสนุนเพียงเล็กน้อย DbC มีข้อบกพร่องหรือมีราคาแพงเกินไป? หรือเป็นเพียงล้าสมัยเนื่องจาก Extreme Programming และวิธีการอื่น ๆ ?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.