ฉันควรตรวจสอบค่าส่งคืนของการเรียกใช้เมธอดแม้ว่าฉันจะรู้ว่าวิธีนั้นไม่สามารถส่งคืนอินพุตที่ไม่ดีได้หรือไม่?

ฉันสงสัยว่าฉันควรป้องกันค่าตอบแทนการโทรด้วยวิธีการโดยตรวจสอบว่าพวกเขาตอบสนองความคาดหวังของฉันแม้ว่าฉันรู้ว่าวิธีการที่ฉันโทรจะตอบสนองความคาดหวังดังกล่าว

GIVEN

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

ฉันควรทำหรือไม่

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

หรือ

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

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

ข้อสรุปของฉันจากคำตอบทั้งหมด (อย่าลังเลที่จะมาหาคุณ):

• วิธีนี้แสดงให้เห็นว่ามีพฤติกรรมที่ไม่เหมาะสมในอดีต
• วิธีการมาจากแหล่งที่ไม่น่าเชื่อถือ
• วิธีการนี้ใช้จากที่อื่นและไม่ได้ระบุอย่างชัดเจนว่าเป็นเงื่อนไขภายหลัง

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

ที่ขึ้นอยู่กับวิธีการที่มีแนวโน้ม getUser และ MyMethod มีการเปลี่ยนแปลงและที่สำคัญกว่าวิธีการที่พวกเขาจะมีแนวโน้มที่จะเปลี่ยนเป็นอิสระจากกัน

หากคุณทราบอย่างแน่นอนว่า getUser จะไม่เปลี่ยนแปลงตลอดไปในอนาคตใช่ว่าจะเป็นการเสียเวลาในการตรวจสอบความถูกต้องและเสียเวลาในการตรวจสอบความถูกต้องที่iมีค่าเท่ากับ 3 ทันทีหลังจากi = 3;คำสั่ง ในความเป็นจริงคุณไม่ทราบว่า แต่มีบางสิ่งที่คุณรู้:

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

• ฟังก์ชั่น getUser เป็นส่วนหนึ่งของ API เอกสารที่มีสัญญาเฉพาะหรือไม่และ myMethod เป็นเพียงลูกค้าของ API ดังกล่าวในรหัสฐานข้อมูลอื่นหรือไม่ ถ้าเป็นเช่นนั้นคุณสามารถอ่านเอกสารนั้นเพื่อดูว่าคุณควรตรวจสอบความถูกต้องของผลตอบแทน (หรือตรวจสอบพารามิเตอร์อินพุตล่วงหน้า!) หรือถ้ามันปลอดภัยที่จะสุ่มสี่สุ่มห้าตามเส้นทางแห่งความสุข หากเอกสารไม่ชัดเจนให้สอบถามผู้ดูแลเพื่อแก้ไข

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

โปรดทราบว่าสิ่งที่กล่าวมาทั้งหมดข้างต้นมีผลแม้ว่าคุณจะเป็นผู้เขียนต้นฉบับของทั้งสองฟังก์ชัน เราไม่รู้ว่าทั้งสองฟังก์ชั่นนี้คาดว่าจะ "อยู่ด้วยกัน" ตลอดชีวิตของพวกเขาหรือไม่หรือถ้าพวกมันจะค่อยๆแยกออกเป็นส่วน ๆ แยกกันหรือถ้าคุณยิงตัวเองด้วยเท้า รุ่นของ getUser แต่คุณอาจเดาได้ดี

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

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

คำขวัญของฉันคือ:

คำถามที่คุณควรถามตัวเองอยู่เสมอไม่ใช่ "ฉันควรยืนยันเรื่องนี้หรือไม่?" แต่ "มีอะไรฉันลืมยืนยัน?"

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

