2012-10-02 36 views
12

Bài đăng này chỉ thảo luận về scala.collection.mutable.LinkedList. Các triển khai khác không phải là chủ đề của chủ đề này.Trường hợp sử dụng cho LinkedList

Câu hỏi của tôi là: trường hợp sử dụng của lớp học này là gì? Tôi thấy nó có các vấn đề của cả hai loại cấu trúc có thể thay đổi và bất biến trong khi mang lại lợi ích cho không. Tôi nói như vậy vì:

  • API vẻ với tôi như thể nó là một API bất biến (filter, map, drop, take vv tất cả trở lại một mới LinkedList thay vì làm thay đổi tại chỗ)
  • tất cả các lợi ích của danh sách liên kết không thay đổi, ít nhất tôi đoán, không có mặt, tức là chia sẻ tối đa giữa các cấu trúc, bởi vì đó là vẫn có thể thay đổi (thông qua var elemvar next.

vì vậy, về cơ bản chúng ta có một thời gian truy cập tuyến tính, ap tuyến tính pend thời gian, không gian tuyến tính vv và không có gì để hiển thị cho nó trong không gian phức tạp hoặc trong khả năng lý do về mã (ngoại trừ có thể là O (1) prepend nhưng nó vẫn là trường hợp với danh sách bất biến).

Tôi không thấy lợi ích quan trọng của loại cấu trúc này? Tôi đang tìm kiếm các biện pháp khách quan và/hoặc trường hợp sử dụng có thể áp dụng cho lớp học này.

+1

Trông giống như một bao bọc mỏng xung quanh lớp không thay đổi. Lợi ích: ai đã viết nó đã có thể làm điều đó rất nhanh chóng, mà không lo lắng về việc giới thiệu lỗi? – bdares

+4

@bdares điều gì khiến bạn nghĩ vậy? Tôi đã có một cái nhìn nhanh về nguồn và nó dường như không có thứ gì như vậy. –

+0

hmmm ... giống như bất kỳ loại có thể thay đổi nào, nó có thể được tham chiếu từ một vài con trỏ và sau khi được chỉnh sửa, những thay đổi sẽ được nhìn thấy từ tất cả các con trỏ. Điều này không liên quan gì đến thời gian phức tạp. – Oren

Trả lời

4

Tôi muốn nói lý do phức tạp - lớp danh sách được liên kết cho phép bạn giữ tham chiếu đến nút ở giữa danh sách và sử dụng insert hoặc update tại nút đó thay vì đi qua phần đầu của danh sách.

[] --> [] --> ... --> [] --> ... --> [] --| 
^     ^
head     myReference 

Trong một ứng dụng mà tôi biết chính xác nơi một sự thay đổi trong một số trình tự sẽ xảy ra (myReference ở trên), chi phí ít hơn nhiều để thay đổi vị trí đó vì sao chép tất cả mọi thứ lên đến vị trí đó như sẽ là trường hợp với immutable.List (tức là tôi chỉ chèn một nút mới sau myReference).

       myNewNode 
          v 
[] --> [] --> ... --> [] --> [] ---> ... --> [] --| 
^     ^
head     myReference 

Ví dụ về ứng dụng như vậy - L-system nơi bạn mở rộng các phần của chuỗi. Nó rẻ hơn nhiều để chèn các nút mới tại chỗ, hơn là sao chép toàn bộ chuỗi mỗi khi nó cần được mở rộng.

Lý do khác là đầy đủ - kể từ DoubleLinkedListLinkedListLike chia sẻ nhiều cơ sở hạ tầng chung, cung cấp thêm một lớp học là chi phí thấp cho kích thước thư viện chuẩn.

+0

lý do đủ tốt. Mặc dù tôi tự hỏi, liệu có lý do đặc biệt nào không có sự triển khai cho các thành ngữ tại chỗ như bản đồ, bộ lọc, vv? – m09

+0

Đã có rất nhiều cuộc thảo luận về điều này.Điều này một phần là vì nhiều người không thể thực hiện dễ dàng hoặc ở tất cả (tại chỗ 'bộ lọc' trên một' Mảng' hoặc 'bản vá', hoặc thậm chí là' sơ đồ phẳng '!), Một phần do lý do hiệu suất (tin hay không) , bản cập nhật tại chỗ không phải lúc nào cũng nhanh hơn bản cập nhật) và phần nào do vấn đề đặt tên. Tuy nhiên, có một hoạt động có thể thực hiện chung trên các chuỗi có thể thay đổi được, và đó là 'biến đổi' - mà chỉ đơn giản gọi là' update' trên mọi phần tử. – axel22

+0

nó có ý nghĩa với tôi, nhưng tôi vẫn tự hỏi tại sao hầu hết các đặc điểm chung mà những triển khai đó có thể được để trống. Tôi đoán dù sao họ không quá khó để thực hiện và giảm tiếng ồn trong API là thích hợp hơn cho việc thực hiện đã được thực hiện. Cảm ơn :) – m09

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