Comments 17
Я поясню свой выбор 8 (как наиболее близкий), хотя на мой взгляд там нужен dynamic_cast, a не typeid, и можно ограничиться параметризованным функтором / компаратором
Приоритет при сортировке на мой взгляд привязан к параметрам сортировки, и элементы об этом ничего знать не должны.
Это исключает варианты 1 — 6 (6 вообще костыльный с побочными эффектами)
Вариант 7 и 8 похожи, но смысла возиться со строками нет, тем более писать для этого методы элемента, по сути дублирование встроенного RTTI.
Вариант 9 на мой взгляд плохо расширяем из-за строгой типизации
Приоритет при сортировке на мой взгляд привязан к параметрам сортировки, и элементы об этом ничего знать не должны.
Это исключает варианты 1 — 6 (6 вообще костыльный с побочными эффектами)
Вариант 7 и 8 похожи, но смысла возиться со строками нет, тем более писать для этого методы элемента, по сути дублирование встроенного RTTI.
Вариант 9 на мой взгляд плохо расширяем из-за строгой типизации
0
Варианты 4 и 5 как раз отвязывает элементы от деталей реализации сортировки
0
Они не привязаны к параметрам сортировки, поскольку она сама не параметризована, а жёстко задана в коде, нету «конфигурирования приоритетов извне» — приоритеты должны задаваться в рантайме, а не на этапе компиляции.
4й вариант где на 3 типа написано 9 функций сравнения плохо масштабируется при увеличении числа типов.
5й в принципе можно легко переделать и параметризовать, если очень надо без RTTI, то выбрал бы его.
4й вариант где на 3 типа написано 9 функций сравнения плохо масштабируется при увеличении числа типов.
5й в принципе можно легко переделать и параметризовать, если очень надо без RTTI, то выбрал бы его.
0
//$dirs
//$files
if($config['mix']) {
$mix=array_megre($dirs, $files);
sort($mix);
}else{
sort($dirs);
sort($files);
}
0
Тогда получается, что только ради целей сортировки нужно таскать список каталогов и файлов раздельно
0
Будет перерасход по памяти?
0
Нет, непонятно как это обыграть в плане архитектуры. Куда деть эти dirs, files? Завернуть в структуру? А если нам нужно сделать общее действие над всеми элементами (например, найти по какому-нибудь шаблону), то искать сначала в одном, а потом в другом?
0
Первый вариант с приоритетом в виде инта, только вместо int — enum.
+1
Хороший вариант, как развитие первого варианта. Можно enum вынести в файл, принадлежашей сортировке и тогда уйдет проблема «поиска всех наследников», нужно будет только заглянуть в файл, где описаны все enum-ы. Но минус — структуры зависят от сортировки
0
Что значит "структуры зависят от сортировки"? В смысле, я не понял, что имеется в виду. Можете перефразировать?
0
Ну это значит, что в структурах есть поле priority, которое нужно только для сортировки. Хотя сортировка — не обязательно задача именно этих структур.
В статье про это написано
Может например быть такая ситуация, что классы File, Folder вам даны извне и вы ничего не можете с ними сделать (добавить доп поле например)
В статье про это написано
Может например быть такая ситуация, что классы File, Folder вам даны извне и вы ничего не можете с ними сделать (добавить доп поле например)
0
Оператор dynamic_cast имеет существенные накладные расходы. При сортировке его лучше избегать.
0
вот если использовать именно список, то отсортировать надо лишь единожды, далее можно перетасовывать его при смене типа сортировки за O(N).
0
Sign up to leave a comment.
Как же, черт возьми, отсортировать этот список?