2017-08-01 23 views
12

Sự khác biệt giữa việc sử dụng List<Map<String, String>> so với List<Object> về mặt sử dụng và hiệu suất là gì. Giả sử tôi phải tạo danh sách bản đồ chỉ có 3 loại cặp giá trị khóa, thay vào đó tôi có thể tạo đối tượng chỉ có 3 thuộc tính và tạo danh sách đối tượng.Danh sách <Bản đồ <Chuỗi, Chuỗi >> so với Danh sách <Object>

Câu hỏi ở đây nằm ngoài hai cách tiếp cận mà bạn nên sử dụng trong trường hợp nào?

+0

Tại sao câu hỏi được mở lại? Nó vẫn dựa trên ý kiến. –

+0

@MuratK. Người ta có thể xem xét sự khác biệt về mục tiêu (tức là không dựa trên ý kiến) về cú pháp và hiệu suất khi được sử dụng cho các kịch bản khác nhau. Nhưng toàn bộ "cái nào tôi nên sử dụng" có xu hướng hướng tới thực hành tốt nhất dựa trên ý kiến ​​và có lẽ sẽ phù hợp hơn với [softwareengineering.se]. Có vẻ như nó có thể đi theo một trong hai cách. – Dukeling

Trả lời

26

Cho phép đầu tiên làm rõ những gì chúng ta đang nói về: nó là

List<Map<String, String>> 

so

List<Foo> 

nơi đối tượng Foo có một số "tài sản", điều đó sẽ được lưu trữ trong một bản đồ (như cặp giá trị khóa) với tùy chọn một.

Trong trường hợp đó, bạn hoàn toàn chọn tùy chọn hai. Đơn giản chỉ vì OOP tốt là tạo ra các tóm tắt hữu ích , còn gọi là mô hình. Có nghĩa là: khi bạn có các thuộc tính mà thuộc về nhau, thì việc sử dụng một lớp để bao quanh chúng là cách tự nhiên để thực hiện.

Điều đó mang đến cho bạn lợi thế nhỏ về hiệu suất (vì bạn tránh truy cập bản đồ), nhưng điều cốt lõi là: nó cho phép bạn viết thời gian biên dịch mã đã kiểm tra. Bạn thấy:

int foo = list.get(0).map.get("key"); 

có thể thất bại tại runtime - bạn không biết nếu bản đồ chứa chìa khóa đó, và nếu đó là một Integer.

Nhưng

int foo = list.get(0).getFoo(); // resp. ...get(0).fieldName 

thể được kiểm tra bởi trình biên dịch! (Vâng, những get() cuộc gọi vẫn có thể thất bại trong thời gian chạy, nhưng đó là một cái gì đó bạn không nhận được xung quanh anyway)

Ngoài ra: không lo lắng về hiệu suất trên mức này: trước hết, bạn phải hiểu những gì thực sự ảnh hưởng đến hiệu suất của bạn khi viết mã Java. Bởi vì bạn hoàn toàn muốn tránh điều đó "mã này là xấu xí nhưng có thể cho hiệu suất tốt hơn" suy nghĩ lẻn vào thiết kế của bạn. Tập trung vào viết mã sạch sẽ thực hiện công việc theo cách thẳng tiến. Làm không bao giờ viết ít biểu cảm hơn vì bạn giả sử tốc độ nhanh hơn. Khi bạn gặp sự cố về hiệu suất - hãy lập hồ sơ cho mã của bạn, xác định nguyên nhân gốc và sửa lỗi đó.

Nhưng không cho phép suy nghĩ tối ưu hóa sớm ảnh hưởng đến chất lượng mã của bạn.

+0

một chút để bắt đầu một ngày! – davidxxx

4

cung cấp lớp học của bạn trông giống như sau:

class Foo 
{ 
    private final String a; 
    private final String b; 
    private final String c; 

    // constructor and getters 
} 

Sử dụng một List<Foo> sẽ cho kết quả:

Hiệu suất Hiệu suất

của việc sử dụng một lớp có khả năng rất giống với một bản đồ. Hầu hết các bản đồ triển khai bản đồ, ví dụ: HashMap, cung cấp O (1) nhận đượcđặt hoạt động. Nó sẽ không chậm hơn đáng kể so với việc gọi một phương thức getter cho đối tượng của bạn.

Cách sử dụng, nếu "chìa khóa" 3 là luôn luôn giống nhau:

Lớp có thể dễ dàng hơn để sử dụng. Nếu bạn có Map<String, String> thì không có cách nào dễ dàng để thực thi rằng mỗi bản đồ chứa chính xác 3 khóa "A", "B" và "C". Điều gì sẽ xảy ra nếu ai đó thêm khóa "D"? Điều gì sẽ xảy ra nếu ai đó xóa khóa A?

Với một lớp tùy chỉnh, điều này dễ thực thi thông qua hàm tạo - kiểm tra thời gian biên dịch.

Cách sử dụng, nếu "chìa khóa" 3 không giống nhau:

Nếu không có nhiều lớp học, và có thể một số loại hệ thống phân cấp lớp, bạn không thể dễ dàng thực hiện điều này. Bản đồ có lẽ tốt hơn.

Các vấn đề liên quan