ทำไม Java มีวิธีการ 'โมฆะ'?

Java / ทำไมต้องมีvoidวิธีการ? เอกสารอ้างอิง :

วิธีการใด ๆ ที่ประกาศเป็นโมฆะจะไม่ส่งคืนค่า

เท่าที่ผมสามารถคิดว่าการใช้งานของทุกคนจะได้รับการบริการที่ดีขึ้นโดยการกลับธงสถานะวัตถุที่ถูกเรียกหรือvoidnull

สิ่งนี้จะทำให้การเรียกใช้คำสั่งที่กำหนดได้และจะช่วยให้รูปแบบการสร้างและวิธีการผูกมัด วิธีการที่ถูกเรียกใช้เฉพาะกับเอฟเฟกต์ของพวกเขามักจะส่งคืนบูลีนหรือSuccessประเภททั่วไปหรือส่งข้อยกเว้นเมื่อล้มเหลว

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

1. เนื่องจาก C มีvoidชนิดและ Java ได้รับการออกแบบให้ปฏิบัติตามอนุสัญญาของตระกูลภาษา C
2. มีฟังก์ชั่นมากมายที่คุณไม่ต้องการคืนค่า คุณจะทำอย่างไรกับ " Successประเภททั่วไป" ต่อไป? ในความเป็นจริงค่าส่งคืนเพื่อบ่งชี้ความสำเร็จมีความสำคัญน้อยกว่าใน Java มากกว่าใน C เนื่องจาก Java มีข้อยกเว้นในการบ่งชี้ความล้มเหลวและ C ไม่ได้

เดิมเหตุผลว่าทำไมภาษาที่มีvoidชนิดเป็นเพราะเหมือนในCกรรมวิธีของภาษาไม่ต้องการที่จะไม่จำเป็นซับซ้อนไวยากรณ์ของภาษาที่มีขั้นตอนและฟังก์ชั่นของทางปาสคาลได้

นั่นคือเหตุผลดั้งเดิม

คำแนะนำของคุณ:

คืนสถานะธง

นั่นเป็นข้อห้าม เราไม่ใช้สถานะธง หากมีข้อผิดพลาดเราจะรายงานผ่านข้อยกเว้น

วัตถุที่ถูกเรียก

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

คืนค่า null

มันจะบังคับให้คุณประกาศวิธีที่จะคืนบางสิ่งบางอย่างในความเป็นจริงมันไม่ได้ส่งคืนอะไรเลยดังนั้นมันจะสร้างความสับสนให้กับคนที่กำลังมองหาอินเทอร์เฟซที่พยายามจะเข้าใจว่ามันทำอะไร ผู้คนจะสร้างคลาสที่ไร้ประโยชน์อย่างหลีกเลี่ยงไม่ได้ซึ่งหมายถึง "no return value" อย่างหลีกเลี่ยงไม่ได้ดังนั้นฟังก์ชั่นทั้งหมดที่ไม่มีสิ่งใดที่จะส่งกลับสามารถส่งคืนการอ้างอิงที่เป็นโมฆะของคลาสนั้นได้ นั่นจะเป็น clunky voidโชคดีมีวิธีแก้ปัญหานี้จะเรียกว่า และนั่นคือคำตอบสำหรับคำถามของคุณ

วิธีการบางอย่างเช่นSystem.out.printlnไม่ได้ส่งคืนสิ่งที่มีประโยชน์ แต่จะเรียกว่าหมดจดสำหรับผลข้างเคียงนี้ voidเป็นตัวบ่งชี้ที่เป็นประโยชน์สำหรับคอมไพเลอร์และสำหรับผู้อ่านของรหัสที่ไม่มีค่าที่เป็นประโยชน์จะถูกส่งกลับ

กลับมาnullแทนvoidหมายความว่าคุณจะได้รับNullPointerExceptionช่วงเวลาที่คุณใช้ค่านี้เพื่ออะไร ดังนั้นคุณแลกเปลี่ยนข้อผิดพลาดเวลารวบรวมสำหรับข้อผิดพลาดรันไทม์ซึ่งเป็นวิธีที่เลวร้ายยิ่ง นอกจากนี้คุณจะต้องกำหนดประเภทผลตอบแทนเป็นObjectซึ่งจะทำให้เข้าใจผิดและสับสน (และการผูกมัดจะยังคงไม่ทำงาน)

รหัสสถานะมักจะใช้เพื่อระบุเงื่อนไขข้อผิดพลาด แต่ Java มีข้อยกเว้นสำหรับวัตถุประสงค์นี้

