คำถามติดแท็ก null

ฉันได้ยินมาว่าการรวมการอ้างอิงโมฆะในภาษาการเขียนโปรแกรมเป็น "ความผิดพลาดพันล้านดอลลาร์" แต่ทำไม แน่นอนว่าพวกเขาสามารถทำให้ NullReferenceExceptions ได้ แต่อย่างนั้น องค์ประกอบของภาษาใด ๆ สามารถเป็นแหล่งของข้อผิดพลาดหากใช้ไม่ถูกต้อง และทางเลือกคืออะไร? ฉันคิดว่าแทนที่จะพูดสิ่งนี้: Customer c = Customer.GetByLastName("Goodman"); // returns null if not found if (c != null) { Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); } else { Console.WriteLine("There was no customer named Goodman. How lame!"); } คุณสามารถพูดสิ่งนี้: …

161 language-design  exceptions  pointers  null 

เมื่อสัปดาห์ที่แล้วเรามีข้อโต้แย้งที่รุนแรงเกี่ยวกับการจัดการโมฆะในชั้นบริการของแอปพลิเคชันของเรา คำถามอยู่ในบริบท. NET แต่จะเหมือนกันใน Java และเทคโนโลยีอื่น ๆ คำถามคือคุณควรตรวจสอบค่า Null และทำให้โค้ดทำงานไม่ว่าจะเกิดอะไรขึ้นหรือปล่อยให้เกิดฟองสบู่ขึ้นเมื่อได้รับค่า Null อย่างไม่คาดคิด ในอีกด้านหนึ่งการตรวจสอบ null ที่คุณไม่ได้คาดหวัง (เช่นไม่มีส่วนติดต่อผู้ใช้ที่จะจัดการ) คือในความคิดของฉันเช่นเดียวกับการเขียนบล็อกลองกับจับเปล่า คุณกำลังซ่อนข้อผิดพลาด ข้อผิดพลาดอาจเป็นไปได้ว่าบางสิ่งมีการเปลี่ยนแปลงในรหัสและ null ตอนนี้เป็นค่าที่คาดไว้หรือมีข้อผิดพลาดอื่น ๆ และรหัสผิดจะถูกส่งผ่านไปยังวิธีการ ในทางกลับกันการตรวจสอบ nulls อาจเป็นนิสัยที่ดีโดยทั่วไป นอกจากนี้หากมีการตรวจสอบแอปพลิเคชันอาจทำงานต่อไปโดยมีเพียงส่วนเล็ก ๆ ของฟังก์ชันที่ไม่มีผลกระทบใด ๆ จากนั้นลูกค้าอาจรายงานข้อบกพร่องเล็ก ๆ เช่น "ไม่สามารถลบความคิดเห็น" แทนที่จะเป็นข้อบกพร่องที่รุนแรงมากเช่น "ไม่สามารถเปิดหน้า X" คุณทำตามแบบฝึกหัดอะไรบ้างและอะไรคือข้อโต้แย้งของคุณสำหรับหรือต่อต้านแนวทางใดแนวทางหนึ่ง? ปรับปรุง: ฉันต้องการเพิ่มรายละเอียดเกี่ยวกับกรณีของเราโดยเฉพาะ เราได้รับวัตถุบางอย่างจากฐานข้อมูลและทำการประมวลผลบางอย่างกับพวกมัน (สมมติว่าสร้างชุดสะสม) นักพัฒนาที่เขียนรหัสไม่ได้คาดหวังว่าวัตถุอาจเป็นโมฆะดังนั้นเขาจึงไม่ได้รวมการตรวจสอบใด ๆ และเมื่อโหลดหน้าเว็บแล้วพบว่ามีข้อผิดพลาดและไม่ได้โหลดหน้าทั้งหมด เห็นได้ชัดว่าในกรณีนี้ควรมีการตรวจสอบ จากนั้นเราได้พิจารณาว่าควรตรวจสอบวัตถุทุกชิ้นที่ประมวลผลแม้ว่าจะไม่คาดว่าจะหายไปหรือไม่และควรยกเลิกการประมวลผลในที่สุดหรือไม่ ประโยชน์สมมุติจะเป็นหน้าจะทำงานต่อไป นึกถึงผลการค้นหาใน Exchange …

113 error-handling  null 

