Bir if yapısı bir işi daha iyi bir zamanda yapabiliyorsa, neden bir anahtar için döndürülecek değeri (bir anahtar için) belirlemek için bir HashMap kullanılmalıdır (işlevlerde)?

Geçenlerde büyük bir şirkette çalışırken, oradaki programcıların bu kodlama stilini takip ettiklerini fark ettim:

Giriş A ise 12, giriş B ise 21 ve giriş C ise 45 döndüren bir fonksiyonum olduğunu varsayalım.

Böylece fonksiyon imzasını şöyle yazabilirim:

int foo(String s){
    if(s.equals("A"))      return 12;
    else if(s.equals("B")) return 21;
    else if(s.equals("C")) return 45;
    else throw new RuntimeException("Invalid input to function foo");
}

Ancak kod incelemesinde, fonksiyonu aşağıdaki şekilde değiştirmem istendi:

int foo(String s){
    HashMap<String, Integer> map = new HashMap<String, Integer>();
    map.put("A", 12);
    map.put("B", 21);
    map.put("C", 45);
    return map.get(s);
}

İkinci kodun neden ilk koddan daha iyi olduğuna kendimi ikna edemiyorum. İkinci kodun çalışması daha fazla zaman alacaktır.

İkinci kodu kullanmanın tek nedeni, daha iyi okunabilirlik sunması olabilir. Ancak işlev birçok kez çağrılıyorsa, ikinci işlev, çağıran yardımcı programın çalışma süresini yavaşlatmaz mı?

Bunun hakkında ne düşünüyorsun?

Mesele, hashmap oluşumunu fonksiyonun dışına taşımak ve bir kez (ya da başka türlü olduğundan daha az kez) yapmaktır.

private static final Map<String, Integer> map;
static{
    Map<String, Integer> temp = new HashMap<String, Integer>();
    temp.put("A", 12);
    temp.put("B", 21);
    temp.put("C", 45);
    map = Collections.unmodifiableMap(temp);//make immutable
}

int foo(String s){
    if(!map.containsKey(s))
        throw new RuntimeException("Invalid input to function foo");

    return map.get(s);
}

Ancak java7'den bu yana anahtarlarda (son) dizeler elde edebildi:

int foo(String s){
    switch(s){
    case "A":
        return 12;
    case "B": 
        return 21;
    case "C": 
        return 45;
    default: throw new RuntimeException("Invalid input to function foo");
}

İkinci örneğinizde, Mapgereksiz başlatma ek yükünü önlemek için bu özel statik üye olmalıdır.

Büyük miktarlarda değerler için harita daha iyi performans gösterir. Bir hashtable kullanarak, yanıt sürekli olarak aranabilir. Birden fazla if yapısı doğru cevabı bulana kadar girdiyi olasılıkların her biri ile karşılaştırmalıdır.

Başka bir deyişle, harita arama O (1) iken, ifs O (n) 'dir, burada n olası girişlerin sayısıdır.

Harita oluşturma O (n) 'dir, ancak statik sabit durum ise yalnızca bir kez yapılır. Sık sık yapılan bir arama için, harita if, program başlarken (veya dile bağlı olarak sınıf yüklenir) biraz daha fazla zaman harcayarak, uzun vadede ifadelerden daha iyi performans gösterecektir .

Bununla birlikte, harita bu iş için her zaman doğru araç değildir . Çok fazla değer olduğunda veya değerlerin bir metin dosyası, kullanıcı girişi veya veritabanı üzerinden yapılandırılabilmesi gerekir (bu durumda harita önbellek görevi görür).

Yazılımda iki hız vardır: kodu yazmak / okumak / hata ayıklamak için geçen süre; ve kodun yürütülmesi için geçen süre.

Beni (ve kod gözden geçirenlerinizi) hashmap işlevinin gerçekten if / then / else'dan daha yavaş olduğuna ikna ederseniz (statik bir hashmap yapmak için yeniden düzenleme yaptıktan sonra) VE beni / gözden geçirenleri, sonra devam edin ve hashmap'i if / else ile değiştirin.

Aksi takdirde, hashmap kodu büyük ölçüde okunabilir; ve (muhtemelen) bugfree; bunu sadece ona bakarak hızlıca belirleyebilirsiniz. Eğer gerçekten çalışmadan if / else hakkında aynı şeyi söyleyemezsiniz; yüzlerce seçenek olduğunda fark daha da abartılıyor.

HashMap tarzı cevabı çok tercih ederim.

Bunun için bir ölçüm var

Siklomatik Karmaşıklık adı verilen bir kod kalitesi metriği vardır . Bu metrik temel olarak koddaki farklı yolların sayısını sayar ( Siklomatik Karmaşıklık nasıl hesaplanır ).

Her olası yürütme yolu için, bir yöntemin hem doğruluğunu anlamak hem de tamamen test etmek zorlaşır.

Bu, "anahtar kelimeleri kontrol etme" gibi: ifs, elses, whiles, vs. yanlış olabilir boolean testlerinden yararlanır. "Anahtar kelimeleri denetlemek" in tekrar tekrar kullanılması kırılgan kod üretir.

Ek yararlar

Ayrıca, "harita tabanlı yaklaşım", geliştiricileri girdi-çıktı çiftlerini, çalışma zamanında çıkarılabilen, yeniden kullanılabilen, değiştirilebilen, test edilebilen ve doğrulanabilen bir veri kümesi olarak düşünmeye teşvik eder. Örneğin, aşağıda "fo-" ifadesini yeniden yazdım, böylece "A-> 12, B-> 21, C-> 45" e kalıcı olarak kilitlenmeyelim:

int foo(String s){
    HashMap<String, Integer> map = getCurrentMapping();
    return map.get(s);
}

rachet_freak cevabında bu tür bir refactordan bahsediyor, hız ve yeniden kullanım için tartışıyor, çalışma zamanı esnekliği için tartışıyorum (değişmez bir koleksiyon kullanmak duruma bağlı olarak büyük faydalar sağlayabilir)

Veriler koddan daha iyidir. En azından kod için başka bir dal eklemek çok cazip gelse de, bir tabloya satır eklemek yanlış yapmak zordur. Bu soru bunun küçük bir örneğidir. Bir arama tablosu yazıyorsunuz. Koşullu mantık ve dokümantasyonla tamamlanmış bir uygulama yazın veya tabloyu yazın ve içine bakın.

Bir veri tablosu her zaman bazı verilerin koddan daha iyi bir temsilidir, modulo optimizasyonu geçer. Tablonun ifade edilmesinin ne kadar zor olduğu dile bağlı olabilir - Java bilmiyorum, ancak OP'deki örnekten daha basit bir arama tablosu uygulayabileceğini umuyoruz.

Bu, python'da bir arama tablosu. Bu davetkar bir çatışma olarak görülüyorsa, lütfen sorunun java olarak etiketlenmediğini, yeniden düzenleme dilinin agnostik olduğunu ve çoğu insanın java bilmediğini düşünün.

def foo(s):
    return {
               "A" : 12,
               "B" : 21,
               "C" : 45,
           }[s]

Çalışma zamanını azaltmak için kodu yeniden yapılandırma fikri haklıdır, ancak daha çok ortak kurulumu kaldıran bir derleyici kullanmak istiyorum.