การส่งคืนthisไม่สามารถทำได้จากวิธีการคงที่

การส่งคืนSuccessวัตถุทั่วไปจะไม่มีวัตถุประสงค์ที่มีประโยชน์

เหตุผลหนึ่งก็คือว่ามันสามารถทำให้เข้าใจผิดnullที่เคยกลับอะไรอื่นนอกจากการพูด ตัวอย่าง:

สิ่งที่ควรArrays.sort(a)กลับมา?

หากคุณโต้แย้งว่าaควรส่งคืนเพื่อให้การโทรสามารถถูกล่ามโซ่ (ซึ่งดูเหมือนว่าเป็นการตอบสนองของคุณที่ตัดสินจากคำถามของคุณ) ดังนั้นจะไม่ชัดเจนอีกต่อไปว่าค่าส่งคืนเป็นสำเนาของวัตถุต้นฉบับหรือวัตถุต้นฉบับเอง . ทั้งสองเป็นไปได้ และใช่คุณสามารถใส่ไว้ในเอกสารประกอบ แต่มันคลุมเครือพอสมควรที่คุณไม่ควรสร้างความคลุมเครือในตอนแรก

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

และถ้าคุณกลับอย่างอื่นที่ไร้สาระโดยสิ้นเชิง (เช่นความยาวของa) แล้วมันก็ทำให้การใช้ค่าตอบแทนที่ทำให้เกิดความสับสนจริงๆ - เพียงแค่คิดว่าวิธีการที่ทำให้เกิดความสับสนมากขึ้นก็คือการพูดint len = Arrays.sort(a)แทนint len = A.length!

การคืนค่า a booleanซึ่งเท่ากับtrueที่คุณแนะนำเสมอไม่เพียง แต่ไร้จุดหมายเท่านั้น (ค่าส่งคืนจะไม่มีข้อมูล) แต่จะทำให้เข้าใจผิด ส่วนใหญ่เวลาที่ดีที่สุดที่จะใช้ชนิดผลตอบแทนเท่านั้นที่มีข้อมูลมากที่สุดเท่าที่สามารถใช้ได้จริง - ที่ว่าทำไมใน Java คุณมีbooleanสำหรับtrue/ falseแทนที่จะส่งคืนintกับ 4 พันล้านค่าที่เป็นไป ในทำนองเดียวกันการส่งคืนbooleanค่าที่เป็นไปได้สองค่าซึ่งมีค่าที่เป็นไปได้เพียงค่าเดียวเท่านั้น ("ความสำเร็จทั่วไป") จะทำให้เข้าใจผิด

มันจะเพิ่มค่าใช้จ่ายประสิทธิภาพที่ไม่จำเป็น

หากวิธีการนี้ใช้สำหรับผลข้างเคียงเท่านั้นจะไม่มีสิ่งใดที่จะส่งคืนและประเภทการคืนจะvoidสะท้อนกลับอย่างแน่นอน ข้อผิดพลาดที่อาจเกิดขึ้นน้อยสามารถส่งสัญญาณผ่านข้อยกเว้น

สิ่งหนึ่งที่อาจจะดีขึ้นจะทำให้ประเภทที่เกิดขึ้นจริงเช่นสกาล่าของvoid Unitสิ่งนี้จะช่วยแก้ปัญหาบางอย่างเช่นการจัดการยาสามัญ

Java เป็นภาษาที่ค่อนข้างเก่า และในปี 1995 (เมื่อมันถูกสร้างขึ้น) และหลังจากนั้นไม่นานโปรแกรมเมอร์ก็กังวลอย่างมากเกี่ยวกับระยะเวลาที่กระบวนการเข้าควบคุมโปรเซสเซอร์รวมถึงการใช้หน่วยความจำ การคืนค่าเป็นโมฆะจะกำจัดวงจรนาฬิกาสองสามรอบและการใช้หน่วยความจำเล็กน้อยจากการเรียกใช้ฟังก์ชันเนื่องจากคุณไม่จำเป็นต้องใส่ค่าส่งคืนบนสแต็กและคุณจะไม่ต้องลบมันในภายหลัง

รหัสที่มีประสิทธิภาพไม่ได้ให้สิ่งที่คุณไม่เคยใช้กลับคืนมาดังนั้นการทำให้เป็นโมฆะในสิ่งที่มีค่าตอบแทนที่ไม่มีความหมายนั้นเป็นวิธีปฏิบัติที่ดีกว่าการส่งคืนค่าความสำเร็จ

