หากฟังก์ชั่นต้องทำการตรวจสอบโมฆะก่อนที่จะทำการออกแบบที่ไม่ดี

ดังนั้นฉันไม่รู้ว่านี่เป็นการออกแบบรหัสที่ดีหรือไม่ดีดังนั้นฉันจึงคิดว่าฉันควรถาม

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

สำหรับตัวอย่างพื้นฐานมาก:

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

ดังนั้นคุณจะเห็นการตรวจสอบ im สำหรับ null ทุกครั้ง แต่วิธีการนี้ควรไม่มีเช็คนี้หรือไม่?

ตัวอย่างเช่นควรโค้ดภายนอกทำความสะอาดข้อมูลก่อนมือดังนั้นวิธีการไม่จำเป็นต้องตรวจสอบเช่นด้านล่าง:

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

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

ปัญหากับตัวอย่างขั้นพื้นฐานของคุณไม่ได้ตรวจสอบเป็นโมฆะก็เงียบล้มเหลว

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

1. อย่ารบกวนการตรวจสอบและปล่อยให้รันไทม์โยนข้อยกเว้น nullpointer
2. ตรวจสอบและโยนข้อยกเว้นด้วยข้อความที่ดีกว่าข้อความ NPE พื้นฐาน

วิธีที่สามทำงานได้ดีกว่า แต่มีประสิทธิภาพมากกว่า:

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

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

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

เนื่องจาก_someEntityสามารถแก้ไขได้ทุกขั้นตอนดังนั้นจึงเหมาะสมที่จะทดสอบทุกครั้งที่SetNameมีการเรียก ท้ายที่สุดมันอาจมีการเปลี่ยนแปลงตั้งแต่ครั้งสุดท้ายที่วิธีการที่เรียกว่า แต่ทราบว่ารหัสในSetNameไม่ด้ายปลอดภัยเพื่อให้คุณสามารถดำเนินการตรวจสอบว่าในหนึ่งด้ายได้_someEntityตั้งค่าให้nullอีกแล้วรหัสจะ barf NullReferenceExceptionอยู่แล้ว

วิธีหนึ่งในการแก้ไขปัญหานี้คือการป้องกันให้ดียิ่งขึ้นและทำสิ่งใดสิ่งหนึ่งต่อไปนี้:

1. ทำสำเนาของท้องถิ่น_someEntityและการอ้างอิงที่คัดลอกผ่านวิธีการ
2. ใช้ตัวล็อก_someEntityเพื่อให้แน่ใจว่ามันจะไม่เปลี่ยนแปลงเมื่อวิธีการทำงาน
3. ใช้ a try/catchและทำการกระทำแบบเดียวกันกับสิ่งNullReferenceExceptionที่เกิดขึ้นภายในวิธีการที่คุณดำเนินการในการตรวจสอบโมฆะครั้งแรก (ในกรณีนี้คือการnopกระทำ)

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

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

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

ในฐานะที่เป็นความคิดเห็นโบนัสฉันรู้สึกว่ารหัสของคุณแปลกและอาจปรับปรุงได้ ทั้งหมดของ:

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

สามารถถูกแทนที่ด้วย:

public Entity SomeEntity { get; set; }

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

แต่วิธีการนี้ควรไม่มีเช็คนี้หรือไม่?

นี่คือทางเลือกของคุณ

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

สัญญาประเภทใดที่คุณต้องการออกแบบขึ้นอยู่กับคุณ สิ่งที่สำคัญคือ

• สร้าง API ที่มีประโยชน์และสอดคล้องและ

• จัดทำเอกสารได้ดีโดยเฉพาะอย่างยิ่งสำหรับกรณีขอบเหล่านั้น

มีกรณีใดบ้างที่วิธีการของคุณถูกเรียก?

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

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

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

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

ตัวอย่างเช่นคุณไม่ต้องการที่จะอยู่ในสถานการณ์นี้:

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

และที่ไซต์การโทร:

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

เนื่องจาก (1) คุณกำลังฝึกผู้โทรว่าโมฆะเป็นค่าที่ดีและ (2) ไม่ชัดเจนว่าความหมายของค่านั้นคืออะไร ค่อนข้างทำสิ่งนี้:

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

และตอนนี้ไซต์การโทรมีลักษณะดังนี้:

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

และตอนนี้ผู้อ่านรหัสรู้ถึงความหมายของมัน

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

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

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

a.Something = b.Something;

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

ฉันจะทราบว่ารูปแบบในรหัสต้นฉบับของคุณ:

if (x == null) return;

สามารถใช้งานได้ในบางสถานการณ์มันยังสามารถ (อาจบ่อยกว่า) ให้วิธีที่ดีในการปิดบังปัญหาพื้นฐานในโค้ดเบสของคุณ

ไม่มีเลย แต่ขึ้นอยู่กับ

คุณทำการตรวจสอบการอ้างอิงเป็นโมฆะถ้าคุณต้องการที่จะตอบสนอง

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

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

ส่วนขยายบางส่วนของคำตอบของ @ null แต่จากประสบการณ์ของฉันแล้ว null จะตรวจสอบไม่ว่าจะเกิดอะไรขึ้น

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

ทีนี้วิธีที่คุณจะจัดการกับnullคุณค่านั้นขึ้นอยู่กับกรณีการใช้งานของคุณเป็นอย่างมาก

หากnullเป็นค่าที่ยอมรับได้เช่นพารามิเตอร์ตัวใดตัวที่สองถึงห้าถึงรูทีน MSVC _splitpath () แสดงว่าการจัดการอย่างเงียบ ๆ นั้นเป็นพฤติกรรมที่ถูกต้อง

หากnullไม่ควรเกิดขึ้นเมื่อเรียกรูทีนที่มีปัญหาเช่นในกรณีของ OP สัญญา API ต้องAssignEntity()ได้รับการเรียกด้วยการใช้งานที่ถูกต้องEntityจากนั้นโยนข้อยกเว้นหรือไม่เช่นนั้นจะทำให้แน่ใจว่าคุณทำเสียงดังมากในกระบวนการ

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