คำถามติดแท็ก duck-typing

4
Python ให้อภัยเทียบกับการอนุญาตและการพิมพ์ดีดเป็ด
ใน Python ฉันมักจะได้ยินว่าเป็นการ "ให้อภัย" ดีกว่า (ยกเว้นการจับ) แทนที่จะดีกว่า "ขออนุญาต" (การตรวจสอบประเภท / เงื่อนไข) ในเรื่องที่เกี่ยวกับการบังคับใช้การพิมพ์เป็ดใน Python มันคือสิ่งนี้ try: x = foo.bar except AttributeError: pass else: do(x) ดีกว่าหรือแย่กว่า if hasattr(foo, "bar"): do(foo.bar) else: pass ในแง่ของประสิทธิภาพการอ่าน "pythonic" หรือปัจจัยสำคัญอื่น ๆ

11
ทำไม PHP ถึงมีอินเตอร์เฟส?
ฉันสังเกตเห็นว่าใน PHP5 มีการเพิ่มส่วนต่อประสานกับภาษา อย่างไรก็ตามเนื่องจาก PHP ถูกพิมพ์อย่างหลวม ๆ ดูเหมือนว่าประโยชน์ส่วนใหญ่ของการใช้ส่วนต่อประสานจะหายไป ทำไมสิ่งนี้จึงรวมอยู่ในภาษา

4
เหตุใดภาษาการเขียนโปรแกรมแบบไดนามิกที่ใช้เป็ดจำนวนมากจึงใช้วิธีการแบบคลาสแทน OOP ต้นแบบ
เนื่องจากภาษาการเขียนโปรแกรมแบบไดนามิกค่อนข้างมากมีคุณสมบัติในการพิมพ์เป็ดและพวกเขายังสามารถเปิดและแก้ไขวิธีการเรียนหรืออินสแตนซ์ได้ตลอดเวลา (เช่นRubyและPython ) ดังนั้น ... คำถามที่ 1) ความต้องการห้องเรียนในภาษาแบบไดนามิกคืออะไร ทำไมภาษาจึงออกแบบวิธีการใช้คลาสเป็น“ เทมเพลต” บางชนิดแทนที่จะเป็นแบบต้นแบบและใช้แค่วัตถุ? จาวาสคริปต์ยังเป็นรุ่นต้นแบบ แต่CoffeeScript (เวอร์ชันปรับปรุงของจาวาสคริปต์) จะเลือกวิธีที่อิงกับคลาส และมันก็เหมือนกันสำหรับLua (รุ่นต้นแบบ) และMoonScript (ตามคลาส) นอกจากนี้ยังมีคลาสใน ES 6 ดังนั้น ... คำถามที่ 2) มีการแนะนำหรือไม่ว่าถ้าคุณพยายามปรับปรุงภาษาที่ใช้ต้นแบบเป็นต้นคุณควรเปลี่ยนเป็นแบบเรียนหรือไม่ ถ้าไม่ทำไมมันถูกออกแบบมาอย่างนั้น?

6
เป็นเป็ดพิมพ์ส่วนย่อยของความแตกต่าง
จากความหลากหลายในวิกิพีเดีย ในวิทยาการคอมพิวเตอร์ polymorphism เป็นคุณสมบัติภาษาการเขียนโปรแกรมที่ช่วยให้ค่าของชนิดข้อมูลที่แตกต่างกันได้รับการจัดการโดยใช้อินเตอร์เฟซที่เหมือนกัน จากการพิมพ์เป็ดบน Wikipedia ในการเขียนโปรแกรมคอมพิวเตอร์ด้วยภาษาการเขียนโปรแกรมเชิงวัตถุการพิมพ์เป็ดเป็นลักษณะของการพิมพ์แบบไดนามิกซึ่งชุดวิธีการและคุณสมบัติปัจจุบันของวัตถุกำหนดความหมายที่ถูกต้องมากกว่าการสืบทอดจากคลาสเฉพาะหรือการใช้อินเทอร์เฟซเฉพาะ การตีความของฉันนั้นขึ้นอยู่กับการพิมพ์เป็ดวิธีการ / คุณสมบัติของวัตถุกำหนดความหมายที่ถูกต้อง ความหมายที่วัตถุรูปร่างปัจจุบันกำหนดอินเทอร์เฟซมันรักษา จากหลากหลายคุณสามารถพูดฟังก์ชั่นเป็น polymorphic ถ้ามันยอมรับหลายชนิดข้อมูลที่แตกต่างกันตราบเท่าที่พวกเขารักษาอินเทอร์เฟซ ดังนั้นหากฟังก์ชั่นสามารถพิมพ์เป็ดมันสามารถยอมรับหลายชนิดข้อมูลที่แตกต่างกันและดำเนินการกับพวกเขาตราบเท่าที่ชนิดข้อมูลเหล่านั้นมีวิธีการที่ถูกต้อง / คุณสมบัติและทำให้การสนับสนุนอินเตอร์เฟซ (การใช้อินเทอร์เฟซของคำศัพท์ไม่ได้หมายถึงการสร้างโค้ด แต่เป็นการสร้างเอกสารที่มีความหมายและมีความหมายมากกว่า) ความสัมพันธ์ที่ถูกต้องระหว่าง ducktyping และ polymorphism คืออะไร? หากภาษาหนึ่งสามารถเป็ดชนิดนั่นหมายความว่ามันสามารถทำ polymorphism?