แต่มีข้อยกเว้นแม้แต่กฎนี้ อยากรู้อยากเห็นพอที่จะใช้ตัวอย่างของ Ixrec มีประเภทของสถานการณ์ที่มันเป็นที่พึงปรารถนาอย่างสมบูรณ์แบบที่จะปฏิบัติตามint i = 3;ด้วยการยืนยันที่iอยู่ในช่วงที่แน่นอน นี่คือสถานการณ์ที่iมีแนวโน้มที่จะมีการเปลี่ยนแปลงโดยคนที่กำลังพยายามทำสิ่งต่าง ๆ ที่เกิดขึ้นและรหัสที่ตามมานั้นขึ้นอยู่กับiการมีค่าอยู่ในช่วงที่แน่นอนและไม่ชัดเจนโดยทันทีเมื่อดูที่รหัสต่อไปนี้ ช่วงที่ยอมรับได้คือ ดังนั้นint i = 3; assert i >= 0 && i < 5;อาจจะเป็นครั้งแรกที่ดูเหมือนไร้สาระ แต่ถ้าคุณคิดเกี่ยวกับมันมันจะบอกคุณว่าคุณอาจจะเล่นด้วยiและก็ยังจะบอกคุณช่วงที่อยู่ในที่ที่คุณต้องอยู่ การยืนยันเป็นเอกสารประเภทที่ดีที่สุดเพราะมันถูกบังคับใช้โดยเครื่องดังนั้นจึงเป็นการรับประกันที่สมบูรณ์แบบและได้รับการปรับโครงสร้างใหม่พร้อมกับรหัสดังนั้นจึงยังคงเกี่ยวข้องกับมันอยู่เสมอ

getUser(int id)ตัวอย่างของคุณไม่ใช่ญาติห่าง ๆ ของassign-constant-and-assert-in-rangeตัวอย่าง คุณจะเห็นข้อบกพร่องเกิดขึ้นเมื่อสิ่งต่าง ๆ แสดงพฤติกรรมซึ่งแตกต่างจากพฤติกรรมที่เราคาดไว้ จริงเราไม่สามารถยืนยันทุกอย่างดังนั้นบางครั้งจะมีการดีบัก แต่มันเป็นความจริงที่ได้รับการยอมรับอย่างดีในอุตสาหกรรมว่ายิ่งเราพบข้อผิดพลาดได้เร็วเท่าไหร่ก็จะยิ่งมีต้นทุนน้อยลงเท่านั้น คำถามที่คุณควรถามไม่เพียง แต่จะแน่ใจได้ว่าคุณเป็นอย่างนั้นgetUser()จะไม่มีวันส่งคืนค่าว่าง (และไม่ส่งคืนชื่อผู้ใช้ด้วยค่า null) แต่จะรวมถึงสิ่งเลวร้ายประเภทใดที่จะเกิดขึ้นกับส่วนที่เหลือของรหัส getUser()ความเป็นจริงในวันหนึ่งกลับมาบางสิ่งบางอย่างที่ไม่คาดคิดและวิธีการที่ง่ายก็คือได้อย่างรวดเร็วโดยมองในส่วนที่เหลือของรหัสที่จะรู้ว่าสิ่งที่ได้รับการคาดหวังของ

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

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

ไม่แน่นอน

ผู้โทรไม่ควรตรวจสอบว่าฟังก์ชั่นการโทรนั้นเคารพสัญญาหรือไม่ เหตุผลง่าย: มีผู้โทรจำนวนมากและเป็นไปไม่ได้และเนื้อหาที่ผิดแม้จากมุมมองแนวคิดสำหรับผู้โทรแต่ละคนและทุกคนเพื่อทำซ้ำตรรกะสำหรับการตรวจสอบผลลัพธ์ของฟังก์ชั่นอื่น ๆ

หากมีการตรวจสอบใด ๆ ที่จะทำแต่ละฟังก์ชั่นควรตรวจสอบโพสต์เงื่อนไขของตัวเอง โพสต์เงื่อนไขให้ความเชื่อมั่นว่าคุณใช้งานฟังก์ชั่นได้อย่างถูกต้องและผู้ใช้จะสามารถเชื่อมั่นในสัญญาของฟังก์ชั่นของคุณ

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