ฉันแน่ใจว่าผู้ออกแบบภาษาเช่น Java หรือ C # รู้ปัญหาที่เกี่ยวข้องกับการมีอยู่ของการอ้างอิงที่เป็นโมฆะ (ดูที่การอ้างอิงโมฆะเป็นเรื่องเลวร้ายจริง ๆ หรือไม่ ) การใช้ประเภทตัวเลือกนั้นไม่ซับซ้อนกว่าการอ้างอิงแบบ null เหตุใดพวกเขาจึงตัดสินใจรวมไว้ด้วย ฉันแน่ใจว่าการอ้างอิงที่ไม่มีค่า null จะสนับสนุน (หรือบังคับให้ใช้) รหัสคุณภาพที่ดีกว่า (โดยเฉพาะการออกแบบห้องสมุดที่ดีกว่า) ทั้งจากผู้สร้างภาษาและผู้ใช้ มันเป็นเพียงเพราะการอนุรักษ์ - "ภาษาอื่นมีเราต้องได้เช่นกัน ... "?

82 language-design  null 

ฉันรู้ว่าหัวข้อนี้ขัดแย้งกันเล็กน้อยและมีบทความ / ความคิดเห็นมากมายลอยอยู่ในอินเทอร์เน็ต โชคไม่ดีที่พวกเขาส่วนใหญ่คิดว่าบุคคลนั้นไม่รู้ว่าความแตกต่างระหว่าง NULL และสตริงว่างคืออะไร ดังนั้นพวกเขาจึงบอกเล่าเรื่องราวเกี่ยวกับผลลัพธ์ที่น่าประหลาดใจด้วยการรวม / สรุปรวมและโดยทั่วไปจะทำบทเรียน SQL ขั้นสูงเพิ่มเติม โดยการทำเช่นนี้พวกเขาพลาดจุดทั้งหมดและไม่มีประโยชน์สำหรับฉัน ดังนั้นหวังว่าคำถามนี้และคำตอบทั้งหมดจะย้ายไปข้างหน้าเล็กน้อย สมมติว่าฉันมีตารางที่มีข้อมูลส่วนบุคคล (ชื่อ, วันเกิด, ฯลฯ ) โดยที่หนึ่งในคอลัมน์คือที่อยู่อีเมลที่มีประเภท varchar เราคิดว่าด้วยเหตุผลบางคนบางคนอาจไม่ต้องการให้ที่อยู่อีเมล เมื่อแทรกข้อมูลดังกล่าว (ไม่มีอีเมล) ลงในตารางมีสองตัวเลือกที่ใช้ได้: ตั้งค่าเซลล์เป็น NULL หรือตั้งค่าเป็นสตริงว่าง ('') สมมติว่าฉันทราบถึงผลกระทบทางเทคนิคทั้งหมดของการเลือกโซลูชันหนึ่งมากกว่าโซลูชันอื่นและฉันสามารถสร้างแบบสอบถาม SQL ที่ถูกต้องสำหรับสถานการณ์ใดสถานการณ์หนึ่ง ปัญหาคือแม้เมื่อค่าทั้งสองแตกต่างกันในระดับเทคนิคพวกเขาจะเหมือนกันในระดับตรรกะ หลังจากดู NULL และ '' ฉันได้ข้อสรุปเดียว: ฉันไม่รู้ที่อยู่อีเมลของผู้ชายคนนั้น ไม่ว่าฉันจะพยายามมากแค่ไหน ฉันไม่สามารถส่งอีเมลโดยใช้ NULL หรือสตริงว่างเปล่าได้ดังนั้นเซิร์ฟเวอร์ SMTP ส่วนใหญ่ก็เห็นด้วยกับเหตุผลของฉัน ดังนั้นฉันมักจะใช้ค่า NULL ที่ฉันไม่ทราบค่าและพิจารณาสตริงว่างเปล่าเป็นสิ่งที่ไม่ดี หลังจากการพูดคุยอย่างเข้มข้นกับเพื่อนร่วมงานฉันมาด้วยคำถามสองข้อ: ฉันถูกสมมติว่าการใช้สตริงว่างเปล่าสำหรับค่าที่ไม่รู้จักทำให้ฐานข้อมูล "โกหก" …

72 design  database  sql  strings  null 

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

71 database  null 