3
คุณจะใช้การพิมพ์เป็ดในจาวาสคริปต์โดยไม่ตรวจสอบคุณสมบัติและวิธีการได้อย่างไร
ฉันรู้ว่าจาวาสคริปต์ใช้การพิมพ์เป็ดและตอนแรกฉันคิดว่านี่จะทำให้ความแตกต่างง่ายเมื่อเทียบกับภาษาที่พิมพ์อย่างยิ่งเช่น C # แต่ตอนนี้ฟังก์ชั่นของฉันที่รับการโต้แย้งจะเกลื่อนไปด้วยสิ่งต่าง ๆ เช่น: if(myObj.hasSomeProperty()) หรือ if(myObj.hasSomeMethod()) หรือ if(isNumber(myParam)) เป็นต้น นี่มันน่าเกลียดสำหรับฉันจริงๆ ฉันมาจากพื้นหลัง C # และฉันพบว่าอินเตอร์เฟสที่กำหนดไว้นั้นดีกว่ามาก ฉันสงสัยว่าฉันพยายามใช้กลยุทธ์ที่มีประสิทธิภาพในภาษาที่พิมพ์แบบคงที่หรือไม่และมีวิธีที่ดีกว่าในการทำเช่นนี้ใน javascript หรือไม่ ฉันรู้ว่าฉันไม่สามารถตรวจสอบได้ แต่การติดตามข้อผิดพลาดรันไทม์ของจาวาสคริปต์อาจเป็นฝันร้ายเพราะพวกเขามักจะไม่เกิดขึ้นเมื่อเกิดข้อผิดพลาดในรหัส

1
การพิมพ์เป็ดการตรวจสอบข้อมูลและการเขียนโปรแกรมที่เหมาะสมใน Python
เกี่ยวกับการพิมพ์เป็ด : การพิมพ์เป็ดนั้นได้รับความช่วยเหลือจากการไม่ได้ทดสอบประเภทของข้อโต้แย้งในวิธีการและร่างกายโดยอาศัยเอกสารประกอบรหัสที่ชัดเจนและการทดสอบเพื่อให้แน่ใจว่าการใช้งานถูกต้อง เกี่ยวกับการตรวจสอบข้อโต้แย้ง (EAFP: ง่ายกว่าที่จะขอการอภัยมากกว่าการอนุญาต) ตัวอย่างที่ดัดแปลงจากที่นี่ : ... มันเป็นสิ่งที่ต้องทำยิ่งกว่า: def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else ซึ่งหมายความว่าทุกคนที่ใช้รหัสของคุณไม่จำเป็นต้องใช้พจนานุกรมจริงหรือคลาสย่อย - พวกเขาสามารถใช้วัตถุใด ๆ ที่ใช้อินเทอร์เฟซการแมป น่าเสียดายในทางปฏิบัติมันไม่ง่ายอย่างนั้น ถ้าสมาชิกในตัวอย่างด้านบนอาจเป็นจำนวนเต็ม จำนวนเต็มไม่เปลี่ยนรูปดังนั้นจึงเหมาะสมอย่างยิ่งที่จะใช้เป็นคีย์พจนานุกรม อย่างไรก็ตามพวกมันยังใช้เพื่อจัดทำดัชนีวัตถุประเภทลำดับ หากสมาชิกเกิดขึ้นเป็นจำนวนเต็มตัวอย่างที่สองสามารถผ่านรายการและสตริงเช่นเดียวกับพจนานุกรม เกี่ยวกับการเขียนโปรแกรมที่แน่วแน่ : การยืนยันเป็นวิธีที่เป็นระบบในการตรวจสอบว่าสถานะภายในของโปรแกรมเป็นไปตามที่โปรแกรมเมอร์คาดไว้โดยมีเป้าหมายในการจับข้อบกพร่อง โดยเฉพาะอย่างยิ่งพวกเขาดีสำหรับการจับสมมติฐานที่ผิดพลาดที่เกิดขึ้นในขณะที่เขียนรหัสหรือใช้อินเทอร์เฟซโดยโปรแกรมเมอร์อื่น นอกจากนี้พวกเขาสามารถทำหน้าที่เป็นเอกสารในบรรทัดบางส่วนโดยทำให้สมมติฐานของโปรแกรมเมอร์ชัดเจน ("ชัดเจนดีกว่าโดยนัย") แนวคิดที่กล่าวถึงบางครั้งมีข้อขัดแย้งดังนั้นฉันจึงพิจารณาปัจจัยต่อไปนี้เมื่อเลือกว่าฉันไม่ได้ทำการตรวจสอบความถูกต้องของข้อมูลเลยให้ทำการตรวจสอบความถูกต้องอย่างแรงหรือใช้การยืนยัน: การตรวจสอบที่แข็งแกร่ง โดยการตรวจสอบที่แข็งแกร่งฉันหมายถึงการเพิ่มข้อยกเว้นที่กำหนดเอง ( ApiErrorตัวอย่าง) หากฟังก์ชัน / เมธอดของฉันเป็นส่วนหนึ่งของ API สาธารณะจะเป็นการดีกว่าถ้าตรวจสอบอาร์กิวเมนต์เพื่อแสดงข้อความแสดงข้อผิดพลาดที่ดีเกี่ยวกับประเภทที่ไม่คาดคิด โดยการตรวจสอบประเภทที่ฉันไม่ได้หมายถึงการใช้เพียงอย่างเดียวisinstanceแต่ยังถ้าวัตถุผ่านการสนับสนุนอินเทอร์เฟซที่จำเป็น …

