Чому HashMap слід використовувати (у функціях), щоб визначити, яке значення повернути (для ключа), коли конструкція if if може виконати роботу в кращий час?

Поки я нещодавно працював у великій компанії, я помітив, що там програмісти дотримувалися цього стилю кодування:

Припустимо, у мене є функція, яка повертає 12, якщо вхід A, 21 якщо вхід B, і 45, якщо вхід - C.

Тож я можу записати підпис функції як:

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");
}

Але при перегляді коду мене попросили змінити функцію на наступне:

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);
}

Я не можу переконати себе, чому другий код кращий за перший. Другий код, безумовно, потребує більше часу для запуску.

Єдиною причиною використання другого коду може бути те, що він забезпечує кращу читаність. Але якщо функція отримує виклик багато разів, невже друга функція не сповільнить час роботи утиліти, яка викликає її?

Що ти думаєш про це?

Сенс полягає в тому, щоб перемістити створення хешмапу за межі функції та зробити це один раз (або лише менше разів, ніж інакше).

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);
}

Однак з того часу java7 змогла мати (остаточні) рядки в комутаторах:

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");
}

У вашому другому прикладі, Mapповинен бути приватним статичним членом, щоб уникнути надмірної ініціалізації.

За великої кількості значень карта працюватиме краще. Використовуючи хештеб, можна шукати відповідь постійно. Конструкція з декількома параметрами повинна порівняти вхід до кожної з можливостей, поки не знайде правильну відповідь.

Іншими словами, пошук на карті - O (1), тоді як ifs - O (n), де n - кількість можливих входів.

Створення карти - O (n), але робиться лише один раз, якщо воно є статичним постійним станом. При частому пошуку, карта буде перевершувати ifтвердження в довгостроковій перспективі, ціною трохи більше часу при запуску програми (або завантаження класу, залежно від мови).

Однак, карта не завжди є правильним інструментом для цієї роботи. Приємно, коли значень багато, або значення мають бути налаштовані за допомогою текстового файлу, вводу користувача чи бази даних (у цьому випадку карта виконує функції кешу).

У програмному забезпеченні дві швидкості: час, необхідний для написання / читання / налагодження коду; і час, необхідний для виконання коду.

Якщо ви можете переконати мене (і ваших рецензентів на код), що функція хешмапу дійсно повільніше, ніж if / then / else (після рефакторингу для створення статичної хешмапу) І ви можете переконати мене / рецензентів у тому, що її закликали достатньо разів, щоб зробити фактичну різниця, тоді вперед і замініть хешмап на if / else.

В іншому випадку код хешмапу легко читати; і (ймовірно) багфрі; це можна швидко визначити, просто подивившись на нього. Ви дійсно не можете сказати те саме про if / else, не вивчивши цього; різниця ще більше перебільшується, коли є сотні варіантів.

Я дуже вважаю за краще відповідь у стилі HashMap.

Для цього є показник

Існує показник якості коду під назвою Цикломатична складність . Цей показник в основному підраховує кількість різних шляхів через код ( як обчислити цикломатичну складність ).

Для кожного можливого шляху виконання метод стає важчим і складнішим для того, щоб зрозуміти І повністю перевірити на правильність.

Це зводиться до того, що "керування ключовими словами" на зразок: ifs, elses, whiles тощо ... використовує булеві тести, які можуть бути неправильними. Неодноразове використання "керуючих ключовими словами" створює крихкий код.

Додаткові переваги

Крім того, "підхід на основі карти" спонукає розробників думати про введення-виведення пар як набір даних, який можна витягувати, використовувати повторно, маніпулювати під час виконання, перевіряти та перевіряти. Наприклад, нижче я переписав "foo", щоб ми не були постійно заблоковані в "A-> 12, B-> 21, C-> 45":

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

rachet_freak згадує цей тип рефактора у своїй відповіді, він стверджує про швидкість та повторне використання, я стверджую про гнучкість виконання (хоча використання непорушної колекції може мати величезні переваги залежно від ситуації)

Дані краще, ніж код. Не в останню чергу, тому що занадто спокусливо додати ще одну гілку до коду, але додавання рядка до таблиці важко помилитися. Це питання є невеликим випадком цього. Ви пишете таблицю пошуку. Або напишіть реалізацію, доповнену умовною логікою та документацією, або запишіть таблицю, а потім знайдіть у ній пошук.

Таблиця даних завжди є кращим представленням деяких даних, ніж код, проходить оптимізація модулів. Наскільки складно виразити таблицю, може залежати мова - я не знаю Java, але сподіваюся, що вона може реалізувати таблицю пошуку просто, ніж приклад в ОП.

Це таблиця пошуку в python. Якщо це сприймається як запрошення конфлікту, врахуйте, що питання не позначено темою java, рефакторинг - це мовна агностика і що більшість людей не знає Java.

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

Ідея реструктуризації коду для скорочення часу виконання має перевагу, але я б скоріше скористався компілятором, який піднімає загальну настройку, ніж це роблю сам.