Как стать автором
Обновить

Комментарии 17

Я поясню свой выбор 8 (как наиболее близкий), хотя на мой взгляд там нужен dynamic_cast, a не typeid, и можно ограничиться параметризованным функтором / компаратором
Приоритет при сортировке на мой взгляд привязан к параметрам сортировки, и элементы об этом ничего знать не должны.
Это исключает варианты 1 — 6 (6 вообще костыльный с побочными эффектами)
Вариант 7 и 8 похожи, но смысла возиться со строками нет, тем более писать для этого методы элемента, по сути дублирование встроенного RTTI.
Вариант 9 на мой взгляд плохо расширяем из-за строгой типизации
Варианты 4 и 5 как раз отвязывает элементы от деталей реализации сортировки
Они не привязаны к параметрам сортировки, поскольку она сама не параметризована, а жёстко задана в коде, нету «конфигурирования приоритетов извне» — приоритеты должны задаваться в рантайме, а не на этапе компиляции.
4й вариант где на 3 типа написано 9 функций сравнения плохо масштабируется при увеличении числа типов.
5й в принципе можно легко переделать и параметризовать, если очень надо без RTTI, то выбрал бы его.
Иногда сортировка должна задаваться жестко в коде. То есть, пользователь извне ее менять не может, но по запросу например менеджера может быть нужно что-то быстро подтюнить
Классы файлов, каталогов и т.д. не обязательно должны быть из стандартной библиотеки. В моем случае задача была даже не в классах и каталогах. Там были другие сущности. Файлы и каталоги я выбрал как наглядный всем понятный пример
//$dirs
//$files
if($config['mix']) {
  $mix=array_megre($dirs, $files);
  sort($mix);
}else{
  sort($dirs);
  sort($files);
}
Тогда получается, что только ради целей сортировки нужно таскать список каталогов и файлов раздельно

Будет перерасход по памяти?

Нет, непонятно как это обыграть в плане архитектуры. Куда деть эти dirs, files? Завернуть в структуру? А если нам нужно сделать общее действие над всеми элементами (например, найти по какому-нибудь шаблону), то искать сначала в одном, а потом в другом?
тогда наследование выглядит как оверхед. Типичная задача на сортировку подразумевает массив элементов одного типа с разными свойствами, никакой магии.

Первый вариант с приоритетом в виде инта, только вместо int — enum.

Хороший вариант, как развитие первого варианта. Можно enum вынести в файл, принадлежашей сортировке и тогда уйдет проблема «поиска всех наследников», нужно будет только заглянуть в файл, где описаны все enum-ы. Но минус — структуры зависят от сортировки

Что значит "структуры зависят от сортировки"? В смысле, я не понял, что имеется в виду. Можете перефразировать?

Ну это значит, что в структурах есть поле priority, которое нужно только для сортировки. Хотя сортировка — не обязательно задача именно этих структур.

В статье про это написано

Может например быть такая ситуация, что классы File, Folder вам даны извне и вы ничего не можете с ними сделать (добавить доп поле например)
Оператор dynamic_cast имеет существенные накладные расходы. При сортировке его лучше избегать.
вот если использовать именно список, то отсортировать надо лишь единожды, далее можно перетасовывать его при смене типа сортировки за O(N).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории