Представьте: кто-то в команде написал код с dynamic, получил RuntimeBinderException в продакшене, и теперь это слово под запретом навсегда.
Это самая ленивая политика в истории .NET. Вместо того чтобы разобраться с проблемой, команды просто заклеивают её скотчем из запретов.
В чём подвох
Когда вы запрещаете dynamic, разработчики не перестают решать те же задачи. Они просто переходят на рефлексию. И получается вот:
// Вместо одной строки
dynamic plugin = LoadPlugin("RenderEngine");
plugin.Render(data);
// Пишем вот это
var pluginType = plugin.GetType();
var method = pluginType.GetMethod("Render");
if (method == null) throw new InvalidOperationException("Method not found");
method.Invoke(plugin, new object[] { data });
800 строк рефлексии с silent nulls и магическими строками. Риски те же, код хуже, багов больше.
Когда dynamic действительно нужен
В 95% случаев dynamic — избыточен. Но есть сценарии, где он просто незаменим:
• Плагин-системы
Ваше приложение загружает расширения, которые вы не компилировали вместе с основным кодом. У вас нет доступа к типам на этапе компиляции. dynamic позволяет вызвать
plugin.Calculate() без танцев с reflection.• Скриптинг
Админы пишут небольшие скрипты для настройки логики — расчёт цен, трансформация данных. Вам не нужны 20 статических классов. Вам нужна гибкость с контролем.
• Duck typing в тестах
Когда вы тестируете поведение, а не типы. Не важно, какой это класс — важно, что он умеет делать
GetPrice(). Не нужно создавать фейковые интерфейсы ради компилятора.Проблема не в dynamic. Проблема в бесконтрольном доступе. Если вы валидируете имена методов, ограничиваете доступ, логируете вызовы и ставите таймауты — вы в безопасности. Возможно, даже в большей, чем с тем лабиринтом из reflection, который живёт в половине вашего кода плагинов.
🐸 Библиотека шарписта
#sharp_view