คำถามติดแท็ก code-contracts

ฉันเพิ่งสะดุดกับกรอบของ Microsoft สำหรับสัญญารหัส ฉันอ่านเอกสารนิดหน่อยและพบว่าตัวเองถามอยู่ตลอดเวลา: "ทำไมฉันถึงต้องการทำสิ่งนี้เพราะมันไม่ได้และไม่สามารถทำการวิเคราะห์แบบสแตติกได้" ตอนนี้ฉันมีรูปแบบการเขียนโปรแกรมป้องกันอยู่แล้วโดยมีข้อยกเว้นป้องกันเช่นนี้: if(var == null) { throw new NullArgumentException(); } ฉันยังใช้ NullObject Pattern มากและไม่ค่อยมีปัญหาใด ๆ เพิ่มการทดสอบหน่วยเข้ากับมันและคุณก็พร้อมแล้ว ฉันไม่เคยใช้การยืนยันและไม่เคยพลาดพวกเขา ค่อนข้างตรงกันข้าม ฉันเกลียดโค้ดที่มีการอ้างถึงที่ไร้ความหมายมากมายซึ่งเป็นเพียงเสียงรบกวนสำหรับฉันและเบี่ยงเบนความสนใจจากสิ่งที่ฉันต้องการเห็น รหัสสัญญาอย่างน้อยที่สุดวิธีของ Microsoft ก็เหมือนกันมาก - และยิ่งแย่ลงไปกว่านั้น พวกเขาเพิ่มเสียงรบกวนและความซับซ้อนให้กับโค้ด ใน 99% ข้อยกเว้นจะถูกโยนต่อไป - ดังนั้นฉันไม่สนใจว่ามันมาจากการยืนยัน / สัญญาหรือปัญหาจริง มีเพียงไม่กี่รายเท่านั้นที่ยังคงอยู่ซึ่งโปรแกรมระบุว่ามีความเสียหายจริง ๆ ดังนั้นข้อดีของการใช้สัญญาโค้ดคืออะไร มีใครบ้างไหม? หากคุณใช้การทดสอบหน่วยและรหัสป้องกันอยู่แล้วฉันรู้สึกว่าการแนะนำสัญญาไม่คุ้มกับค่าใช้จ่ายและทำให้เกิดเสียงรบกวนในรหัสของคุณที่ผู้ดูแลจะสาปแช่งเมื่อเขาอัปเดตวิธีดังกล่าวเหมือนกับที่ฉันทำเมื่อฉันไม่เห็นว่ารหัสกำลังทำอะไร เนื่องจากการยืนยันที่ไร้ประโยชน์ ฉันยังไม่เห็นเหตุผลที่ดีที่จะจ่ายราคา

26 code-contracts 

ฉันกำลังเรียนรู้เกี่ยวกับสัญญารหัสใน. NET และฉันพยายามเข้าใจแนวคิดของผู้สร้างที่บริสุทธิ์ สัญญารหัสเอกสารฯ : วิธีการทั้งหมดที่เรียกว่าภายในสัญญาจะต้องบริสุทธิ์ นั่นคือพวกเขาจะต้องไม่ปรับปรุงสถานะก่อนหน้าใด ๆ วิธีบริสุทธิ์ได้รับอนุญาตให้แก้ไขวัตถุที่สร้างขึ้นหลังจากเข้าสู่วิธีบริสุทธิ์ และPureAttributeเอกสารประกอบฯ : บ่งชี้ว่าชนิดหรือเมธอดนั้นบริสุทธิ์นั่นคือมันไม่ได้ทำการเปลี่ยนแปลงสถานะใด ๆ ที่มองเห็นได้ ฉันเข้าใจข้อความเหล่านี้เมื่อพูดถึงวิธีการ แต่สิ่งที่เกี่ยวกับตัวสร้าง สมมติว่าคุณมีชั้นเรียนเช่นนี้: public class Foo { public int Value { get; set; } public Foo(int value) { this.Value = value; } } คอนสตรัคเตอร์นี้เห็นได้ชัดว่ามีผลต่อสถานะของFooวัตถุใหม่แต่ไม่มีผลข้างเคียงอื่น ๆ (เช่นมันไม่ได้ใช้พารามิเตอร์ใด ๆ หรือเรียกวิธีการที่ไม่บริสุทธิ์) เป็นผู้สมัคร[Pure]หรือไม่? อะไรคือความสำคัญของการวางแอ[Pure]ททริบิวต์ลงในคอนสตรัคเตอร์และเมื่อไหร่ที่ฉันควรทำสิ่งนี้ในโค้ดของตัวเอง?