การทำงานกับปัญหาที่ใช้สูตรการเปลี่ยนแปลงเปอร์เซ็นต์: percent change = 100 * [(new value - old value) / old value] ฉันจะอธิบายความแตกต่างได้อย่างไรnew value or old value = NULLแทนที่จะเป็น0กับคนที่อาจไม่ใช่โปรแกรมเมอร์ เจ้านายของฉันสงสัยว่าทำไมมีสตริงว่างในกล่องข้อความมากกว่าค่าเพราะเรามีค่าเก่า แต่ไม่ใช่ค่าใหม่

59 null  tsql 

เอริค Lippert ทำให้เป็นจุดที่น่าสนใจมากในการอภิปรายของเขาว่าทำไม C # ใช้nullมากกว่าMaybe<T>ประเภท : ความสอดคล้องของระบบพิมพ์เป็นสิ่งสำคัญ เราจะรู้ได้หรือไม่ว่าการอ้างอิงที่ไม่เป็นโมฆะนั้นไม่เคยภายใต้สถานการณ์ใด ๆ สิ่งที่เกี่ยวกับในตัวสร้างของวัตถุที่มีเขตข้อมูลที่ไม่เป็นโมฆะประเภทการอ้างอิง? สิ่งที่เกี่ยวกับใน finalizer ของวัตถุดังกล่าวที่วัตถุจะเสร็จสมบูรณ์เพราะรหัสที่ควรจะกรอกในการอ้างอิงโยนข้อยกเว้น? ระบบการพิมพ์ที่อยู่กับคุณเกี่ยวกับการรับประกันเป็นสิ่งที่อันตราย นั่นเป็นสิ่งที่เปิดตา แนวคิดเกี่ยวข้องกับฉันและฉันได้เล่นกับคอมไพเลอร์และระบบพิมพ์ แต่ฉันไม่เคยคิดถึงเรื่องนั้น ภาษาที่มีประเภทอาจจะเป็นอย่างไรแทนที่จะเป็นกรณีที่จับขอบโมฆะเช่นการเริ่มต้นและการกู้คืนข้อผิดพลาดซึ่งในความเป็นจริงการอ้างอิงที่ไม่ใช่โมฆะรับประกันไม่จริงในสถานะที่ถูกต้อง?

53 type-systems  null 

ตัวอย่างเช่นสมมติว่าฉันมีคลาสMemberซึ่งมี lastChangePasswordTime: class Member{ . . . constructor(){ this.lastChangePasswordTime=null, } } ซึ่ง lastChangePasswordTime อาจไม่มีความหมายเนื่องจากสมาชิกบางคนอาจไม่เปลี่ยนรหัสผ่าน แต่ถ้าหาก nulls เป็นสิ่งชั่วร้ายสิ่งที่ควรใช้เมื่อค่าสามารถขาดความหมายได้อย่างไร และhttps://softwareengineering.stackexchange.com/a/12836/248528ฉันไม่ควรใช้ null เพื่อแสดงค่าขาดหายไปอย่างมีความหมาย ดังนั้นฉันพยายามเพิ่มธงบูลีน: class Member{ . . . constructor(){ this.isPasswordChanged=false, this.lastChangePasswordTime=null, } } แต่ฉันคิดว่ามันค่อนข้างล้าสมัยเพราะ: เมื่อ isPasswordChanged เป็นเท็จ lastChangePasswordTime จะต้องเป็นโมฆะและการตรวจสอบ lastChangePasswordTime == null เกือบจะเหมือนกันกับการตรวจสอบ isPasswordChanged เป็นเท็จดังนั้นฉันชอบเช็ค lastChangePasswordTime == null โดยตรง เมื่อเปลี่ยนลอจิกที่นี่ฉันอาจลืมอัปเดตทั้งสองฟิลด์ หมายเหตุ: เมื่อผู้ใช้เปลี่ยนรหัสผ่านฉันจะบันทึกเวลาเช่นนี้: …

39 null  boolean 

