ส่งคืน ImmutableMap หรือ Map ดีกว่าไหม

สมมติว่าผมเขียนวิธีการที่ควรจะกลับเป็นแผนที่ ตัวอย่างเช่น:

public Map<String, Integer> foo() {
  return new HashMap<String, Integer>();
}

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

public Map<String, Integer> foo() {
  return ImmutableMap.of();
}

ฉันควรปล่อยประเภทการส่งคืนเป็นแผนที่ทั่วไปหรือฉันควรระบุว่าฉันส่งคืน ImmutableMap?

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

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

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

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

ข้อสรุปของฉันคือชัดเจนดีอย่าปล่อยให้โอกาส

คุณควรมีImmutableMapเป็นประเภทผลตอบแทนของคุณ Mapมีวิธีการที่จะไม่ได้รับการสนับสนุนโดยการดำเนินการImmutableMap(เช่นput) และมีการทำเครื่องหมายใน@deprecatedImmutableMap

การใช้เมธอดที่เลิกใช้แล้วจะส่งผลให้คอมไพเลอร์เตือน & IDE ส่วนใหญ่จะเตือนเมื่อมีคนพยายามใช้เมธอดที่เลิกใช้

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

ในทางกลับกันถ้าฉันปล่อยไว้แบบนี้นักพัฒนารายอื่นอาจพลาดข้อเท็จจริงที่ว่าวัตถุนี้ไม่เปลี่ยนรูป

คุณควรพูดถึงสิ่งนั้นใน Javadocs นักพัฒนาอ่านพวกเขาคุณก็รู้

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

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

โปรดทราบว่ามีเพียงMapตัวมันเองเท่านั้นที่จะไม่เปลี่ยนรูปไม่ใช่วัตถุที่มีอยู่

ถ้าฉันปล่อยไว้แบบนี้นักพัฒนาคนอื่นอาจพลาดข้อเท็จจริงที่ว่าวัตถุนี้ไม่เปลี่ยนรูป

นั่นเป็นเรื่องจริง แต่นักพัฒนาซอฟต์แวร์รายอื่นควรทดสอบโค้ดของตนและตรวจสอบให้แน่ใจว่าครอบคลุม

อย่างไรก็ตามคุณมีอีก 2 ทางเลือกในการแก้ปัญหานี้:

• ใช้ Javadoc

  @return a immutable map
  

• เลือกชื่อวิธีการอธิบาย

  public Map<String, Integer> getImmutableMap()
  public Map<String, Integer> getUnmodifiableEntries()
  

  สำหรับกรณีการใช้งานที่เป็นรูปธรรมคุณสามารถตั้งชื่อวิธีการให้ดีขึ้นได้ เช่น

  public Map<String, Integer> getUnmodifiableCountByWords()
  

คุณทำอะไรได้อีก?!

คุณสามารถส่งคืนไฟล์

• สำเนา

  private Map<String, Integer> myMap;
  
  public Map<String, Integer> foo() {
    return new HashMap<String, Integer>(myMap);
  }
  

  ควรใช้แนวทางนี้หากคุณคาดว่าจะมีลูกค้าจำนวนมากแก้ไขแผนที่และตราบใดที่แผนที่มีเพียงไม่กี่รายการ

• CopyOnWriteMap

  การคัดลอกในคอลเลกชันการเขียนมักจะใช้เมื่อคุณต้องจัดการกับ
  ภาวะพร้อมกัน แต่แนวคิดนี้จะช่วยคุณในสถานการณ์ของคุณด้วยเนื่องจาก CopyOnWriteMap สร้างสำเนาของโครงสร้างข้อมูลภายในในการดำเนินการที่กลายพันธุ์ (เช่นเพิ่มลบ)

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

  ควรใช้แนวทางนี้หากคุณคาดว่าลูกค้าบางรายจะแก้ไขแผนที่

  น่าเศร้าที่ java ไม่มีไฟล์CopyOnWriteMap. แต่คุณอาจพบบุคคลที่สามหรือดำเนินการด้วยตัวเอง

ในที่สุดคุณควรจำไว้ว่าองค์ประกอบในแผนที่ของคุณอาจยังคงไม่แน่นอน

ส่งคืน ImmutableMap อย่างแน่นอนเหตุผลคือ:

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

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

public ImmutableMap<String, Integer> foo() {
    return ImmutableMap.copyOf(internalMap);
}

ฝรั่งจะลอกแผนที่ทุกครั้ง ช้าจัง แต่ถ้าinternalMapเป็นแล้วImmutableMapก็ไม่เป็นไร

หากคุณไม่ จำกัด ชั้นเรียนของคุณในการกลับมาImmutableMapคุณสามารถกลับมาได้Collections.unmodifiableMapเช่นนั้น:

public Map<String, Integer> foo() {
    return Collections.unmodifiableMap(internalMap);
}

โปรดทราบว่านี่เป็นมุมมองที่ไม่เปลี่ยนรูปในแผนที่ หากการเปลี่ยนแปลงนั้นจะสำเนาแคชของinternalMap Collections.unmodifiableMap(internalMap)อย่างไรก็ตามฉันยังคงชอบมันสำหรับ getters

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

public Integer fooOf(String key) {
    return map.get(key);
}

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

public Stream<Map.Entry<String, Integer>> foos() {
    map.entrySet().stream()
}

จากนั้นไคลเอนต์สามารถสร้างแผนที่ที่ไม่เปลี่ยนรูปหรือเปลี่ยนแปลงได้ตามที่ต้องการหรือเพิ่มรายการลงในแผนที่ของตนเอง หากไคลเอ็นต์ต้องการทราบว่ามีค่าอยู่หรือไม่สามารถส่งคืนทางเลือกแทนได้:

public Optional<Integer> fooOf(String key) {
    return Optional.ofNullable(map.get(key));
}

แผนที่ไม่เปลี่ยนรูปเป็นแผนที่ประเภทหนึ่ง ดังนั้นการออกจากประเภทการส่งคืนแผนที่ก็ไม่เป็นไร

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

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

ดูบทความต่อไปนี้:

แอนดี้กิบสัน