19 c#  .net  code-contracts  pure-function 

ฉันเป็นโปรแกรมเมอร์ที่ค่อนข้างป้องกันและเป็นแฟนตัวยงของ Microsoft Code Contracts ตอนนี้ฉันไม่สามารถใช้ C # และในภาษาส่วนใหญ่เครื่องมือเดียวที่ฉันมีคือการยืนยัน ดังนั้นฉันมักจะจบลงด้วยรหัสเช่นนี้: class { function() { checkInvariants(); assert(/* requirement */); try { /* implementation */ } catch(...) { assert(/* exceptional ensures */); } finally { assert(/* ensures */); checkInvariants(); } } void checkInvariants() { assert(/* invariant */); } } อย่างไรก็ตามกระบวนทัศน์นี้ (หรือสิ่งที่คุณจะเรียกว่า) นำไปสู่ความยุ่งเหยิงของรหัสจำนวนมาก ฉันเริ่มสงสัยว่ามันคุ้มค่ากับความพยายามจริง …

13 testing  code-contracts 

ฉันเป็นแฟนตัวยงของการเขียนข้อตกลงสัญญาหรือเช็คประเภทใดก็ได้ที่มีในภาษาที่ฉันใช้ สิ่งหนึ่งที่ทำให้ฉันรำคาญใจเล็กน้อยคือฉันไม่แน่ใจว่าการปฏิบัติทั่วไปสำหรับการตรวจสอบซ้ำซ้อนคืออะไร สถานการณ์ตัวอย่าง: ฉันเขียนฟังก์ชันต่อไปนี้ก่อน 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 อาจไม่ได้รับการตรวจสอบอีกต่อไป ซึ่งทำให้ฉันเขียนการใช้งานนี้หลังจากทั้งหมด: …

10 assertions  code-contracts 

ฉันกำลังทำโครงการวิจัยที่ฉันค้นคว้าตัวเลือกเพื่อจัดการการเปลี่ยนแปลงในสถาปัตยกรรมไมโครบริการที่ขับเคลื่อนด้วยเหตุการณ์ สมมุติว่าเรามีแอปพลิเคชั่นที่ให้บริการต่าง ๆ สี่อย่าง แต่ละบริการเหล่านี้มีฐานข้อมูลของตัวเองเพื่อเก็บข้อมูลในเครื่อง ในการตั้งค่านี้บริการสี่รายการสื่อสารกันโดยใช้ Event Bus ดังนั้นเมื่อมีสิ่งใดเกิดขึ้นในบริการมันจะเผยแพร่กิจกรรม บริการอื่น ๆ ทั้งหมดที่มีความสนใจในเหตุการณ์นั้นจะดำเนินการด้วยวิธีของตนเอง ในกรณีนี้บริการต่าง ๆ ในสถาปัตยกรรมจำเป็นต้องมี "สัญญา" เกี่ยวกับเนื้อหาของเหตุการณ์เหล่านี้ (แอตทริบิวต์ ฯลฯ ) ดังนั้นบริการจึงมี "การพึ่งพาคู่กันอย่างหลวม ๆ " ต่อเหตุการณ์เหล่านี้ คำถามของฉันคือ: เราจะจัดการการเปลี่ยนแปลงในเหตุการณ์เหล่านี้ได้อย่างไร ดังนั้นบริการสมมติว่าลงทะเบียนผู้ใช้ใหม่ในแอปพลิเคชัน ดังนั้นจึงส่งกิจกรรม "" UserRegistered "Service B เลือกกิจกรรมนั้นและประมวลผล แต่นักพัฒนาบางคนในทีมบริการ C ตัดสินใจว่าพวกเขาต้องการเพศของผู้ใช้ที่ลงทะเบียนด้วยดังนั้นเหตุการณ์จึงเปลี่ยนไปและแอตทริบิวต์เพศ ถูกเพิ่มไปยังเหตุการณ์ "UserRegistered" เราจะมั่นใจได้อย่างไรว่า Service B ยังสามารถรับเหตุการณ์เดียวกันด้วยคุณสมบัติพิเศษนั้นโดยไม่ต้องปรับใช้ซ้ำ และมีวิธีอื่นในการแก้ไขปัญหานี้แล้วกำหนดเหตุการณ์เหล่านี้หรือไม่

9 communication  versioning  microservices  message-queue  code-contracts