ฉันต้องการเรียนรู้เกี่ยวกับค่า Null หรือการอ้างอิง Null ตัวอย่างเช่นฉันมีคลาสที่เรียกว่า Apple และฉันสร้างอินสแตนซ์ของมัน Apple myApple = new Apple("yummy"); // The data is stored in memory จากนั้นฉันกินแอปเปิ้ลนั้นและตอนนี้มันต้องเป็นโมฆะดังนั้นฉันตั้งมันเป็นโมฆะ myApple = null; หลังจากสายนี้ฉันลืมว่าฉันกินมันและตอนนี้ต้องการตรวจสอบ bool isEaten = (myApple == null); ด้วยการโทรนี้การอ้างอิง myApple อยู่ที่ไหน เป็นค่าตัวชี้พิเศษหรือไม่ ถ้าเป็นเช่นนั้นถ้าฉันมีวัตถุ 1,000 NULL พวกเขาครอบครองพื้นที่หน่วยความจำวัตถุ 1,000 หรือ 1,000 พื้นที่หน่วยความจำ int ถ้าเราคิดว่าประเภทตัวชี้เป็น int?

39 memory  null 

เรากำลังเปิดตัวระบบและบางครั้งเราได้รับข้อยกเว้นที่มีชื่อเสียงพร้อมกับข้อความNullReferenceExceptionObject reference not set to an instance of an object อย่างไรก็ตามในวิธีการที่เรามีวัตถุเกือบ 20 ชิ้นการมีบันทึกซึ่งบอกว่าวัตถุนั้นเป็นโมฆะนั้นไม่มีประโยชน์เลย มันเหมือนกับบอกคุณว่าเมื่อคุณเป็นตัวแทนความปลอดภัยของการสัมมนาคนหนึ่งใน 100 คนเป็นผู้ก่อการร้าย มันไม่มีประโยชน์กับคุณเลย คุณควรได้รับข้อมูลเพิ่มเติมหากคุณต้องการตรวจสอบว่าชายคนไหนเป็นคนที่คุกคาม ในทำนองเดียวกันถ้าเราต้องการที่จะลบข้อผิดพลาดเราจำเป็นต้องรู้ว่าวัตถุใดเป็นโมฆะ ตอนนี้มีบางอย่างหมกมุ่นอยู่ในใจฉันมาหลายเดือนแล้วและนั่นก็คือ: เหตุใด. NET จึงไม่ให้ชื่อเราหรืออย่างน้อยก็ประเภทของการอ้างอิงวัตถุซึ่งเป็นโมฆะ? . ไม่เข้าใจประเภทจากการสะท้อนกลับหรือแหล่งอื่น ๆ นอกจากนี้แนวปฏิบัติที่ดีที่สุดที่จะเข้าใจว่าวัตถุใดเป็นโมฆะ? เราควรทดสอบความสามารถของวัตถุในบริบทเหล่านี้ด้วยตนเองเสมอและบันทึกผลลัพธ์หรือไม่ มีวิธีที่ดีกว่า? อัปเดต: ข้อยกเว้นThe system cannot find the file specifiedมีลักษณะเดียวกัน คุณไม่พบไฟล์ใดจนกว่าคุณจะแนบกับกระบวนการและดีบัก ฉันเดาว่าข้อยกเว้นประเภทนี้จะฉลาดขึ้น มันจะดีกว่าไหมถ้า. NET สามารถบอกเราc:\temp.txt doesn't exist.แทนข้อความทั่วไปได้? ในฐานะนักพัฒนาฉันลงคะแนนใช่

39 .net  exceptions  logging  null 

ฉันสงสัยว่าฉันควรป้องกันค่าตอบแทนการโทรด้วยวิธีการโดยตรวจสอบว่าพวกเขาตอบสนองความคาดหวังของฉันแม้ว่าฉันรู้ว่าวิธีการที่ฉันโทรจะตอบสนองความคาดหวังดังกล่าว 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()); } …

30 java  validation  null  return-type  defensive-programming 

