Здравствуйте, m2user, Вы писали:

M>Угу, и если добавить реализацию Func<T, int> comparer, то по объему содержательного кода будет примерно столько же, как в предложенном здесь (https://rsdn.org/forum/dotnet/8914066?tree=tree

Автор: m2user
Дата: 22.03.25

) варианте.
M>Поэтому не вижу там никакого овердизайна.

1. Как бы любому непредвзятому очевидно обратное. Объем кода как-то сильно выше.

2. ArrayList — это древнючий не типизированный класс не пригодный, например, для списков структур.

3. Он не решает исходную задачу, так как у него точно так же нет перегрузки не принимающий эталонный элемент. В результате ты начинаешь городить костыли над костылями — Wrapper, вторую обёртку.

Уж лучше тогда воспользоваться костылём karbofos42

Автор: karbofos42
Дата: 22.03.25

. Он короче, понятнее и быстрее.

M>Также я полагаю, что с т.з. поддержки кода собственная реализация даже самых простых алгоритмов это дополнительная нагрузка и потенциальный источник bug`ов.

Твои предположения высосаны из пальца и не верны. Твои обёртки плохо читаются, создают оверхэд и точно так же требуют тестирования. Код бинарного поиска очень прост. Он, конечно, требует тестирования, но не более чем костыли. А вот мину у костылей всего лишь один, но глобальный — они ухудшают читаемость кода усложняя его без необходимости.

M>Т.е. для автора кода алгоритм выглядит как 100% верный (например скопирован с reference source), однако для другого разработчика, который будет иметь дело с этим кодом, это уже не так (даже если есть unit тесты).

Если тесты есть, проблем никаких не вижу. А они всё равно нужны.