Có một mục đích cụ thể cho danh sách không đồng nhất?

Đến từ nền tảng C # và Java, tôi đã quen với các danh sách của mình là đồng nhất và điều đó có ý nghĩa với tôi. Khi tôi bắt đầu chọn Lisp, tôi nhận thấy rằng các danh sách có thể không đồng nhất. Khi tôi bắt đầu xoay quanh dynamictừ khóa trong C #, tôi nhận thấy rằng, kể từ C # 4.0, cũng có thể có các danh sách không đồng nhất:

List<dynamic> heterogeneousList

Câu hỏi của tôi là điểm là gì? Có vẻ như một danh sách không đồng nhất sẽ có nhiều chi phí hơn khi thực hiện xử lý và nếu bạn cần lưu trữ các loại khác nhau ở một nơi, bạn có thể cần một cấu trúc dữ liệu khác. Là sự ngây thơ của tôi nuôi dưỡng khuôn mặt xấu xí của nó hay có những lúc thực sự hữu ích khi có một danh sách không đồng nhất?

Bài viết Bộ sưu tập không đồng nhất được gõ mạnh bởi Oleg Kiselyov, Ralf Lämmel và Keean Schupke không chỉ chứa đựng một danh sách dị thể trong Haskell, mà còn là một ví dụ thúc đẩy về thời điểm, lý do và cách bạn sẽ sử dụng HLists. Cụ thể, họ đang sử dụng nó để truy cập cơ sở dữ liệu kiểm tra thời gian biên dịch an toàn kiểu. (Hãy nghĩ rằng LINQ, trên thực tế, bài báo mà họ đang tham khảo là bài báo Haskell của Erik Meijer et al dẫn đến LINQ.)

Trích dẫn từ đoạn giới thiệu của bài viết của HLists:

Dưới đây là danh sách kết thúc mở của các ví dụ điển hình yêu cầu các bộ sưu tập không đồng nhất:

• Một bảng biểu tượng được cho là lưu trữ các mục thuộc các loại khác nhau là không đồng nhất. Nó là một bản đồ hữu hạn, trong đó loại kết quả phụ thuộc vào giá trị đối số.
• Một phần tử XML được gõ không đồng nhất. Trong thực tế, các phần tử XML là các bộ sưu tập lồng nhau bị ràng buộc bởi các biểu thức chính quy và thuộc tính mơ hồ 1.
• Mỗi hàng được trả về bởi một truy vấn SQL là một bản đồ không đồng nhất từ ​​tên cột đến các ô. Kết quả của một truy vấn là một dòng đồng nhất của các hàng không đồng nhất.
• Việc thêm một hệ thống đối tượng nâng cao vào một ngôn ngữ chức năng đòi hỏi các bộ sưu tập không đồng nhất của một loại kết hợp các bản ghi mở rộng với phân nhóm và giao diện liệt kê.

Lưu ý rằng các ví dụ bạn đưa ra trong câu hỏi của bạn thực sự không phải là danh sách không đồng nhất theo nghĩa là từ này thường được sử dụng. Họ đang yếu gõ hoặc không định kiểu liệt kê. Trên thực tế, chúng thực sự là các danh sách đồng nhất , vì tất cả các yếu tố đều cùng loại: objecthoặc dynamic. Sau đó, bạn bị buộc phải thực hiện các diễn viên hoặc instanceofcác bài kiểm tra không được kiểm tra hoặc một cái gì đó tương tự, để thực sự có thể làm việc một cách có ý nghĩa với các yếu tố, khiến chúng bị gõ yếu.

Câu chuyện dài, container không đồng nhất trao đổi hiệu năng thời gian chạy cho linh hoạt. Nếu bạn muốn có một danh sách các công cụ khác mà không liên quan đến các loại công cụ cụ thể, thì sự không đồng nhất là cách tốt nhất. Lisps được gõ động đặc trưng, ​​và hầu hết mọi thứ đều là một danh sách khuyết điểm của các giá trị được đóng hộp, vì vậy, hiệu suất nhỏ được mong đợi. Trong thế giới Lisp, năng suất lập trình viên được coi là quan trọng hơn hiệu năng thời gian chạy.

Trong một ngôn ngữ được gõ động, các thùng chứa đồng nhất thực sự sẽ có một chi phí không đáng kể so với các ngôn ngữ không đồng nhất, bởi vì tất cả các yếu tố được thêm vào sẽ cần phải được kiểm tra loại.

Trực giác của bạn về việc chọn một cấu trúc dữ liệu tốt hơn là điểm chính. Nói chung, càng nhiều hợp đồng bạn có thể đặt vào mã của mình, bạn càng biết nhiều về cách thức hoạt động của nó và càng đáng tin cậy, có thể duy trì, & c. no trở nên. Tuy nhiên, đôi khi bạn thực sự muốn có một thùng chứa không đồng nhất, và bạn nên được phép có một cái nếu bạn cần nó.

Trong các ngôn ngữ chức năng (như lisp), bạn sử dụng khớp mẫu để xác định điều gì xảy ra với một thành phần cụ thể trong danh sách. Tương đương trong C # sẽ là một chuỗi các câu lệnh if ... otherif kiểm tra loại phần tử và thực hiện thao tác dựa trên đó. Không cần phải nói, khớp mẫu chức năng hiệu quả hơn so với kiểm tra kiểu thời gian chạy.

