Bir ImmutableMap veya bir Harita döndürmek daha mı iyi?

Diyelim ki Harita döndürmesi gereken bir yöntem yazıyorum . Örneğin:

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

Bir süre düşündükten sonra, bu haritayı oluşturulduktan sonra değiştirmek için hiçbir neden olmadığına karar verdim. Bu nedenle, bir ImmutableMap döndürmek istiyorum .

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

Dönüş türünü genel bir Harita olarak bırakmalı mıyım yoksa bir ImmutableMap döndürdüğümü belirtmeli miyim?

Bir taraftan, arayüzlerin tam olarak neden yaratıldığı; uygulama ayrıntılarını gizlemek için.
Öte yandan, bunu böyle bırakırsam, diğer geliştiriciler bu nesnenin değişmez olduğu gerçeğini gözden kaçırabilir. Böylece, değişmez nesneler gibi büyük bir hedefe ulaşamayacağım; değişebilecek nesnelerin sayısını en aza indirerek kodu daha net hale getirmek için. Daha da kötüsü, bir süre sonra birisi bu nesneyi değiştirmeye çalışabilir ve bu bir çalışma zamanı hatasıyla sonuçlanır (Derleyici bu konuda uyarmaz).

• Halka açık bir API yazıyorsanız ve bu değişmezlik tasarımınızın önemli bir yönü ise, ya yöntemin adının döndürülen haritanın değişmez olacağını açıkça belirtmesini sağlayarak ya da somut türden harita. Javadoc'ta bundan bahsetmek bence yeterli değil.

  Görünüşe göre Guava uygulamasını kullandığınız için, dokümana baktım ve bu soyut bir sınıf, bu yüzden size gerçek, somut tipte biraz esneklik sağlıyor.

• Dahili bir araç / kitaplık yazıyorsanız, düz bir düzenin döndürülmesi çok daha kabul edilebilir hale gelir Map. İnsanlar aradıkları kodun iç kısımlarını bilecek veya en azından ona kolayca erişebilecekler.

Benim sonucum, açıkça iyidir, işleri şansa bırakmayın.

Sen olmalıdır ImmutableMapiade türü olarak. Mapuygulanması tarafından desteklenmeyen yöntemleri içeren ImmutableMap(örneğin put) ve işaretlenmiştir @deprecatediçinde ImmutableMap.

Kullanımdan kaldırılmış yöntemleri kullanmak, derleyici uyarısına neden olur ve çoğu IDE, insanlar kullanımdan kaldırılmış yöntemleri kullanmaya çalıştığında uyarır.

Bu gelişmiş uyarı, bir şeylerin yanlış olduğuna dair ilk ipucunuz olarak çalışma zamanı istisnalarına sahip olmaya tercih edilir.

Öte yandan, bunu böyle bırakırsam, diğer geliştiriciler bu nesnenin değişmez olduğu gerçeğini gözden kaçırabilir.

Bunu javadocs'ta belirtmelisiniz. Geliştiriciler onları okur, bilirsiniz.

Böylece, değişmez nesneler gibi büyük bir hedefe ulaşamayacağım; değişebilecek nesnelerin sayısını en aza indirerek kodu daha net hale getirmek için. Daha da kötüsü, bir süre sonra birisi bu nesneyi değiştirmeye çalışabilir ve bu bir çalışma zamanı hatasıyla sonuçlanır (Derleyici bu konuda uyarmaz).

Hiçbir geliştirici test edilmemiş kodunu yayınlamaz. Ve test ettiğinde, sadece sebebini değil, aynı zamanda değişmez bir haritaya yazmaya çalıştığı dosyayı ve satırı da gördüğü yerde bir İstisna atılır.

Ancak, Mapiçerdiği nesnelerin değil , yalnızca kendisinin değişmez olacağını unutmayın .

Bunu böyle bırakırsam, diğer geliştiriciler bu nesnenin değişmez olduğu gerçeğini gözden kaçırabilir

Bu doğru, ancak diğer geliştiriciler kodlarını test etmeli ve kapsandığından emin olmalıdır.

Yine de bunu çözmek için 2 seçeneğiniz daha var:

• Javadoc kullanın

  @return a immutable map
  

• Açıklayıcı bir yöntem adı seçin

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

  Somut bir kullanım örneği için, yöntemleri daha iyi adlandırabilirsiniz. Örneğin

  public Map<String, Integer> getUnmodifiableCountByWords()
  

Başka ne yapabilirim?!

Bir iade edebilirsiniz

• kopya

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

  Bu yaklaşım, çok sayıda istemcinin haritayı değiştirmesini bekliyorsanız ve harita yalnızca birkaç girdi içerdiği sürece kullanılmalıdır.