ถ้า null เป็นค่าส่งคืนที่ถูกต้องของเมธอด getUser ดังนั้นโค้ดของคุณควรจัดการกับถ้าไม่ใช่ไม่ใช่ข้อยกเว้นมันไม่ใช่กรณีพิเศษ

หาก null ไม่ใช่ค่าส่งคืนที่ถูกต้องของเมธอด getUser แสดงว่ามีข้อผิดพลาดใน getUser - เมธอด getUser ควรมีข้อยกเว้นหรือได้รับการแก้ไข

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

ฉันขอยืนยันว่าหลักฐานของคำถามของคุณปิดอยู่: ทำไมต้องใช้การอ้างอิงแบบ null เพื่อเริ่มต้นด้วย

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

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

ทำไมอัลกอริทึมควรใส่ใจเกี่ยวกับค่า Null? ขั้นตอนควรเหมือนกัน มันง่ายและชัดเจนกว่าที่จะมีวัตถุว่างเปล่าที่คืนค่าศูนย์สตริงว่าง ฯลฯ

นี่คือตัวอย่างของการตรวจสอบโค้ดสำหรับ null:

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

นี่คือตัวอย่างของรหัสโดยใช้วัตถุ null:

return getUser().getName();

ไหนดีกว่า ฉันเชื่อว่าส่วนที่สองคือ

ในขณะที่คำถามถูกติดแท็กจาวามันก็คุ้มค่าที่จะสังเกตว่ารูปแบบวัตถุ null นั้นมีประโยชน์จริง ๆใน C ++ เมื่อใช้การอ้างอิง การอ้างอิง Java เป็นเหมือนพอยน์เตอร์ C ++ มากขึ้นและอนุญาตให้มีค่าว่างได้ การอ้างอิง C ++ ไม่สามารถเก็บnullptrได้ ถ้าใครอยากจะมีสิ่งที่คล้ายกับการอ้างอิงโมฆะใน C ++, รูปแบบวัตถุโมฆะเป็นวิธีเดียวที่ฉันรู้เพื่อให้บรรลุ

โดยทั่วไปฉันจะบอกว่าส่วนใหญ่ขึ้นอยู่กับสามด้านต่อไปนี้:

1. ความทนทาน: วิธีการโทรสามารถรับมือกับnullค่าได้หรือไม่ หากnullค่าอาจส่งผลให้RuntimeExceptionฉันขอแนะนำให้ตรวจสอบ - ยกเว้นความซับซ้อนต่ำและวิธีการโทร / โทรถูกสร้างขึ้นโดยผู้เขียนคนเดียวกันและnullไม่ได้คาดหวัง (เช่นทั้งprivateในแพคเกจเดียวกัน)

2. ความรับผิดชอบของโค้ด: หากนักพัฒนา A รับผิดชอบต่อgetUser()วิธีการและนักพัฒนา B ใช้มัน (เช่นเป็นส่วนหนึ่งของห้องสมุด) ฉันขอแนะนำอย่างยิ่งให้ตรวจสอบความถูกต้องของค่า เพียงเพราะนักพัฒนา B อาจไม่ทราบเกี่ยวกับการเปลี่ยนแปลงที่ส่งผลให้มีnullค่าตอบแทนที่เป็นไปได้

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

นอกจากนี้ฉันขอแนะนำให้จัดทำเอกสารที่มีศักยภาพ nullค่าส่งคืนที่เป็นไปได้ในความคิดเห็น JavaDoc เนื่องจากการไฮไลต์ของคำอธิบาย JavaDoc ใน IDEs getUser()ส่วนใหญ่นี้อาจจะเป็นคำเตือนที่เป็นประโยชน์สำหรับใครก็ตามที่ใช้

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

คุณไม่จำเป็นต้องทำอย่างแน่นอน

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