1
นัยกับอินเทอร์เฟซชัดเจน
ฉันคิดว่าฉันเข้าใจข้อ จำกัด ที่แท้จริงของการรวบรวมความแตกต่างของเวลาและความหลากหลายของเวลาทำงาน แต่อะไรคือความแตกต่างทางแนวคิดระหว่างอินเตอร์เฟสที่ชัดเจน (polymorphism แบบรันไทม์คือฟังก์ชันเสมือนและพอยน์เตอร์ / การอ้างอิง) และอินเทอร์เฟซโดยปริยาย (polymorphism เวลาคอมไพล์เช่น . ความคิดของฉันคือวัตถุสองชิ้นที่มีส่วนต่อประสานที่ชัดเจนเหมือนกันจะต้องเป็นวัตถุประเภทเดียวกัน (หรือมีบรรพบุรุษร่วมกัน) ในขณะที่วัตถุสองชิ้นที่มีส่วนต่อประสานแบบเดียวกันนั้นไม่จำเป็นต้องเป็นวัตถุชนิดเดียวกัน อินเทอร์เฟซที่พวกเขาทั้งสองเสนอสามารถมีฟังก์ชันการทำงานที่แตกต่างกันมาก ความคิดใด ๆ เกี่ยวกับเรื่องนี้? และหากวัตถุสองชิ้นมีอินเตอร์เฟสแบบนัยเดียวกันเหตุผลอะไร (ข้างๆประโยชน์ทางเทคนิคของการไม่ต้องใช้การส่งข้อมูลแบบไดนามิกที่มีตารางการค้นหาฟังก์ชั่นเสมือน ฯลฯ ) จะไม่มีวัตถุเหล่านี้สืบทอดมาจากวัตถุพื้นฐานที่ประกาศอินเตอร์เฟสนั้น ทำให้เป็นอินเทอร์เฟซที่ชัดเจนหรือไม่ อีกวิธีในการบอกว่า: คุณสามารถให้กรณีที่วัตถุสองอย่างที่เสนออินเทอร์เฟซแบบเดียวกัน (และสามารถใช้เป็นชนิดของคลาสเทมเพลตตัวอย่าง) ไม่ควรสืบทอดมาจากคลาสพื้นฐานที่ทำให้อินเทอร์เฟซนั้นชัดเจน? บางโพสต์ที่เกี่ยวข้อง: https://stackoverflow.com/a/7264550/635125 https://stackoverflow.com/a/7264689/635125 https://stackoverflow.com/a/8009872/635125 นี่คือตัวอย่างที่จะทำให้คำถามนี้เป็นรูปธรรมมากขึ้น: การเชื่อมต่อโดยนัย: class Class1 { public: void interfaceFunc(); void otherFunc1(); }; class Class2 { public: void interfaceFunc(); …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.