สัญญารหัส / ยืนยัน: สิ่งที่มีการตรวจสอบซ้ำกัน?

ฉันเป็นแฟนตัวยงของการเขียนข้อตกลงสัญญาหรือเช็คประเภทใดก็ได้ที่มีในภาษาที่ฉันใช้ สิ่งหนึ่งที่ทำให้ฉันรำคาญใจเล็กน้อยคือฉันไม่แน่ใจว่าการปฏิบัติทั่วไปสำหรับการตรวจสอบซ้ำซ้อนคืออะไร

สถานการณ์ตัวอย่าง: ฉันเขียนฟังก์ชันต่อไปนี้ก่อน

void DoSomething( object obj )
{
  Contract.Requires<ArgumentNullException>( obj != null );
  //code using obj
}

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

void DoSomethingElse( object obj )
{
  //no Requires here: DoSomething will do that already
  DoSomething( obj );
  //code using obj
}

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

void DoSomethingElse( object obj )
{
  Contract.Requires<ArgumentNullException>( obj != null );
  DoSomething( obj );
  //code using obj
}

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

การปฏิบัติที่พบบ่อยที่สุดสำหรับสถานการณ์เช่นนี้คืออะไร?

โดยส่วนตัวฉันจะตรวจสอบโมฆะในฟังก์ชั่นใด ๆ ที่จะล้มเหลวถ้ามันได้รับโมฆะและไม่ได้อยู่ในฟังก์ชั่นที่จะไม่

ดังนั้นในตัวอย่างข้างต้นของคุณถ้า doSomethingElse () ไม่จำเป็นต้องทำการค้นหาซ้ำดังนั้นฉันจะไม่ตรวจสอบ obj สำหรับค่าว่าง

หาก DoSomething () ทำการยกเลิกการอ้างอิงควรตรวจสอบค่าว่าง

หากทั้งสองฟังก์ชั่นไม่ลงรอยกันก็ควรตรวจสอบทั้งคู่ ดังนั้นถ้า DoSomethingElse dereferences obj ควรตรวจสอบ null แต่ DoSomething ยังควรตรวจสอบ null เนื่องจากอาจถูกเรียกจากพา ธ อื่น

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

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

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

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

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

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