- PVSM.RU - https://www.pvsm.ru -
Это заключительная часть цикла про Dynamic Language Runtime. Предыдущие статьи:
В этой небольшой заметке мы наконец разберем основные случаи использования dynamic в реальной жизни: когда без него не обойтись и когда он может существенно облегчить существование.
Таких случаев нет. Всегда можно написать аналогичный по функционалу код в статическом стиле, разница лишь в удобстве чтения и объеме кода. Например, при работе с COM-объектами вместо dynamic можно использовать рефлексию.
В первую очередь это, конечно же, работа с COM-объектами, ради которой всё это и затевалось. Сравните код, получившийся при помощи dynamic и при помощи рефлексии:
dynamic instance = Activator.CreateInstance(type);
instance.Run("Notepad.exe");
var instance = Activator.CreateInstance(type);
type.InvokeMember("Run", BindingFlags.InvokeMethod, null, instance, new[] { "Notepad.exe" });
Как правило, для работы с COM-объектами через рефлексию приходится создавать развесистые классы с обертками под каждый метод/свойство. Есть и менее очевидные плюшки типа возможности не заполнять ненужные вам параметры (обязательные с точки зрения COM-объекта) при вызове метода через dynamic.
Ещё один хрестоматийный пример — работа с конфигами, например с XML. Без dynamic:
XElement person = XElement.Parse(xml);
Console.WriteLine(
$"{person.Descendants("FirstName").FirstOrDefault().Value} {person.Descendants("LastName").FirstOrDefault().Value}"
);
С dynamic:
dynamic person = DynamicXml.Parse(xml);
Console.WriteLine(
$"{person.FirstName} {person.LastName}"
);
Разумеется, для этого нужно реализовать свой динамический класс. В качестве альтернативы первому листингу можно написать класс, который будет работать примерно так:
var person = StaticXml.Parse(xml);
Console.WriteLine(
$"{person.GetElement("FirstName")} {person.GetElement("LastName")}"
);
Но, согласитесь, это выглядит гораздо менее изящно, чем через dynamic.
Предыдущий пункт можно обобщить на любые действия с внешними ресурсами. У нас всегда есть две альтернативы: использование dynamic для получения кода в нативном C# стиле либо статическая типизация с «магическими строками». Давайте рассмотрим пример с REST API запросом. С dynamic можно написать так:
dynamic dynamicRestApiClient = new DynamicRestApiClient("http://localhost:18457/api");
dynamic catsList = dynamicRestApiClient.CatsList;
Где наш динамический класс по запросу свойства отправит запрос вида
[GET] http://localhost:18457/api/catslist
Затем десериализует его и вернем нам уже готовый к целевому использованию массив кошек. Без dynamic это будет выглядеть примерно так:
var restApiClient = new RestApiClient("http://localhost:18457/api");
var catsListJson = restApiClient.Get("catsList");
var deserializedCatsList = JsonConvert.DeserializeObject<Cat[]>(catsListJson);
В предыдущем примере у вас мог возникнуть вопрос: почему в одном случае мы десериализуем возвращаемое значение к конкретному типу, а в другом — нет? Дело в том, что в статической типизации нам нужно явно привести объекты к типу Cat для работы с ними. В случае же dynamic, достаточно десериализовать JSON в массив объектов внутри нашего динамического класса и вернуть из него object[], поскольку dynamic берёт на себя работу с рефлексией. Приведу два примера того, как это работает:
dynamic deserialized = JsonConvert.DeserializeObject<object>(serialized);
var name = deserialized.Name;
var lastName = deserialized.LastName;
Attribute[] attributes = type.GetCustomAttributes(false).OfType<Attribute>();
dynamic attribute = attributes.Single(x => x.GetType().Name == "DescriptionAttribute");
var description = attribute.Description;
Тот же самый принцип, что и при работе с COM-объектами.
С помощью dynamic можно очень элегантно реализовать этот паттерн. Вместо тысячи слов:
public static void DoSomeWork(Item item)
{
InternalDoSomeWork((dynamic) item);
}
private static void InternalDoSomeWork(Item item)
{
throw new Exception("Couldn't find handler for " + item.GetType());
}
private static void InternalDoSomeWork(Sword item)
{
//do some work with sword
}
private static void InternalDoSomeWork(Shield item)
{
//do some work with shield
}
public class Item { }
public class Sword : Item {}
public class Shield : Item {}
Теперь при передаче объекта типа Sword в метод DoSomeWork будет вызван метод InternalDoSomeWork(Sword item).
Плюсы использования dynamic:
Минусы использования dynamic:
На мой взгляд, наибольший профит от использования dynamic разработчик получит в следующих ситуациях:
Как минимум спорным выглядит использование dynamic в сложных проектах с объемной базой кода, — здесь лучше потратить время на написание статических оберток, сведя таким образом количество неочевидных моментов к минимуму.
Если вы работаете с COM-объектами или доменами в сервисах/продуктах, подразумевающих длительное непрерывное время работы — лучше dynamic не использовать, несмотря на то, что именно для таких случаев он и создавался. Даже если вы досконально знаете что и как делать и никогда не допускаете ошибок, рано или поздно может прийти новый разработчик, который этого не знает. Итогом, скорее всего, будет трудновычислимая утечка памяти.
Автор: Alexey Plokhikh
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/c-2/332915
Ссылки в тексте:
[1] Подробно о dynamic: подковерные игры компилятора, утечка памяти, нюансы производительности: https://habr.com/ru/post/466657/
[2] Грокаем DLR: https://habr.com/ru/post/469075/
[3] Источник: https://habr.com/ru/post/470355/?utm_source=habrahabr&utm_medium=rss&utm_campaign=470355
Нажмите здесь для печати.