Sử dụng đa hình sẽ là một kết hợp gần hơn với khớp mẫu. Nghĩa là, có các đối tượng của danh sách khớp với một giao diện cụ thể và gọi một hàm trên giao diện đó cho từng đối tượng. Một cách khác là cung cấp một loạt các phương thức quá tải, lấy một loại đối tượng cụ thể làm tham số. Phương thức mặc định lấy Object làm tham số của nó.

public class ListVisitor
{
  public void DoSomething(IEnumerable<dynamic> list)
  {
    foreach(dynamic obj in list)
    {
       DoSomething(obj);
    }
  }

  public void DoSomething(SomeClass obj)
  {
    //do something with SomeClass
  }

  public void DoSomething(AnotherClass obj)
  {
    //do something with AnotherClass
  }

  public void DoSomething(Object obj)
  {
    //do something with everything els
  }
}

Cách tiếp cận này cung cấp một xấp xỉ để khớp mẫu Lisp. Mẫu khách truy cập (như được triển khai ở đây, là một ví dụ tuyệt vời về việc sử dụng cho các danh sách không đồng nhất). Một ví dụ khác là gửi tin nhắn trong đó, có người nghe cho một số tin nhắn trong hàng đợi ưu tiên và sử dụng chuỗi trách nhiệm, người điều phối chuyển tin nhắn và trình xử lý đầu tiên khớp với tin nhắn xử lý nó.

Mặt trái là thông báo cho tất cả những người đăng ký tin nhắn (ví dụ: mẫu Tổng hợp sự kiện thường được sử dụng để ghép lỏng ViewModels trong mẫu MVVM). Tôi sử dụng cấu trúc sau

IDictionary<Type, List<Object>>

Cách duy nhất để thêm vào từ điển là một chức năng

Register<T>(Action<T> handler)

(và đối tượng thực sự là một WeakReference cho người được truyền trong handler). Vì vậy, ở đây tôi PHẢI sử dụng Danh sách <Object> vì tại thời điểm biên dịch, tôi không biết kiểu đóng sẽ là gì. Tuy nhiên, tại Runtime tôi có thể thực thi rằng Loại đó sẽ là chìa khóa cho từ điển. Khi tôi muốn khởi động sự kiện, tôi gọi

Send<T>(T message)

và một lần nữa tôi giải quyết danh sách. Không có lợi thế nào khi sử dụng Danh sách <động> vì dù sao tôi cũng cần truyền nó. Vì vậy, như bạn thấy có những giá trị cho cả hai phương pháp. Nếu bạn định tự động gửi một đối tượng bằng cách sử dụng Phương thức nạp chồng, thì động là cách để thực hiện. Nếu bạn bị ép buộc bỏ bất kể, cũng có thể sử dụng Object.

Bạn đã đúng rằng tính không đồng nhất mang chi phí thời gian chạy, nhưng quan trọng hơn là nó làm suy yếu các đảm bảo thời gian biên dịch được cung cấp bởi bộ đánh máy. Mặc dù vậy, có một số vấn đề trong đó các giải pháp thay thế thậm chí còn tốn kém hơn.

Theo kinh nghiệm của tôi, xử lý các byte thô thông qua các tệp, ổ cắm mạng, v.v., bạn thường gặp phải các vấn đề như vậy.

Để đưa ra một ví dụ thực tế, hãy xem xét một hệ thống cho tính toán phân tán bằng cách sử dụng tương lai . Một công nhân trên một nút riêng lẻ có thể sinh ra công việc thuộc bất kỳ loại tuần tự hóa nào, mang lại một tương lai của loại đó. Đằng sau hậu trường, hệ thống sẽ gửi công việc cho một người ngang hàng, và sau đó lưu một bản ghi liên kết đơn vị công việc đó với tương lai cụ thể phải được điền vào khi câu trả lời cho công việc đó trở lại.

Những hồ sơ này có thể được lưu giữ ở đâu? Theo trực giác, những gì bạn muốn là một cái gì đó giống như một Dictionary<WorkId, Future<TValue>>, nhưng điều này giới hạn bạn chỉ quản lý một loại tương lai trong toàn bộ hệ thống. Loại phù hợp hơn là Dictionary<WorkId, Future<dynamic>>, vì công nhân có thể chuyển sang loại thích hợp khi nó buộc tương lai.

Lưu ý : Ví dụ này xuất phát từ thế giới Haskell nơi chúng ta không có phân nhóm. Tôi sẽ không ngạc nhiên nếu có một giải pháp thành ngữ hơn cho ví dụ cụ thể này trong C #, nhưng hy vọng nó vẫn mang tính minh họa.

ISTR rằng Lisp không có bất kỳ cấu trúc dữ liệu nào ngoài danh sách, vì vậy nếu bạn cần bất kỳ loại đối tượng dữ liệu tổng hợp nào, thì đó sẽ phải là một danh sách không đồng nhất. Như những người khác đã chỉ ra, chúng cũng hữu ích cho việc tuần tự hóa dữ liệu để truyền hoặc lưu trữ. Một tính năng hay là chúng cũng có kết thúc mở, vì vậy bạn có thể sử dụng chúng trong một hệ thống dựa trên sự tương tự giữa ống và bộ lọc và có các bước xử lý liên tiếp để tăng hoặc sửa dữ liệu mà không yêu cầu đối tượng dữ liệu cố định hoặc cấu trúc liên kết dòng công việc .