ฉันได้อ่านข้อโต้แย้งที่ชี้ให้เห็นว่าตัวเลือกที่สอง (กลับthis) voidควรจะมีวิธีการแทน นี่เป็นความคิดที่ดี แต่วิธีการสร้างแบบไม่เป็นที่นิยมในขณะที่ Java ถูกสร้างขึ้น หากเป็นที่นิยมในขณะนั้นเหมือนตอนนี้นั่นอาจเป็นแนวทาง การกลับมาnullเป็นความคิดที่แย่จริงๆ ฉันหวังว่าจะnullไม่ได้เป็นภาษาเลยแม้แต่น้อย

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

อีกแง่มุม:

Java เป็นภาษาคงที่ที่มีคุณสมบัติค่อนข้างเข้มงวด ซึ่งหมายความว่ามีหลายสิ่งที่ค่อนข้างเปิดกว้างหรือมีพลวัตในภาษาอื่น (c / f Ruby, Lisp เป็นต้น) ได้รับการพิจารณาอย่างเคร่งครัด

นี่คือการตัดสินใจออกแบบทั่วไป "ทำไม" ยากที่จะตอบ (ดีเพราะนักออกแบบของภาษาคิดว่ามันจะดี!) "มีอะไรสำหรับ" สวยใส: จะช่วยให้คอมไพเลอร์ตรวจสอบจำนวนมากของข้อผิดพลาดซึ่งโดยทั่วไปเป็นคุณลักษณะที่ดีงามสำหรับภาษาใด ๆ ประการที่สองมันทำให้เปรียบเทียบได้ง่ายกับเหตุผลเกี่ยวกับภาษา ตัวอย่างเช่นมันค่อนข้างง่ายที่จะสร้างความถูกต้องอย่างเป็นทางการพิสูจน์ใน (ส่วนย่อยของ) ภาษา Java; เป็นการเปรียบเทียบซึ่งจะเป็นไปไม่ได้จริงในภาษาไดนามิกเช่น Ruby et al

ความคิดนี้แทรกซึมในภาษาตัวอย่างเช่นการประกาศบังคับใช้ข้อยกเว้นที่เป็นไปได้ที่วิธีการหนึ่งอาจใช้วิธีการแยกประเภทของinterfacevs. เทียบกับclassเพื่อหลีกเลี่ยงการถ่ายทอดทางพันธุกรรมที่คลุมเครือและอื่น ๆ สำหรับสิ่งที่มันเป็น (ภาษา OOP โลกแห่งความจำเป็นคงที่ที่มีความสำคัญและมุ่งเน้นไปที่การจัดการข้อผิดพลาดในการคอมไพล์เวลา) สิ่งเหล่านั้นจริง ๆ แล้วค่อนข้างหรูหราและทรงพลัง พวกเขาเข้ามาใกล้กับภาษาเชิงวิทยาศาสตร์ (Science'y) ซึ่งทำขึ้นโดยมีจุดประสงค์เพื่อสำรวจปัญหาเหล่านี้มากกว่าภาษาอื่น ๆ ในโลกแห่งความจริงก่อนหน้านี้ (ในเวลานั้นคุณต้องคำนึงถึง)

ดังนั้น. มีvoidประเภทที่เข้มงวดเป็นข้อความที่ชัดเจน: วิธีนี้จะไม่ส่งกลับสิ่งใดระยะเวลา มันเป็นสิ่งที่มันเป็น. การแทนที่โดยการบังคับให้ส่งคืนสิ่งที่มักจะนำไปสู่พฤติกรรมแบบไดนามิกมากขึ้น (เช่นใน Ruby ที่def ทุกคนมีค่าตอบแทนที่ชัดเจนหรือโดยปริยายเสมอ) ซึ่งจะไม่ดีสำหรับการพิสูจน์และเหตุผล; หรือการขยายขนาดใหญ่โดยใช้กลไกอื่น ๆ ที่นี่

(และ NB, ทับทิม (ตัวอย่าง) จัดการนี้แตกต่างกันและวิธีการแก้ปัญหาของมันยังคงตรงตามที่ได้รับการยอมรับว่าเป็นของ Java เพราะมีปรัชญาที่แตกต่างอย่างสิ้นเชิง. ตัวอย่างเช่นมันจะพ่น provability และสมเหตุสมผลสมบูรณ์ออกจากหน้าต่างในขณะที่การวางขนาดใหญ่มุ่งเน้นไปที่ ความสามารถในการใช้ภาษาสูงมาก)