Чи застарілий / "шкідливий" інтерфейс IComparable?

IComparable працює лише одним способом

Скажімо, у вас Employeeклас. З одного виду, ви хочете показати всі Employeesвідсортовані за назвою - в іншому за адресою. Як ти збираєшся цього досягти? Не з IComparable, принаймні, не в жодному ідіоматичному вигляді.

IComparable має логіку в неправильному місці

Інтерфейс використовується при виклику .Sort(). У поданні, яке відображає Customerсортування за назвою, взагалі немає коду, який би вказував, як він буде сортований.
З іншого боку, Customerклас припускає, як він буде використовуватися - у цьому випадку він буде використовуватися у списку, відсортованому за іменами.

IComparable використовується неявно

У порівнянні з альтернативами, дуже важко зрозуміти, де використовується логіка порівняння - чи взагалі. Припускаючи ваш стандартний IDE і починаючи з Customerкласу, мені доведеться це зробити

1. Шукати всі посилання на Customer
2. Знайдіть ті посилання, які використовуються у списку
3. Перевірте, чи колись ці списки .Sort()закликали їх

Що, мабуть, гірше, якщо ви видалите IComparableреалізацію, яка все ще використовується, ви не отримаєте помилок чи попередження. Єдине, що ви отримаєте - це неправильна поведінка у всіх місцях, які були вам занадто незрозумілими.

Ці питання поєднуються плюс зміни вимог

Сама причина, коли я придумав це, полягає в тому, що це пішло не так. Я з радістю використовую IComparableу своїй програмі вже 2 роки. Тепер вимоги змінилися і річ потрібно сортувати двома різними способами. Він зауважив, що не весело пройти кроки, описані в попередньому розділі.

Питання

Ці питання змушують мене думати IComparableяк про неповноцінний IComparerабо .OrderBy(), до того, що я не бачу жодного дійсного випадку використання, який не міг би краще подати альтернативи.
Чи завжди краще використовувати IComparerабо LINQ, або є переваги / випадки використання, яких я тут не бачу?

IComparableмає обмеження, про які ви згадали, це правильно. Це інтерфейс, який вже був доступний у .NET Framework 1.0, де ці функціональні альтернативи та Linq були недоступні. Так, так, можна побачити це як застарілий рамковий елемент, який в основному зберігається для зворотної сумісності.

Однак для багатьох простих структур даних одного способу сортування, ймовірно, достатньо чи природного. У цих випадках наявність одного канонічного місця для реалізації відносин замовлення все ще є хорошим способом зберегти код DRY, замість того, щоб завжди повторювати ту саму логіку в кожному дзвінку в OrderByусьому місці.

Як ви вже писали, ви "із задоволенням використовуєте IComparable у вашій заявці вже 2 роки", тому мені здається, що він вам довго слугував. Коли вам доведеться перевірити, змінити і протестувати всі дзвінки Sort, це також може бути ознакою того, що ви робили таку ж логіку сортування у багатьох місцях, що не є виною IComparable. Тож це може бути приводом централізувати більше цієї логіки в одному місці, зробивши ваш код більш ДУХОМ.

Я згоден з вашими настроями щодо IComparable

Просто подивіться на зауваження далі Array.Sort()

• Кожен елемент масиву повинен реалізовувати IComparableінтерфейс, щоб він міг порівнювати з усіма іншими елементами масиву. (або викид викинуто)
• Якщо сортування не завершено успішно, результати не визначені.

Напевно, ми ніколи не будемо мотивації, однак! розглянути object.Equals()метод кожного об'єкта, який дозволяє порівнювати об'єкти між собою, щоб побачити, чи вони "однакові"

У вас це вже є, але ви отримали завдання додати Array.Sort()його, можливо, захочете додатиobject.Compare(object)