Я обнаружил, что бегаю по старому устаревшему коду фреймворка 3.5, и обнаружил некоторые моменты, когда есть целая куча списков и словарей, которые должны обновляться синхронизированным образом. Я решил, что могу сделать этот процесс бесконечно проще как для использования, так и для понимания, объединяя их в пользовательские классы-контейнеры новых пользовательских классов. Однако есть некоторые моменты, в которых я пришел к вопросу об организации содержимого этих новых контейнерных классов по определенному внутреннему свойству. Например, сортировка по свойству ID номера одного класса.

Поскольку контейнерные классы в основном основаны на общем объекте List, моим первым инстинктом было написать внутренние классы с помощью IComparable и написать метод CompareTo, который сравнивает свойства. Таким образом, я могу просто позвонитьitems.Sort() когда я хочу вызвать сортировку.

Однако вместо этого я подумал об использованииitems = items.OrderBy(Func) вместо. Таким образом, это более гибко, если мне нужно отсортировать по любому другому свойству. Читаемость также лучше, так как свойство, используемое для сортировки, будет перечислено в строке с вызовом сортировки, вместо того, чтобы искать код IComparable. В результате общая реализация выглядит чище.

Меня не волнует преждевременная или микрооптимизация, но мне нравится последовательность. Я считаю, что лучше придерживаться одного вида реализации для всех случаев, когда это уместно, и использовать разные реализации там, где это необходимо. Стоит ли конвертировать мой код, чтобы использовать LINQ OrderBy вместо List.Sort? Лучше ли придерживаться реализации IComparable для этих пользовательских контейнеров? Есть ли какие-либо существенные механические преимущества, предлагаемые любым путем, на котором я должен взвешивать решение? Или их конечная функциональность эквивалентна тому, что она просто становится предпочтением кодера?