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

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

53 immutability  semantics  collections  mutable 

สมมติว่าฉันมีกระแสของสิ่งต่าง ๆ และฉันต้องการ "เพิ่มคุณค่า" พวกเขาให้อยู่กลางกระแสฉันสามารถใช้peek()ทำสิ่งนี้ได้เช่น: streamOfThings.peek(this::thingMutator).forEach(this::someConsumer); สมมติว่าการกลายพันธุ์สิ่งต่าง ๆ ณ จุดนี้ในรหัสเป็นการทำงานที่ถูกต้องตัวอย่างเช่นthingMutatorวิธีการอาจตั้งค่าฟิลด์ "lastProcessed" เป็นเวลาปัจจุบัน อย่างไรก็ตามpeek()ในบริบทส่วนใหญ่หมายถึง "มอง แต่ไม่ได้สัมผัส" ใช้peek()เพื่อเปลี่ยนแปลงองค์ประกอบของกระแสข้อมูลที่เป็น antipattern หรือไม่เหมาะสมหรือไม่? แก้ไข: ทางเลือกที่ธรรมดากว่าคือการเปลี่ยนผู้บริโภค: private void thingMutator(Thing thing) { thing.setLastProcessed(System.currentTimeMillis()); } ไปที่ฟังก์ชันที่คืนค่าพารามิเตอร์: private Thing thingMutator(Thing thing) { thing.setLastProcessed(currentTimeMillis()); return thing; } และใช้map()แทน: stream.map(this::thingMutator)... แต่ที่แนะนำรหัสลวก ๆ (คนreturn) และฉันไม่ได้เชื่อว่ามันเป็นที่ชัดเจนเพราะคุณรู้ว่าpeek()ผลตอบแทนที่วัตถุเดียวกัน แต่map()มันไม่ได้ล้างได้อย่างรวดเร็วว่ามันเป็นเดียวกันระดับของวัตถุ นอกจากนี้peek()คุณยังสามารถมีแลมบ์ดาที่กลายพันธุ์ได้ แต่map()คุณต้องสร้างซากรถไฟ เปรียบเทียบ: stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...) …

36 java  anti-patterns  java8  stream-processing  mutable