ผมได้อ่านเกี่ยวกับ (UN) ความสะดวกสบายของการมีnullแทน Maybe(ตัวอย่าง) หลังจากที่ได้อ่านบทความนี้ , ผมเชื่อว่ามันจะดีกว่าที่จะใช้Maybe (หรือบางสิ่งบางอย่างที่คล้ายกัน) อย่างไรก็ตามฉันรู้สึกประหลาดใจที่เห็นว่าภาษาการเขียนโปรแกรมเชิงวัตถุหรือเชิงวัตถุที่มีชื่อเสียง "ยังคงใช้อยู่null(ซึ่งอนุญาตการเข้าถึงชนิดที่ไม่ถูกตรวจสอบซึ่งสามารถแสดงถึงค่า 'ไม่มีอะไร') และMaybeส่วนใหญ่จะใช้ในภาษาโปรแกรมเชิงฟังก์ชัน ตัวอย่างเช่นดูรหัส C # ต่อไปนี้: void doSomething(string username) { // Check that username is not null // Do something } มีบางอย่างมีกลิ่นไม่ดีที่นี่ ... ทำไมเราควรตรวจสอบว่าข้อโต้แย้งนั้นเป็นโมฆะหรือไม่ เราไม่ควรคิดว่าทุกตัวแปรมีการอ้างอิงไปยังวัตถุหรือไม่? อย่างที่คุณเห็นปัญหาคือว่าโดยนิยามตัวแปรเกือบทั้งหมดสามารถมีการอ้างอิงที่เป็นโมฆะ เกิดอะไรขึ้นถ้าเราสามารถตัดสินใจว่าตัวแปรใดเป็น "โมฆะ" และไม่ได้? นั่นจะช่วยเราได้มากในขณะที่ทำการดีบั๊กและมองหา "NullReferenceException" ลองจินตนาการว่าโดยค่าเริ่มต้นไม่มีประเภทอาจมีอ้างอิงโมฆะ แทนที่จะเป็นเช่นนั้นคุณจะระบุอย่างชัดเจนว่าตัวแปรสามารถมีการอ้างอิงที่เป็นโมฆะได้เฉพาะในกรณีที่คุณต้องการ นั่นคือความคิดเบื้องหลังบางที หากคุณมีฟังก์ชั่นที่ในบางกรณีล้มเหลว (ตัวอย่างเช่นการหารด้วยศูนย์) คุณสามารถส่งกลับMaybe<int>ระบุอย่างชัดเจนว่าผลลัพธ์อาจเป็น int แต่ยังไม่มีอะไร! นี่คือเหตุผลหนึ่งที่ต้องการบางทีอาจจะแทนที่จะเป็นโมฆะ …

29 programming-languages  object-oriented  language-design  null  imperative-languages 

การแสดงที่มา: สิ่งนี้เกิดจากคำถาม P.SEที่เกี่ยวข้อง พื้นหลังของฉันอยู่ใน C / C ++ แต่ฉันได้ทำงานในจำนวนที่เป็นธรรมใน Java และฉันกำลังเข้ารหัส C # เนื่องจากพื้นหลัง C ของฉันการตรวจสอบพอยน์เตอร์ที่ผ่านและส่งคืนนั้นเป็นของมือสอง แต่ฉันยอมรับว่ามันมีอคติต่อมุมมองของฉัน ฉันเพิ่งเห็นการกล่าวถึงรูปแบบวัตถุ Nullซึ่งแนวคิดก็คือวัตถุจะถูกส่งคืนเสมอ กรณีปกติส่งคืนวัตถุที่คาดหวังที่มีประชากรและกรณีข้อผิดพลาดส่งคืนวัตถุว่างเปล่าแทนตัวชี้โมฆะ สถานที่ตั้งเป็นฟังก์ชั่นการโทรจะมีวัตถุบางอย่างให้เข้าถึงและหลีกเลี่ยงการละเมิดการเข้าถึงหน่วยความจำที่เป็นโมฆะ ดังนั้นข้อดี / ข้อเสียของการตรวจสอบค่า null เมื่อเปรียบเทียบกับการใช้รูปแบบวัตถุ Null คืออะไร ฉันสามารถเห็นรหัสการโทรที่สะอาดขึ้นด้วย NOP แต่ฉันยังสามารถดูได้ว่ามันจะสร้างความล้มเหลวที่ซ่อนอยู่ที่ไม่ได้รับการยก ฉันต้องการให้แอปพลิเคชันของฉันล้มเหลวอย่างหนัก (หรือเป็นข้อยกเว้น) ในขณะที่ฉันกำลังพัฒนามันมากกว่าที่จะมีข้อผิดพลาดเงียบ ๆ หลบเข้าไปในป่า รูปแบบวัตถุ Null ไม่สามารถมีปัญหาที่คล้ายกันกับที่ไม่ทำการตรวจสอบเป็นโมฆะ? วัตถุหลายอย่างที่ฉันได้ทำงานกับวัตถุหรือภาชนะบรรจุของตัวเอง ดูเหมือนว่าฉันจะต้องมีกรณีพิเศษเพื่อรับประกันว่าภาชนะบรรจุวัตถุหลักทั้งหมดมีวัตถุเปล่าของตัวเอง ดูเหมือนว่าสิ่งนี้จะน่าเกลียดด้วยการซ้อนกันหลายชั้น

