Tại sao HashMap nên được sử dụng (trong các hàm) để xác định giá trị nào sẽ trả về (cho khóa) khi một cấu trúc khác có thể thực hiện công việc trong thời gian tốt hơn?

Trong khi gần đây tôi làm việc tại một công ty lớn, tôi nhận thấy rằng các lập trình viên ở đó theo phong cách mã hóa này:

Giả sử tôi có hàm trả về 12 nếu đầu vào là A, 21 nếu đầu vào là B và 45 nếu đầu vào là C.

Vì vậy, tôi có thể viết chữ ký hàm là:

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

Nhưng khi xem lại mã, tôi được yêu cầu thay đổi chức năng như sau:

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

Tôi không thể thuyết phục bản thân tại sao mã thứ hai tốt hơn mã thứ nhất. Mã thứ hai chắc chắn sẽ mất nhiều thời gian hơn để chạy.

Lý do duy nhất để sử dụng mã thứ hai có thể là nó cung cấp khả năng đọc tốt hơn. Nhưng nếu chức năng này được gọi nhiều lần thì chức năng thứ hai có làm chậm thời gian chạy của tiện ích gọi nó không?

Bạn nghĩ gì về điều này?

Vấn đề là di chuyển việc tạo ra hashmap bên ngoài hàm và thực hiện nó một lần (hoặc chỉ ít lần hơn so với cách khác).

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

Tuy nhiên java kể từ khi java7 có thể có các chuỗi (cuối cùng) trong các khóa:

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

Trong ví dụ thứ hai của bạn, Mapnên là một thành viên tĩnh riêng để tránh chi phí khởi tạo dự phòng.

Đối với số lượng lớn các giá trị, bản đồ sẽ hoạt động tốt hơn. Sử dụng hashtable, người ta có thể tra cứu câu trả lời trong thời gian không đổi. Cấu trúc nhiều-if phải so sánh đầu vào với từng khả năng cho đến khi tìm thấy câu trả lời đúng.

Nói cách khác, tra cứu bản đồ là O (1) trong khi ifs là O (n) trong đó n là số lượng đầu vào có thể.

Tạo bản đồ là O (n), nhưng chỉ được thực hiện một lần nếu nó ở trạng thái không đổi tĩnh. Đối với việc tra cứu được thực hiện thường xuyên, bản đồ sẽ vượt trội hơn các ifcâu lệnh trong thời gian dài, với chi phí hơi nhiều thời gian hơn khi chương trình khởi động (hoặc lớp được tải, tùy thuộc vào ngôn ngữ).

Điều đó đang được nói, bản đồ không phải lúc nào cũng là công cụ phù hợp cho công việc này. Thật tuyệt khi có nhiều giá trị hoặc các giá trị phải được cấu hình thông qua tệp văn bản, đầu vào của người dùng hoặc cơ sở dữ liệu (trong trường hợp đó bản đồ đóng vai trò là bộ đệm).

Có hai tốc độ trong phần mềm: thời gian cần để viết / đọc / gỡ lỗi mã; và thời gian cần thiết để thực thi mã.

Nếu bạn có thể thuyết phục tôi (và những người đánh giá mã của bạn) rằng hàm hashmap thực sự chậm hơn if / then / other (sau khi tái cấu trúc để tạo một hashmap tĩnh) VÀ bạn có thể thuyết phục tôi / người đánh giá rằng nó được gọi là đủ thời gian để thực hiện khác biệt, sau đó tiếp tục và thay thế hashmap bằng if / other.

Mặt khác, mã hashmap có thể đọc được; và (có lẽ) không có lỗi; bạn có thể xác định điều đó một cách nhanh chóng chỉ bằng cách nhìn vào nó. Bạn thực sự không thể nói điều tương tự về if / other mà không thực sự nghiên cứu nó; sự khác biệt thậm chí còn phóng đại hơn khi có hàng trăm lựa chọn.

Tôi rất thích câu trả lời kiểu HashMap.

Có một số liệu cho điều này

Có một số liệu chất lượng mã được gọi là Độ phức tạp Cyclomatic . Số liệu này về cơ bản đếm số lượng đường dẫn khác nhau thông qua mã ( cách tính Độ phức tạp theo chu kỳ ).

Đối với mọi đường dẫn thực thi có thể, một phương thức trở nên khó hơn và khó hơn để vừa hiểu VÀ kiểm tra đầy đủ tính chính xác.

Nó tập trung vào thực tế là "kiểm soát từ khóa" như: ifs, elses, whiles, v.v ... tận dụng các bài kiểm tra boolean có thể sai. Việc sử dụng lặp lại "từ khóa kiểm soát" tạo ra mã dễ vỡ.

Lợi ích kèm theo

Ngoài ra, "cách tiếp cận dựa trên bản đồ" khuyến khích các nhà phát triển nghĩ về các cặp đầu vào-đầu ra như một bộ dữ liệu có thể được trích xuất, tái sử dụng, thao tác trong thời gian chạy, kiểm tra và xác minh. Ví dụ: bên dưới tôi viết lại "foo" để chúng tôi không bị khóa vĩnh viễn vào "A-> 12, B-> 21, C-> 45":

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

rachet_freak đề cập đến loại tái cấu trúc này trong câu trả lời của anh ta, anh ta lập luận về tốc độ và tái sử dụng, tôi đang tranh luận về tính linh hoạt của thời gian chạy (mặc dù sử dụng một bộ sưu tập bất biến có thể có lợi ích to lớn tùy thuộc vào tình huống)

Dữ liệu tốt hơn mã. Ít nhất là vì quá hấp dẫn để thêm một nhánh khác vào mã, nhưng việc thêm một hàng vào bảng rất khó để hiểu sai. Câu hỏi này là một ví dụ nhỏ về điều này. Bạn đang viết một bảng tra cứu. Hoặc viết một triển khai, hoàn thành với logic và tài liệu có điều kiện, hoặc viết bảng ra sau đó tra cứu trong đó.

Một bảng dữ liệu luôn là một đại diện tốt hơn của một số dữ liệu so với mã, tối ưu hóa modulo. Bảng khó diễn đạt như thế nào có thể phụ thuộc vào ngôn ngữ - Tôi không biết Java, nhưng hy vọng nó có thể thực hiện bảng tra cứu đơn giản hơn ví dụ trong OP.

Đây là một bảng tra cứu trong python. Nếu điều này được xem là mời xung đột, vui lòng xem xét rằng câu hỏi không được gắn thẻ java, việc tái cấu trúc là bất khả tri về ngôn ngữ và hầu hết mọi người không biết java.

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

Ý tưởng tái cấu trúc mã để giảm thời gian chạy có giá trị, nhưng tôi muốn sử dụng một trình biên dịch nâng thiết lập chung hơn là tự mình làm.