• CopyOnWriteMap

  yazma koleksiyonlarına kopyala genellikle
  eşzamanlılıkla uğraşmanız gerektiğinde kullanılır. Ancak, bir CopyOnWriteMap değişken bir işlemde dahili veri yapısının bir kopyasını oluşturduğundan (örneğin ekle, kaldır) bu konsept size de yardımcı olacaktır.

  Bu durumda, haritanızın etrafında, mutatif işlemler dışında, tüm yöntem çağrılarını temeldeki haritaya delege eden ince bir sarmalayıcıya ihtiyacınız vardır. Değişken bir işlem başlatılırsa, temel alınan haritanın bir kopyasını oluşturur ve diğer tüm çağrılar bu kopyaya devredilecektir.

  Bazı istemcilerin haritayı değiştirmesini bekliyorsanız bu yaklaşım kullanılmalıdır.

  Ne yazık ki java'da böyle bir CopyOnWriteMap. Ancak üçüncü bir taraf bulabilir veya kendiniz uygulayabilirsiniz.

Sonunda haritanızdaki öğelerin hala değiştirilebilir olabileceğini aklınızda bulundurmalısınız.

Kesinlikle bir ImmutableMap döndürün, gerekçelendirme:

• Yöntem imzası (dönüş türü dahil) kendi kendini belgeleyen olmalıdır. Yorumlar müşteri hizmetleri gibidir: Müşterilerinizin onlara güvenmesi gerekiyorsa, birincil ürününüz kusurludur.
• Bir şeyin bir arabirim mi yoksa bir sınıf mı olduğu, yalnızca onu genişletirken veya uygularken önemlidir. Bir örnek (nesne) verildiğinde, zaman istemci kodunun% 99'u bir şeyin arabirim mi yoksa sınıf mı olduğunu bilmeyecek veya umursamayacaktır. İlk başta ImmutableMap'in bir arayüz olduğunu varsaydım. Ancak bağlantıya tıkladıktan sonra bunun bir sınıf olduğunu anladım.

Sınıfın kendisine bağlıdır. Guava'nın ImmutableMap, değişken bir sınıfa yönelik değişmez bir bakış açısı olması amaçlanmamıştır. Sınıfınız değişmez ise ve temelde bir yapıya sahipse ImmutableMap, dönüş türünü yapın ImmutableMap. Ancak, sınıfınız değiştirilebilirse, yapma. Eğer buna sahipseniz:

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

Guava haritayı her seferinde kopyalayacaktır. Bu yavaş. Ama internalMapzaten bir ise ImmutableMap, o zaman tamamen sorun değil.

Sınıfınızı geri ImmutableMapdönüşle sınırlamazsanız, bunun yerine şu şekilde geri dönebilirsiniz Collections.unmodifiableMap:

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

Bunun haritanın değişmez bir görünümü olduğunu unutmayın . Eğer internalMapdeğişikliklerin, bu nedenle bir kopyasını önbelleğe alınmış olacaktır Collections.unmodifiableMap(internalMap). Yine de alıcılar için tercih ederim.

Bu, soruyu tam olarak yanıtlamıyor, ancak yine de bir haritanın iade edilip edilmeyeceğini düşünmeye değer. Harita değişmez ise, sağlanacak birincil yöntem get (key) 'e dayanır:

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

Bu, API'yi çok daha sıkı hale getirir. Bir harita gerçekten gerekliyse, bu, bir giriş akışı sağlayarak API istemcisine bırakılabilir:

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

Daha sonra müşteri, ihtiyaç duyduğu şekilde kendi sabit veya değiştirilebilir haritasını oluşturabilir veya girişleri kendi haritasına ekleyebilir. Müşterinin değerin var olup olmadığını bilmesi gerekiyorsa, bunun yerine isteğe bağlı olarak döndürülebilir:

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

Değişmez Harita bir Harita türüdür. Dolayısıyla, Harita'nın dönüş türünden ayrılmak sorun değil.

Kullanıcıların döndürülen nesneyi değiştirmemesini sağlamak için yöntemin belgeleri, döndürülen nesnenin özelliklerini açıklayabilir.

Bu tartışmalı bir fikir meselesidir, ancak burada daha iyi fikir, harita sınıfı için bir arayüz kullanmaktır. Bu arayüzün açıkça değişmez olduğunu söylemesi gerekmez, ancak arayüzdeki üst sınıfın ayarlayıcı yöntemlerinden herhangi birini açığa çıkarmazsanız mesaj aynı olacaktır.

Aşağıdaki makaleye bir göz atın:

andy gibson