27 error-handling  null 

สมมติว่าฉันมีวิธี: public void DoSomething(ISomeInterface someObject) { if(someObject == null) throw new ArgumentNullException("someObject"); someObject.DoThisOrThat(); } ฉันได้รับการฝึกฝนให้เชื่อว่าการขว้างArgumentNullExceptionเป็น "ถูกต้อง" แต่ข้อผิดพลาด "การอ้างอิงวัตถุไม่ได้ถูกตั้งค่าเป็นอินสแตนซ์ของวัตถุ" หมายความว่าฉันมีข้อผิดพลาด ทำไม? ฉันรู้ว่าถ้าฉันแคชอ้างอิงsomeObjectและใช้ในภายหลังแล้วมันจะดีกว่าที่จะตรวจสอบความว่างเปล่าเมื่อผ่านไปและล้มเหลวก่อน อย่างไรก็ตามหากฉันอ้างถึงในบรรทัดถัดไปทำไมเราจึงควรตรวจสอบ มันจะโยนข้อยกเว้นไม่ทางใดก็ทางหนึ่ง แก้ไข : มันเพิ่งเกิดขึ้นกับฉัน ... ความกลัวของโมฆะที่ลงทะเบียนไม่ได้มาจากภาษาอย่าง C ++ ที่ไม่ได้ตรวจสอบคุณ (นั่นเป็นเพียงแค่พยายามที่จะเรียกใช้วิธีการบางอย่างที่ตำแหน่งหน่วยความจำ zero + method offset)?

27 c#  null 

นี่เป็นกฎข้อหนึ่งที่ซ้ำแล้วซ้ำอีกและทำให้ฉันงงงวย Nulls เป็นความชั่วร้ายและควรหลีกเลี่ยงเมื่อใดก็ตามที่เป็นไปได้ แต่จากความไร้เดียงสาของฉันให้ฉันกรีดร้อง - บางครั้งคุณค่าอาจหายไปอย่างมีความหมาย! โปรดให้ฉันถามสิ่งนี้ในตัวอย่างที่มาจากรหัสที่น่ากลัวที่ต่อต้านการขี่แบบนี้ฉันกำลังทำงานอยู่ในขณะนี้ นี่คือที่หลักของมันเป็นเกมที่มีผู้เล่นหลายคนทางเว็บซึ่งผู้เล่นทั้งสองวิ่งไปพร้อมกัน (เช่นในโปเกมอนและตรงข้ามกับหมากรุก) หลังจากนั้นแต่ละครั้งเซิร์ฟเวอร์จะเผยแพร่รายการของการอัปเดตรหัส JS ฝั่งไคลเอ็นต์ ชั้นอัปเดต: public class GameUpdate { public Player player; // other stuff } คลาสนี้ได้รับการต่อเนื่องเป็น JSON และส่งไปยังผู้เล่นที่เชื่อมต่อ การอัปเดตส่วนใหญ่จะมีผู้เล่นเชื่อมโยงกับพวกเขาตามปกติ - หลังจากทั้งหมดคุณจำเป็นต้องรู้ว่าผู้เล่นคนใดที่ทำในเทิร์นนี้ อย่างไรก็ตามการอัปเดตบางอย่างไม่สามารถเชื่อมโยง Player ได้อย่างมีความหมาย ตัวอย่าง: เกมถูกบังคับเนื่องจากมีการ จำกัด การเลี้ยวโดยไม่มีการกระทำเกิน สำหรับการอัปเดตดังกล่าวฉันคิดว่ามันมีความหมายที่จะให้ผู้เล่นเป็นโมฆะ แน่นอนฉันสามารถ "แก้ไข" รหัสนี้โดยใช้การสืบทอด: public class GameUpdate { // stuff } public class …

26 anti-patterns  null