Giao diện IComparable đã lỗi thời / có hại gì không?

IComparable chỉ hoạt động một cách

Giả sử bạn có một Employeelớp học. Trong một chế độ xem, bạn muốn hiển thị tất cả được Employeessắp xếp theo tên - trong một chế độ khác, theo địa chỉ. Làm thế nào bạn sẽ đạt được điều đó? Không phải với IComparable, ít nhất là không theo bất kỳ cách thành ngữ nào.

IComparable có logic ở sai chỗ

Giao diện được sử dụng bằng cách gọi .Sort(). Trong chế độ xem hiển thị được Customersắp xếp theo tên, hoàn toàn không có mã để ngụ ý cách sắp xếp nó.
Mặt khác, Customerlớp đang giả định cách nó sẽ được sử dụng - trong trường hợp này, nó sẽ được sử dụng trong một danh sách được sắp xếp theo tên.

IComparable được sử dụng ngầm

So với các lựa chọn thay thế, rất khó để thấy logic so sánh đang được sử dụng ở đâu - hoặc nếu có. Giả sử IDE chuẩn của bạn và bắt đầu từ Customerlớp, tôi sẽ phải

1. Tìm kiếm tất cả các tham chiếu đến Customer
2. Tìm những tài liệu tham khảo được sử dụng trong một danh sách
3. Kiểm tra xem những danh sách đó đã bao giờ .Sort()được gọi trên chúng chưa

Điều gì có thể tồi tệ hơn, nếu bạn loại bỏ một IComparabletriển khai vẫn đang được sử dụng, bạn sẽ không gặp phải lỗi hay cảnh báo nào. Điều duy nhất bạn sẽ nhận được là hành vi sai lầm ở tất cả những nơi quá mơ hồ để bạn nghĩ đến.

Những vấn đề này kết hợp, cộng với yêu cầu thay đổi

Lý do tôi đến để nghĩ về điều này là vì nó đã sai đối với tôi. Tôi đã hạnh phúc sử dụng IComparabletrong ứng dụng của tôi trong 2 năm nay. Bây giờ, các yêu cầu đã thay đổi và điều cần được sắp xếp theo 2 cách khác nhau. Nó đã nhận thấy rằng không có gì vui khi trải qua các bước được mô tả trong phần trước.

Câu hỏi

Những vấn đề này khiến tôi nghĩ IComparablelà kém hơn IComparerhoặc .OrderBy(), đến mức không thấy bất kỳ trường hợp sử dụng hợp lệ nào sẽ không được phục vụ tốt hơn bởi các lựa chọn thay thế.
Có phải luôn luôn tốt hơn để sử dụng IComparerhoặc LINQ, hoặc có những lợi thế / trường hợp sử dụng mà tôi không thấy ở đây?

IComparablecó những hạn chế bạn đề cập, đó là chính xác. Nó là một giao diện đã có sẵn trong .NET framework 1.0, trong đó các lựa chọn thay thế chức năng và Linq không có sẵn. Vì vậy, có, người ta có thể xem nó như là một yếu tố khung lỗi thời, chủ yếu được giữ cho khả năng tương thích ngược.

Tuy nhiên, đối với nhiều cấu trúc dữ liệu đơn giản, một cách sắp xếp có lẽ là đủ hoặc tự nhiên. Đối với những trường hợp này, có một vị trí chính tắc để thực hiện mối quan hệ thứ tự vẫn là một cách tốt để giữ mã DRY, thay vì luôn lặp lại cùng một logic trong mỗi lệnh gọi đến OrderBymọi nơi.

Bạn đã "vui vẻ sử dụng IComparable trong ứng dụng của mình được 2 năm rồi", như bạn đã viết, vì vậy nó xuất hiện với tôi nó phục vụ tốt cho bạn trong một thời gian dài. Khi bạn phải xác thực, thay đổi và kiểm tra tất cả các cuộc gọi đến Sort, đó cũng có thể là dấu hiệu bạn đang thực hiện cùng loại logic sắp xếp ở nhiều nơi, đây không phải là lỗi của IComparable. Vì vậy, đây có thể là một dịp để tập trung nhiều logic này vào một nơi, làm cho mã của bạn trở nên KHÔ hơn.

Tôi đồng ý với tình cảm của bạn về IComparable

Chỉ cần nhìn vào các nhận xét trên Array.Sort()

• Mỗi phần tử của mảng phải thực hiện IComparablegiao diện để có khả năng so sánh với mọi phần tử khác trong mảng. (hoặc ngoại lệ được ném)
• Nếu sắp xếp không thành công, kết quả không được xác định.

Chúng tôi có lẽ sẽ không bao giờ là động lực, tuy nhiên! xem xét object.Equals()một phương thức trên mọi đối tượng cho phép bạn so sánh các đối tượng với nhau để xem chúng có "giống nhau" không

Bạn đã có nó rồi, nhưng đã được giao nhiệm vụ thêm Array.Sort()bạn có thể muốn thêmobject.Compare(object)