เหตุใดจึงใช้ตัวเลือกใน Java 8+ แทนการตรวจสอบตัวชี้โมฆะแบบดั้งเดิม

เราเพิ่งย้ายไปยัง Java 8 ตอนนี้ฉันเห็นแอปพลิเคชันที่เต็มไปด้วยOptionalวัตถุ

ก่อน Java 8 (สไตล์ 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

หลังจาก Java 8 (สไตล์ 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

ฉันไม่เห็นคุณค่าที่เพิ่มขึ้นของOptional<Employee> employeeOptional = employeeService.getEmployee();เวลาที่บริการกลับมาเป็นตัวเลือก:

มาจากพื้นหลัง Java 6 ฉันเห็นสไตล์ 1 ชัดเจนกว่าและมีโค้ดน้อยกว่า มีข้อได้เปรียบที่แท้จริงที่ฉันหายไปที่นี่หรือไม่?

รวบรวมจากความเข้าใจจากคำตอบทั้งหมดและการวิจัยเพิ่มเติมที่บล็อก

สไตล์ 2 ไม่เพียงพอสำหรับ Java 8 เพื่อให้เห็นประโยชน์เต็มที่ คุณไม่ต้องการif ... useเลย ดูตัวอย่างของออราเคิล เราได้รับคำแนะนำจากพวกเขา

สไตล์ 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

หรือตัวอย่างข้อมูลที่ยาวขึ้น

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

หากคุณใช้Optionalเป็นเลเยอร์ "ความเข้ากันได้" ระหว่าง API ที่เก่ากว่าซึ่งอาจยังส่งคืนnullอาจเป็นประโยชน์ในการสร้างตัวเลือก (ไม่ว่างเปล่า) ในขั้นตอนล่าสุดที่คุณมั่นใจว่ามี เช่นที่คุณเขียน:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

ฉันเลือกที่จะ:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

ประเด็นก็คือว่าคุณรู้ว่ามีพนักงานที่ไม่ใช่ null บริการเพื่อให้คุณสามารถห่อที่ขึ้นมาในด้วยOptional Optional.of()จากนั้นเมื่อคุณโทรหาgetEmployee()คุณอาจจะได้หรือไม่รับพนักงานก็ได้ พนักงานคนนั้นอาจ (หรืออาจจะไม่) มี ID จากนั้นหากคุณจบด้วย ID คุณต้องการพิมพ์

ไม่จำเป็นต้องตรวจสอบnull ใด ๆ การมีอยู่ ฯลฯ ในรหัสนี้อย่างชัดเจน

ถัดจากไม่มีค่าเพิ่มในการOptionalมีค่าเดียว ดังที่คุณเห็นนั่นเป็นเพียงการแทนที่เช็คnullด้วยการตรวจสอบสถานะ

มีมูลค่าเพิ่มมากในการมีCollectionสิ่งนั้น ทุกวิธีการสตรีมมิ่งนำไปแทนที่แบบเก่าลูปในระดับต่ำเข้าใจOptionalสิ่งต่าง ๆ และทำในสิ่งที่ถูกต้องเกี่ยวกับพวกเขา (ไม่ประมวลผลพวกเขาหรือท้ายที่สุดกลับไม่มีการตั้งค่าอื่นOptional) หากคุณจัดการกับรายการnบ่อยกว่ารายการแต่ละรายการ (และ 99% ของรายการที่เหมือนจริงทั้งหมด) มันเป็นการปรับปรุงครั้งใหญ่ที่มีการสนับสนุนในตัวสำหรับการนำเสนอทางเลือก ในกรณีที่เหมาะสมที่สุดคุณไม่จำเป็นต้องตรวจสอบnull หรือแสดงตน

ตราบใดที่คุณใช้Optionalเช่นเดียวกับ API แฟนซีสำหรับisNotNull()แล้วใช่คุณจะไม่พบความแตกต่างใด ๆ nullมีเพียงการตรวจสอบ

สิ่งที่คุณไม่ควรใช้Optionalสำหรับ

การใช้Optionalเพียงเพื่อตรวจสอบว่ามีค่าอยู่หรือไม่นั่นคือ Bad Code ™:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

สิ่งที่คุณควรใช้Optionalสำหรับ

หลีกเลี่ยงค่าที่ไม่มีอยู่โดยสร้างค่าเมื่อจำเป็นเมื่อใช้เมธอด null-return API:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

หรือถ้าการสร้างพนักงานใหม่มีค่าใช้จ่ายสูงเกินไป:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

นอกจากนี้การทำให้ทุกคนทราบว่าวิธีการของคุณอาจไม่ส่งคืนค่า (ถ้าด้วยเหตุผลใดก็ตามคุณไม่สามารถส่งคืนค่าเริ่มต้นเหมือนด้านบน):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

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

จุดสำคัญสำหรับฉันในการใช้ตัวเลือกเป็นที่ชัดเจนเมื่อนักพัฒนาต้องการตรวจสอบว่าค่าส่งคืนฟังก์ชั่นหรือไม่

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

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

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

แน่นอนคำถามอย่างรวดเร็วกลายเป็น "ทำไมเป็นปัจจุบันและไปถึงที่นั่น?"

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

แต่ให้ประโยชน์สองสามอย่าง (สอง) ดียอดเยี่ยมและมีเสน่ห์ (?):

• มันง่ายต่อการเปลี่ยนรหัสดั้งเดิมเพื่อใช้คุณสมบัติใหม่
• มันลดความโค้งการเรียนรู้ของตัวเลือก

คนแรกค่อนข้างง่าย

ลองนึกภาพคุณมี API ที่มีลักษณะดังนี้:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

และคุณมีชั้นเรียนดั้งเดิมที่ใช้สิ่งนี้ (กรอกข้อมูลในช่องว่าง):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

ตัวอย่างที่วางแผนไว้เพื่อให้แน่ใจ แต่ทนกับฉันที่นี่

Java 8 ได้เปิดตัวแล้วและเรากำลังดิ้นรนเพื่อขึ้นเรือ ดังนั้นสิ่งหนึ่งที่เราทำคือเราต้องการแทนที่อินเทอร์เฟซเก่าของเราด้วยสิ่งที่ส่งกลับทางเลือก ทำไม? เพราะอย่างที่คนอื่นได้กล่าวถึงอย่างมีน้ำใจ: นี่เป็นการคาดเดาจากสิ่งที่เป็นโมฆะหรือไม่สิ่ง นี้ได้ถูกชี้ไปแล้วโดยคนอื่น แต่ตอนนี้เรามีปัญหา ลองนึกภาพเรามี (แก้ตัวให้ฉันในขณะที่ฉันกด alt + F7 ด้วยวิธีการที่ไร้เดียงสา), 46 แห่งที่วิธีนี้เรียกว่าในรหัสทดสอบที่ผ่านการทดสอบมาอย่างดีซึ่งทำงานได้ดีมาก ตอนนี้คุณต้องอัปเดตสิ่งเหล่านี้ทั้งหมด

นี่คือที่เป็นปัจจุบันส่องสว่าง

เพราะตอนนี้: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {โยน NoSuchSnickersException ใหม่ (); } else {consumer.giveDiabetes (lastSnickers); }

กลายเป็น:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

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

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

ในกรณีของคุณที่คุณต้องการพิมพ์บางสิ่งออกไปคุณก็ทำได้:

. snickersCounter.lastConsumedSnickers () ifPresent (System.out :: println);

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

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

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

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

แน่นอนว่าเวอร์ชั่นที่ดูดีในลักษณะนี้:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

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

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

ฉันไม่เห็นประโยชน์ในรูปแบบ 2 คุณยังต้องตระหนักว่าคุณต้องมีการตรวจสอบค่าว่างและตอนนี้มันยิ่งใหญ่ขึ้นทำให้อ่านง่ายขึ้น

สไตล์ที่ดีกว่าก็คือถ้า employeeServive.getEmployee () จะส่งกลับทางเลือกและจากนั้นรหัสก็จะกลายเป็น:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

วิธีนี้คุณจะไม่สามารถ callemployeeServive.getEmployee (). getId () และคุณสังเกตเห็นว่าคุณควรจัดการกับตัวเลือก valoue อย่างใด และถ้าในวิธีการ codebase ทั้งหมดของคุณจะไม่ส่งคืนค่าว่าง (หรือเกือบจะไม่เคยเป็นที่รู้จักกันดีในทีมของคุณยกเว้นกฎนี้) มันจะเพิ่มความปลอดภัยจาก NPE

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

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

อย่างไรก็ตามเพื่อให้สามารถใช้งานได้คุณต้องใช้รูปแบบนี้อย่างสม่ำเสมอ

คำตอบของฉันคือ: ไม่ได้ อย่างน้อยก็คิดให้ดีว่ามันเป็นการปรับปรุงหรือไม่

การแสดงออก (นำมาจากคำตอบอื่น) เช่น

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

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

มันดูดีกว่าแบบเก่า

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

ซึ่งทำให้เห็นได้ชัดว่าอาจมีส่วนelseคำสั่ง

สไตล์การใช้งาน

• ดูแตกต่างไปจากเดิมอย่างสิ้นเชิง (และไม่สามารถอ่านได้สำหรับคนที่ไม่ได้ใช้)
• เป็นความเจ็บปวดในการแก้ปัญหา
• ไม่สามารถขยายได้อย่างง่ายดายสำหรับการจัดการกรณี "ขาด" ( orElseไม่เพียงพอเสมอ)
• ทำให้เข้าใจผิดในการเพิกเฉยกรณี "ขาด"

ไม่ควรใช้เป็นยาครอบจักรวาล ถ้ามันใช้ได้ในระดับสากลดังนั้นความหมายของ.ผู้ปฏิบัติงานควรถูกแทนที่ด้วยความหมายของ?.ผู้ปฏิบัติงาน NPE ที่ถูกลืมและปัญหาทั้งหมดถูกเพิกเฉย

ในขณะที่เป็นแฟนชวาตัวยงฉันต้องบอกว่าสไตล์การใช้งานเป็นเพียงคำสั่งที่ไม่ดีของชายชวา

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

รู้จักกันดีจากภาษาอื่น ๆ เราเห็นด้วยไหมว่าข้อความนี้

• มันใช้งานไม่ได้จริงเหรอ?
• คล้ายกับรหัสแบบเก่าง่ายกว่านี้มากเพียงใด
• สามารถอ่านได้มากกว่าสไตล์การใช้งานหรือไม่
• เป็นมิตรกับการดีบั๊กหรือไม่

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