Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Dynamic container proof of concept

3 комментария

Итак, я обещал запилить proof of concept идеи касательно динамически изменяемых программ, так что давайте начнем. Для начала нужно сделать контейнер с набором типов и механизмом регистрации:

public class DynamicContainer
{
  private Dictionary<Type, Type> registry
    = new Dictionary<Type, Type>();
  public void Register<TRequested, TReturned>()
    where TReturned : TRequested
  {
    // todo
  }
}

Пока все достаточно банально, и мы даже не разбили контейнер на “билдер” (классический GoF паттерн) и сам контейнер, как это делает например Autofac. Но в какой-то момент нам придется таки обойти весь граф зависимостей (давайте представим что мы делаем только property injection) и записать куда-то эти результаты.

Это все очень легко делается. Просто добавляем очередной dictionary который держит список зависимостей для каждого типа. Кстати сюда же можно добавить ассоциативный контейнер в обратную сторону — специально для тех кому лень искать в нугетах bidirectional directionary:

private readonly Dictionary<Type, HashSet<Type>> dependencies
  = new Dictionary<Type, HashSet<Type>>();
private readonly Dictionary<Type, HashSet<Type>> affected
  = new Dictionary<Type, HashSet<Type>>();

Теперь, в момент регистрации любого компонента, эти структуры нужно заполнять. Давайте представим что у нас property injection реализован с помошью атрибута [Service]: тогда мы просто берем и для каждого типа находим все проперти с этим атрибутом, и добавляем все что надо в оба словаря:

public DynamicContainer Register(Type requested, Type returned)
{
  var props = returned.GetProperties(BindingFlags.Instance | BindingFlags.NonPublic)
    .Where(p => CustomAttributeExtensions.GetCustomAttribute<ServiceAttribute>((MemberInfo) p) != null);
  foreach (var p in props)
  {
    dependencies.Set(returned, p.PropertyType);
    affected.Set(p.PropertyType, returned);
  }
  registry.Set(requested, returned);
  return this;
}

Здесь и далее, Set() — это upsert операция.

Теперь, в процессе создания типа, должны быть удовлетворены все его зависимости, то есть:

private object Resolve(Type type)
{
  var actualType = registry[type];
  var instance = Activator.CreateInstance(actualType);
  if (dependencies.ContainsKey(actualType))
  {
    foreach (var p in actualType.GetProperties(BindingFlags.Instance|BindingFlags.NonPublic)
      .Where(p => p.GetCustomAttribute<ServiceAttribute>() != null))
    {
      p.SetValue(instance, Resolve(p.PropertyType));
    }
  }
  return instance;
}

Иначе говоря, мы пытаемся рекурсивно внедрить все зависимости для нужных пропертей. Давайте еще сделаем небольшой helper-метод для выдачи инстансов:

public T Resolve<T>()
{
  return (T) Resolve(typeof(T));
}

Теперь сценарий: у нас есть машина которая использует некий сервис…

public class Car
{
  [Service]
  private IAlarmService AlarmService { get; set; }
  public void TriggerAlarm()
  {
    Console.WriteLine("Triggering alarm⋮");
    AlarmService.Trigger();
  }
}

Сам по себе сервис имеет метод Alarm() который просто пишет в консоль:

public class AlarmService : IAlarmService
{
  public void Trigger()
  {
    Console.WriteLine("Alarm has been sent to HQ");
  }
}

Так вот, все это счастье можно спокойно использовать вот так:

var container = new DynamicContainer();
container
  .Register<IAlarmService, AlarmService>()
  .Register<Car>();
var car = container.Resolve<Car>();
car.TriggerAlarm(); // Alarm has been sent to HQ

А теперь собственно то, что я хотел показать: допустим мы хотим сервис AlarmService поменять в рантайме. Делается это вот так:

var text = File.ReadAllText(@"..\..\AlarmService.cs");
text = text.Replace("has been sent", "has NOT been sent");
var ipc = new InProcessCompiler();
var newServiceType = ipc.Compile(text);
container.Register(newServiceType.GetInterfaces()[0],
  newServiceType);

Тут происходит следующее:

  • Мы вычитываем сорцы сервиса который хотим менять. Заметьте что это подразумевает что у нас one class per file.

  • Берем и меняем исходник. На этом этапе можно также сохранить эти сорцы в тот файл откуда взяли.

  • Создаем компилятор (это отдельный класс который просто использует компиляторный API чтобы что-то собрать) и компилируем сорцы.

  • На выходе у нас — System.Type. Просто берем и регистрируем его заного в контейнере.

Вот собственно и всё — реализация обновилась. Можно пересоздать объект Car и тут же воспользоваться новым сервисом:

car = container.Resolve<Car>();
car.TriggerAlarm(); // Alarm has NOT been sent to HQ

Такой вот proof of concept. Думаю вы поняли, что если держать реестр всех созданных контейнером объектов (как WeakReference-ы конечно же), то можно прямо в методе Register() пройтись по выданным объектам и обновить их сервисы, без какого либо пересоздания.&npsp;■

Реклама

Written by Dmitri

25 июля 2018 at 20:19

Опубликовано в .NET, Technology

Development 2.0

7 комментариев

Ох вау, новый блогпост, а вы-то думали что Нестерук suka мертв. Ну, еще нет, хоть я на пенсии и пишу это на острове пенсионеров (Мадейра). Какой-то адский бабулькоград.

Так ну ладно, я тут пришел поговорить про Optane. Точнее это отмазка. Вся суть в том, что я снова хочу толкать все те же свои программитские идеи которые и раньше толкал, только Optane делает это чуть проще.

Итак, о чем мы? Да о том, что скорость SSD-образных технологий постепенно приближается к скорости RAM — настолько, что те модели Optane которые есть на рынке сейчас — это М.2 драйвы для кэшей для тех у кого еще нет SSD и те кто хочет малой кровью получить прирост к перформансу.

Конечно Intel — это, извините, лживая и не особо заботящаяся о своих клиентах компания. Это я как пользователь всего их стэка говорю, им глубоко пофиг что их компилятор накрывается на тривиальных примерах с “Ошибка 3”, а про то что прирост скорости процов в последнии несколько лет чуть ли не нулевой (ну, процентов 15) вообще говорить не стоит, как и о продолбанном Broadwell.

Так вот, Optane — это такой “звоночек” что идет, пусть и не очень быстро, самая настоящая конвергенция, когда нет разницы в скорости и персистентности между RAM и “долгосрочными” носителями информации. А это в свою очередь открывает интересные возможности, и не только для геймдева где “Loading screen” это нечто ругательное.

Что за идею я вам хочу толкнуть? Да все ту же идею что программы должны быть всегда запущенны, и что разделение программы на этап компиляции и этап запуска — это бред. Еще со времен Java 2, простихосподи, у нас была возможность скомпилировать программу прямо из программы и динамически ее подгрузить. Вот насчет отгрузки все сложнее (легко в C++, очень сложно в .NET) можно долго писать, но возможность такая существует. Итак, что бы хотелось иметь?

  • Программист запускает программу как “чистый лист”, то есть по сути запускает лишь работающий, пустой IoC контейнер без регистраций (и SMS).

  • Программист редактирует программу “по живому”, в процессе запуска. Контейнер дает ему возможность добавить новый класс/интерфейс или поменять существующий. Это кстати — не совсем тривиальные задачи, но в базовом сценарии, когда все зависимости заинжекшены — вполне реально.

  • Кусок кода, который кодер только что сваял компилируется и загружается в программу. Ну или сохраняется как либа и подгружается.

  • Если был изменен существующий тип, он заменяется, перерегистрируется в контейнере и потом каждый тип, который его использует, пересоздается снова. Это может стать очень большой, рекурсивной операцией т.к. нужен обход зависимостей всех зарегистрированных в контейнере типов.

  • Если был создан новый тип, он просто регистрируется в контейнере и в дальнейшем может быть использован как напрямую так и через контейнер.

Вот это, мои дорогие, то как я вижу Development 2.0 — новая парадигма, в которой ничего не нужно пересобирать и перезапускать. Нужен просто такой IoC контейнер, который настроен на вечную персистентность системы и умеет худо бедно отгружать типы (или делать грамотный перезапуск). Технология динамического прототипирования, про которую я неоднократно говорил — это proof of concept того, про что я тут пишу.

А что, собственно, происходит дальше? Неужто мы редактируем прямо продакшн? Ну это уже от вас зависит — если вы захотите запилить “параллельную реальность” для проверки идей и тестирования, то это реально! И будет работать намного быстрее т.к. все уже загружено в процесс и никакой рекомпиляции “всего и вся” делать не нужно! А уже наработанные технологии code coverage дадут возможность трекать изменения и ранить тесты только на то, что реально поменялось.

Чтобы не быть голословным, я пошалуй напишу proof of concept на это дело. Какие-то наработки у меня уже есть с давнего dotNext, сейчас самое время сделать апдейт…

Written by Dmitri

5 июня 2018 at 19:42

Опубликовано в Programming

Tagged with

Отзыв о конференции DotNext Piter 2018

7 комментариев

Вот и ДотНекст закончился, а поскольку я уже практически перестал писать в блог что-то содержательное, напишу хоть о конференции, т.к. я там был, мед-пиво пил, билет получил халявный но зато купил билет коллеге так что все норм.

Первое что скажу — 12 спонсоров в этот раз, это круто, вроде в 1й присест был JetBrains один и то бесплатно, а тут 12. Правда спонсоры это в основном сервисные компании, которые платят копейки (копейки в моем понимании это <$1kk/год) — EPAM, DataArt (черт, я там работал целых аж 3 месяца), и прочие подобные конторы. Из продуктовых там были JetBrains, Fast Reports, хз не помню кто еще. Главным спонсором был Альфабанк, для меня фраза “ритейловый банк” синоним “раковая опухоль”, да не будем о плохом, товарищи. Короче я понял что я unemployable :)

Так вот, посетил я не все доклады, а только некоторые, так что вот мои отзывы:

Apps, algorithms and abstractions: decoding our digital world, Dylan Beattie: давайте начнем с того что SkillsMatter это какбы контора которая, как и я, зарабатывает деньги. Что они там делают — ну, тренинги делают. А сам по себе доклад был 100% популистский, что хорошо, т.к. конфа должна начинаться и заканчиваться чем-то легким. Поэтому было вообще ОК, Дилан рассказал про то сколько всего сложного происходит в тот момент когда ты получаешь на мобильнике картинку котика и пишешь LOL. Отдельный ему респект за русскоязычный юмор (щи да каша пища наша!), очень хорошо подготовился. Почему правда англичанин одевается как техасский ковбой история умалчивает, наверное это часть его рок-имиджа — это ведь он (и Вагиф Абилов, кстати!) играли рок на закрытии первого дня. Годно.

Fastware, Andrei Alexandrescu, The D Language Foundation — эээ, D какбы мертв, а Алексадреску обычно делает доклады на С++ конференциях вроде ACCU, C++Now и прочие, т.к. он легенда С++ мира который ушел в D. Который не взлетел — он хоть и делал там что-то на D в фейсбуке, но в отличии от Rust нехватило момента и язык не смог преодолеть силу тяготелния. Доклад Александреску показался мне немного несобранным и лишенным консистентности — он конечно потрудился чтобы перевести свои примеры в C#, но примеров было мало и они были клинично-прецезионными. Скорость — это не про те языки где нельзя напрямую писать ASM или манипулировать SIMDом, хотя что-то на C# у вас определенно получится. В целом, доклад не особо понравился.

Lightweight microservice collaboration using HTTP, Christian Horsdal — типичный консалтерский доклад высокого уровня. Я еще должен подчеркнуть тут, что microservices are not a thing: коммуникация через веб-интерфейсы это хорошо, но уровень дробления должно быть адекватно, и резать все на “микро” это очень тупо и никому нафиг не нужно. Поэтому просмотрел доклад, не почерпнув ни одной особой мысли. Да, в микросервисах появляются задачи вроде “как описать весь API”, “что нужно делать при поломке”, но эти задачи не отличаются от аналогов с работос с очередями вроде MSMQ, RabbitMQ и всем этим остальным адом. CQRS/ES — это круто и нужно. Микросервисы — скорее все же нет.

Взаимодействие микросервисов по HTTP/2, Евгений Жиров — вот этот доклад мне понравился, т.к. это была реальная case study о том как использовать HTTP/2. Докладчик объяснил зачем им это было надо, на какие грабли они наткнулись и про “а как же .NET Core”. Совершенно годный доклад, и хоть его основной вывод “нужно подождать”, мне понравилось.

Building real world production-ready web APIs with .NET Core, Alex Thissen — еще один доклад по микросервисам который тоже меня не впечатлил. Было чуть больше конкретики, у докладчика был реальный проект, но опять же весь рассказ как-то скомкался воедино, у него не было какой-то общей структуры верхнего уровня, и в результате я не могу сказать чтобы я из него что-то важное. Опять же, microservices aren’t a thing поэтому горевать по ним никто не будет.

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

Вот как-то так. В Москву я на DotNext не поеду — терпеть не могу этот город, и даже когда был евангелистом испытывал от него тошноту. И вообще, в этом году у меня было желание съездить на Build, но всем из РФ закрыли визы, а лететь одному — ну, в принципе реально, но как-то совсем одиноко. Как-нибудь в другой раз, когда санкции снимут. Хотя я почти уверен что их уже вообще не снимут. Ну еще несколько лет точно.

Да, похвастаюсь, у меня вышла книжка. Такие дела.

Written by Dmitri

24 апреля 2018 at 22:06

Опубликовано в Events

Tagged with ,

Итоги 2017 года

17 комментариев

Обидно когда приходит конец года а у тебя нет желания писать “что мы достигли в 2017”. Все от тебя ждут пост, but you are not helping. Why are you not helping, Leon? (гребаные репликанты)

К слову, новый Blade Runner годный фильм… хотя новых идей там где-то около нуля. Dunkirk тоже годный, хоть этот блог пока и не превратился в обзор кино и прочего (хотя вон по велосипедам в отдельной страничке уже вагон написано).

Этот пост — стена текста без картинок. Не знаю, вроде кому-то такой формат подходит.

Итак, поговорим за достижения. В этом году я худо бедно запилил Kinetica — платформу которая рендерит всякий красивый текст. На базе Кинетики удалось записать один видеокурс, Design Patterns in Java, и несмотря на то что конкретно про механизмы рендеринга которые использовались для курса я не получил слишком много комментов, сам курс людям понравился. Еще бы, я знаю что я делаю. Да, и если кому интересно, Kinetica написана на C# и Direct2D/DirectWrite, и нет, пока что ее скачать нельзя.

В моей голове все больше кристализуется понятие Education 2.0, то есть новый виток обучения. Ествественно, просто красивый анимированный рендер текста — это только начало. Для прогресса в этом плане мне нужна помощь (сейчас у меня 2 сотрудника), время, а также свежие технологии — тут и “мобилка”, и боты, и AR/VR. Будет очень интересно, а главное прибыльно, т.к. с растущей автоматизацией общества (где автономные машины, а?) все большей массе людей придется идти в, гм, автоматизаторы, а это как раз программирование и иже с ним.

Так, что еще? Ну, про алготрейдинг я писать не буду, отчасти потому что “деньги любят тишину”, а отчасти потому что начни я тут писать каким матаппаратом оперирую (пежноство, но у меня реально безумные вещи), у вас просто завянут уши, глаза, или что там. Я могу разве что литературу порекоммендовать, для начала читайте Оксендаля, он годный.

В плане гаджетов… ну, если не брать электровелы (блин, я все еще прусь этой темой), я очень мало нового попробовал. Ну, механические клавиатуры (уже писал вроде на эту тему, советую всем начинать со свич-тестера, первой вашей механической клавой вполне можно брать WASD). Что ещё? iPhone X попробовал, с точки зрения фото он Г, камеры реально некачественные, и я не понимаю, как обзоры в интернете все так подтасовали что ли, короче убогий софт для фото, хотя машинка резвая и вообще. Буду воровать у моей SO для тестирования мобильной платформы.

На 2018 у меня нет никаких технологических амбиций вообще. Вот например ироничная ситуация: у меня комп которому лет 8, у него 3 монитора 1080р… я бы мог сейчас вбросить деньжат и сделать 2×3×4K, там GTX1080, все дела… но парадокс в том, что все итак работает! И приносит деньги! А мотивации затеять новую сборку компа как-то пока нет особо, если учесть насколько все это нудно. Проще просто взять и купить свежий ноут.

Эпоха перенасыщения

У меня в последнее время такое впечатление, что народ насытился и даже пересытился всяким дорогим добром. Помнится, обедая в Аспене, я спросил своих американских коллег, нормально ли что местный веломагазин продает велосипеды по 5 тысяч долларов, по 7… они странно на меня посмотрели и сказали что, ну вообще да, что тут странного? И сейчас я сам уже не понимаю, откуда у нас образовался такой огромный разрыв в доходах между теми кто плывет по течению и тех, кто делает хоть что-то.

Перенасыщение идет во всех сферах. Все кажется пройденным, одним и тем же. Летишь на Канары в 100500-й раз и понимаешь что ничего особенного нет. Смотришь на “распродажи” Massdrop (на самом деле немного разводиловский сайт) и понимаешь что у тебя захламлено абсолютно всё, что тебе не нужен 23-й нож или 5-ю клавиатуру или еще одни наушники. Хотя было бы неплохо.

Перенасыщение не тольков материальном плане, но и в информационном: можно пойти в тырнеты и выкачать все интересные сериалы и смотреть до посинения. Но ловишь себя на мысли, что скроллишь к интересным моментам. Или вот еще пример: я включаю видеокурс чтобы разобраться с новой технологией. Но хватает меня ненадолго: хочется быстрее, быстрее, больше инфы, примеров, меньше слайдов. Терпения не хватает досмотреть.

У всех вокруг примерно те же проблемы: short attention span, нет желания ни во что вникать, хочется получить “быстрый контент”. Поэтому меня как раз и не удивляет, что все мои самые прибыльные идеи пришли с максимальной дозой страданий: страдать-то никто не хочет как раз.

Политический сдвиг

Мне, по большому счету, всегда было плевать на политику: я сторонник limited government и мне главное чтобы ко мне не лезли. Санкционная еда у меня имеется (я этот пост в Лапе печатаю, намек!), рутрекер в браузере открывается, чего еще надо? Но если серьезно, та смена парадигмы, которая идет в европе… мне все это очень не нравится, потому что европа — это все еще мой дом.

Я конечно говорю про терроризм и массовый наплыв иммиграции. Тут нужно пояснить: я не сторонник социализма вообще. Шведская модель забрать все у богатых и распределить беженцам — она экономически необоснована. Особенно в плане культурной несовместимости всех этих ребят с нашей культурой. Да-да, я про зоофилию и прочий бред, которым наши гости из Сирии любят баловаться. Бррр.

Мне всегда было плевать на разделение между либералами и консерваторами. Но сейчас у либеральной стороны политики какие-то странные цели: узаконить однополые браки, проводить смену пола детям (детям, блять!), и еще массой всякого ахтунга который к основной массе населения вообще никакого отношения не имеет. Взять например всю эту панику насчет туалетов для трансгендеров… блин, ну серьезно? Я не могу все это воспринимать всерьез.

В связи с этим понятно почему люди так рады, прям ликуют, победе Трампа. Потому что Трамп большой железнодорожный болт забил на весь этот идиотизм. Он (ну, Мэттис) разбомбил к чертям ИГИЛ (Россия тоже руку приложила!), и класть он хотел на всякие Пакистан, Иран, Палестину и прочий мирок где люди просто завидуют и ненавидят. Трамп делает то что хочет, и ни медиа-цирк ни Голивуд, никто уже не сможет его сместить.

Рано или поздно, окажется что США, с ее жесткой миграционной политикой и реальным движением человечества вперед, останется единственной вменяемой страной… мы будем жить на планете США, подчиненной демократично-капиталичтическим принципам, нравится вам это или нет. А ребятам в платках придется искать себе другую планету, т.к. на этой их никто терпеть не будет. Может на Венеру? Смотрите кто там живет.

Экономические веяния

Все уже знаю что углеводородам хана. Страны Европы постепенно вводят законы чтобы к 2030-40м годам запретить ДВС полностью. Кто-то из вас наверняка захочет поныть в комментах, но ваш лживый национализм неуместен: таким странам как РФ, Саудовская Аравия, Иран/Ирак… им полностью придет хана. Они итак не особо экономически эффективны, но после перехода на электрику, закупать Бентли штабелями уже не получится. Я бы был рад если бы РФ производила, ну, микропроцессоры например, или одежду или мебель на конкурентноспособном уровне, но поезд уже ушел, причем ушел давно. Остается только пилить лес и копать землю.

Вообще автоматизация сильно поменяет расклад… в том смысле что ну не нужно нам 8 миллиардов людей, и кормить их нечем. Я понимаю, всем хочется пожить и понарожать детишек, но извините посоны, планета у нас одна. Достаточно одного качественного скачка (например, бессмертие) чтобы устроить такое расслоение общества, о котором вы и не мечтали. Представьте что у богатых, с их армиями роботов, появится возможность жить без масс рабов. Что они сделают? Правильно, избавятся от всей ненужной биомассы.

Все это, отчасти, мечты и спекуляции, т.к. в ближайшем будущем мы разве то водил попросим освободить авто, т.к. авто будут возить нас сами… посмотрите что делает Uber и прочие в этом плане. Вот это — будущее, с которым сложно спорить. Я все еще хочу понять как получится миссия на Марс если космическая радиация приводит к бесплодию и болезни Альцгеймера.

Что со всем этим делать?

Все делают на что-то ставки. Мне кажется, ставку нужно делать на idle, не-рабочее население у которого есть всё и которое хочет получить интересную информацию, причем прямо в моск. Вот это и нужно строить — игры, шоу на YouTube (идешь в лес, находишь суицидника, записываешь, общее презрение), образовательные программы. Нам нужно занять человека в период перенасыщенности, т.к. есть подозрение что тело, которое не стимулирует внешняя среда, быстрее умирает. А мертвое тело не сможет вам занести денюжку, что как бы критично!

Здесь было напутствие насчет 2018 и мои персональные планы на этот год, но их захавал Сотона. А у меня +100500 к инфантильности, спасибо за прочтение этого опуса. С Новым Годом!

P.S.: критика велкам, как всегда!

Written by Dmitri

4 января 2018 at 0:57

Опубликовано в Life

Tagged with

Заметка про видеокурсы

17 комментариев

Самое время поговорить про видеокурсы и то, как я до этого дошел. Если коротко, процесс был такой:

  • Работая в JetBrains, я делал всякие рекламные видео. Их, к сожалению, никто не смотрел. Максимум просмотров было где-то 5к, что в контексте YouTube равно нулю. Но мне за это платили зарплату, так что я делал, и вроде делал неплохо. Скиллы хоть поднял.

  • Я решил сделать свой YouTube канал для того чтобы постить видосики. Также, я постил некоторые из них на TechDays.ru пока ms зами на забили на эту платформу в угоду Channel9.

  • Я понял что мои видосы на YouTube не смотрит ровным счетом никто. 1к просмотров, где-то 2к подписчиков: хвастаться нечем. На yt вообще доход только от рекламы, а я подозреваю что у всех разработчиков стоит AdBlock.

  • В какой-то момент, я вышел на Pluralsight, и начал писать для них курсы. Completion fee (сколько денег платят за завершенный курс) для одного курса где-то $4k. Серьезно, 4к это больше разработческой зарплаты. Так что норм. Особенно если еще и работаешь.

  • Пассивный доход с ps был где-то в районе нуля. А потом один курс выстрелил. Причем самый нежданный. И понеслась.

  • Я сделал много видосиков для ps, а также рискнул сделать что-то на Udemy. К сожалению на Udemy у меня доход был где-то нуль, поэтому я на это подзабил.

  • В какой-то момент я решил выкладывать на Udemy все, что я изучаю в данный момент. Просто «в потоке». И постепенно оно начало более менее приносить.

  • Далее во времени, я насобачился маркетить в Udemy и вот тут уже пошел заметный love.

Вся эта ситуация немного патологична: я думал что все будут потреблять бесплатный контент, а получается что люди хотят видеть ценность, и поэтому ненулевой ценник для них — показатель качества.

Впрочем, я не против. Я когда делаю курсы, я делаю их хорошо. Очень хорошо. Качество везде. Иначе не выдержать конкуренции, да и вообще, самооценка, «ачивки» — это не только деньги (они уже не волнуют), это когда ты победил себя и поставил все точки над i. ■

Written by Dmitri

27 августа 2017 at 22:54

Опубликовано в Education

Использование ImpromptuInterface в реализациях паттернов проектирования

6 комментариев

Вы наверняка уже знаете, что если отнаследоваться от DynamicObject, можно получить разные плюшки от DLR, такие как например возможность вызывать методы класса даже если у класса их нет, и все такое. Но знаете ли вы что можно «вывесить» этот ваш DynamicObject как абсолютно любой интерфейс? Зачем это надо, спросите вы — ну, для того чтобы реализовывать всякие паттерны проектирования. Вот парочка примеров.

Как это работает?

После добавления NuGet пакета ImpromptuInterface, у вас появится extension-метод ActLike<T>(), который будет доступен на всех объектах типа object. Параметр T в данном случае – это именно тип интерфейса который хочется вывесить наружу.

За кулисами этого вызова создается, конечно же, динамическая прокся, которая является одновременно и проксёй для оригинального объекта и при этом реализует нужный интерфейс.

А теперь давайте посмотрим для чего это надо.

Паттерн Null Object

Самый простой пример — это паттерн Null Object, т.е. объект, который ровным счетом ничего не делает.

Вот например, у вас есть интерфейс логирования

public interface ILog
{
  void Info(string msg);
  void Warn(string msg);
}

Потом вы используете этот механизм в каком-то другом классе, например логируете операции с банковским счетом:

public class BankAccount
{
  private ILog log;
  private int balance;
  public BankAccount(ILog log)
  {
    this.log = log;
  }
  public void Deposit(int amount)
  {
    balance += amount;
    // check for null everywhere
    log?.Info($"Deposited ${amount}, balance is now {balance}");
  }
  public void Withdraw(int amount)
  {
    if (balance >= amount)
    {
      balance -= amount;
      log?.Info($"Withdrew ${amount}, we have ${balance} left");
    }
    else
    {
      log?.Warn($"Could not withdraw ${amount} because balance is only ${balance}");
    }
  }
}

Представьте теперь, что логирование вам нафиг не сдалось. Что делать? Передавать null нельзя, будут NRE везде где вызовы, ведь safe call operator ?. повсеместно разработчики, как правило, не используют. Ждем non-nullable types в C#8 или позже.

Один вариант — просто сделать фейковый класс:

public sealed class NullLog : ILog
{
  public void Info(string msg)
  {
    
  }
  public void Warn(string msg)
  {
    
  }
}

Это и есть «каноническая» реализация паттерна Null Object, но она получается легко только когда членов у класса мало, или же ReSharper под рукой. В целом, не хочется писать всю эту муть, особенно если вас не так сильно волнует перформанс.

Итак, третий, «ядерный» вариант с использование ImpromptuInterface. Делаем класс со следующей сигнатурой:

public class Null<T> : DynamicObject where T:class
{
  ⋮

T параметр выше – как раз тип интерфейса. Теперь можно сделать из класса этакий псевдо-singleton (на самом деле нет, создаем каждый раз):

⋮
public static T Instance 
{
  get
  {
    if (!typeof(T).IsInterface)
      throw new ArgumentException("I must be an interface type");
    return new Null<T>().ActLike<T>();
  }
}
⋮

Магия в том, что мы делаем Null<T>, сохраняя тип аргумента, но вывешиваем его не как Null<T> а просто как T.

А что дальше? Дальше нам нужно перехватывать вызовы методов, например:

  ⋮
  public override bool TryInvokeMember(InvokeMemberBinder binder, 
    object[] args, out object result)
  {
    result = Activator.CreateInstance(binder.ReturnType);
    return true;
  }
}

Код выше смотрит на тип возвращаемого значения метода и берет его дефолтную реализацию, т.е. вызывает new T() через System.Activator — это конечно же чревато тем, что если у класса нет дефолтного конструктора, то result будет равен null что очень грустно но не критично если вы не будете пытаться этим результатом пользоваться.

Вот собственно и всё, наш null object готов:

var log = Null<ILog>.Instance;
var ba = new BankAccount(log);
ba.Deposit(100); // логирования не будет

Динамическая Прокси

А теперь давайте представим «обратный» сценарий: у вас есть класс банковского счета, вы хотите добавить логирование «со стороны».

public interface IBankAccount
  {
    void Deposit(int amount);
    bool Withdraw(int amount);
    string ToString();
  }
  public class BankAccount : IBankAccount
  {
    private int balance;
    private int overdraftLimit = -500;
    public void Deposit(int amount)
    {
      balance += amount;
      WriteLine($"Deposited ${amount}, balance is now {balance}");
    }
    public bool Withdraw(int amount)
    {
      if (balance - amount >= overdraftLimit)
      {
        balance -= amount;
        WriteLine($"Withdrew ${amount}, balance is now {balance}");
        return true;
      }
      return false;
    }
    public override string ToString()
    {
      return $"{nameof(balance)}: {balance}";
    }
  }

Допустим что вы хотите логировать количество методов, которые вызываются на BankAccount. Для этого мы снова делаем динамическую проксю, только в этот раз мы уже агрегируем нужный нам объект:

public class Log<T> : DynamicObject where T : class, new()
{
  private readonly T subject;
  private Dictionary<string, int> methodCallCount =
    new Dictionary<string, int>();
  protected Log(T subject)
  {
    this.subject = subject;
  }
  ⋮

Далее можно сварганить фабричный метод, который будет делать тип Log<T> и выдывать его как интерфейс I. Например:

⋮
public static I As<I>() where I : class
{
  if (!typeof(I).IsInterface)
    throw new ArgumentException("I must be an interface type");
  return new Log<T>(new T()).ActLike<I>();
}
⋮

Теперь нам нужно сделать так, чтобы при вызове метода, метод-то вызывался, но кол-во методов тоже записывалось. Для этого нужно перегрузить TryInvokeMember():

⋮
public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
  try
  {
    // logging
    WriteLine($"Invoking {subject.GetType().Name}.{binder.Name} with arguments [{string.Join(",", args)}]");
    // more logging
    if (methodCallCount.ContainsKey(binder.Name)) methodCallCount[binder.Name]++;
    else methodCallCount.Add(binder.Name, 1);
    result = subject.GetType().GetMethod(binder.Name).Invoke(subject, args);
    return true;
  }
  catch
  {
    result = null;
    return false;
  }
}
⋮

Что делает код выше? Ну, помимо логирования количества вызовов, он через reflection вызывает нужный метод на объекте и сохраняет результат. Если вдруг падает исключение — что поделать, бывает, пишет в результат null, и всё.

Ну и наконец, если вам вдруг надо чтобы работал честный ToString() на объекте, но он декорировал существующий ToString() того типа, на котором ведется логирование, то это можно сделать вот так:

  ⋮
  public string Info
  {
    get
    {
      var sb = new StringBuilder();
      foreach (var kv in methodCallCount)
        sb.AppendLine($"{kv.Key} called {kv.Value} time(s)");
      return sb.ToString();
    }
  }
  
  // will not be proxied automatically
  public override string ToString()
  {
    return $"{Info}{subject}";
  }
}

Вот собственно и всё, теперь можно юзать вот эту проксю как-то вот так:

var ba = Log<BankAccount>.As<IBankAccount>();
ba.Deposit(100);
ba.Withdraw(50);
WriteLine(ba);

Заключение

Возможность вывесить любой интерфейс из DynamicObject-а бывает очень удобной. Идинственное что за эту возможность придется платить перформансом, так что класть это в продакшн или нет – решать вам. Но в тестировании бывает полезно.

Если вам интересны паттерны, у меня есть более 10 часов видосиков по паттернам в C#/.NET. Enjoy!

Written by Dmitri

4 мая 2017 at 12:41

Опубликовано в C#, Design Patterns

.NET-ный enum в стиле Rust

2 комментария

Как вы уже наверное знаете, у разных языков (C#, Java, Rust, …) понимание того что такое enum (перечисление) абсолютно разное. Иногда мне в C# хочется чтобы было как в Rust, да и в C++ тоже. Поэтому это рассказ про то, как сделать «хорошо» на примере C#.

Однородный тип

Давайте начнем. Например, чтобы писать

Color color = Color.Red;

нужно чтобы Color.Red имел тот же тип что и Color. То есть, если утрировать, можно и так написать:

public class Color
{
  private byte r, g, b, a;
  public Color(byte r, byte g, byte b, byte a)
  {
    this.r = r;
    this.g = g;
    this.b = b;
    this.a = a;
  }
  public static Color Red = new Color(255, 0, 0, 255);
}

Вопрос теперь только в том как генерить все это многообразие. В Rust ничего особо писать не надо, а в C#, как видите, нужно сделать очень много телодвижений. Но результат практически тот же.

Что-то мы потеряли, а что-то приобрели. Потеряли мы все Enum.GetValues(), т.е. возможность получить все предопределенные цвета. Как их вернуть? Ну наверное как-то вот так:

public static Color Red = new Color(255, 0, 0, 255);
public static Color Blue = new Color(0, 0, 255, 255);
public static Color[] Values = new[] {Red, Blue};

Что ещё продолбано? Ну, имена этих переменных. Ой! А вот это непросто будет сделать:

private BiDictionary<string, Color> colors = new BiDictionary<string, Color>
{
  ["Red"] = Red,
  ["Blue"] = Blue
};
public IEnumerable<string> Names => colors.Keys;
public IEnumerable<Color> Values => colors.Values;
public Color this[string name] => colors[name];
public string this[Color color] => colors.Reverse[color]; // возможно излишне?
private string ToStringImpl()
{
  return $"{nameof(r)}: {r}, {nameof(g)}: {g}, {nameof(b)}: {b}, {nameof(a)}: {a}";
}
public override string ToString()
{
  if (colors.Reverse.ContainsKey(this)) return colors.Reverse[this];
  return ToStringImpl();
}

BiDictionary как вы поняли – это словарь который работает в обе стороны, чтобы можно было быстро искать. Реализации подобного есть в тырнете, плюс самому на коленке написать тоже несложно.

Итак, всё ли мы реализовали? Да вроде да, можно использовать

Color red = Color.Red;
Color my = new Color(255, 0, 255, 0);

и вывод будет вот такой:

Red
r: 255, g: 0, b: 255, a: 0

Дискриминированное объединение

Пока все просто, давайте пример посложнее уже. Типичный пример вычисления со всякой неоднородной начинкой выглядит как-то так:

type IntOrBool =
  | Boolean of bool
  | Integer of int // это не раст, это F#

Ха! То есть смотрите, у вас есть два абсолютно разных типа, с разными данными, и они должны приводиться к некому типу IntOrBool. Первое что приходит в голову — это абстрактный класс вроде

public abstract class IntOrBool
{
  public int Tag => this is Integer ? 0 : 1;
  public bool IsInteger => this is Integer;
  public bool IsBoolean => this is Boolean;
  public static Boolean NewBoolean(bool value) => new Boolean(value);
  public static Integer NewInteger(int value) => new Integer(value);
}

Ну и соответственно каждый из наследников должен выглядеть как-то вот так:

public class Integer : IntOrBool
{
  public int Value { get; set; }
  public Integer(int value)
  {
    Value = value;
  }
  // делаем вид что мы int
  public static implicit operator Integer(int value)
  {
    return new Integer(value);
  }
  public static implicit operator int(Integer integer)
  {
    return integer.Value;
  }
}

Но дальше у нас те же проблемы что и ранее — как сделать ToString(), как вывести список всех возможных типов объединения? Мы точно знаем как это делает F# — он для этого использует атрибуты, и по сути поиск всех классов превращается в использование Reflection. Что уныло. А что если сделать вот так?

public static Type[] Cases = new[] {typeof(Boolean), typeof(Integer)};

В конечном счете, что мы теряем? Ладно, пора уже попробовать использовать все это в типичном (насколько это возможно для такого синтетического примера) сценарии:

IntOrBool foo = 0; // FAIL :(

Опа, уже нифига не работает. Хотели удобство а получилось не очень. Что, еще операторов? Пожалуйста

public static implicit operator IntOrBool(int value) => NewInteger(value);
public static implicit operator IntOrBool(bool value) => NewBoolean(value);

ок, теперь можно инициализировать, а можно ли проверять if-ом?

IntOrBool foo = 0;
if (foo is Integer bar)
{
  int i = bar;
  WriteLine(i);
}

Кривоватенько, но работает. foo is int bar конечно же писать нельзя. Ну и выборку по шаблону в стиле case Integer(i) пока тоже в C# не сделали.

Да, насчет ToString() — тут будет просто GetType().ToString() для кейсов у которых нет собственных данных. То есть будут порождаться типы даже там, где они не нужны. Для F# это как бы норма (в F# например, любой переданный оператор превращается в struct), но в C# это не очень хорошо, хотя опять же, ничего критичного.

Вообщем вот такой финт ушами, не дающий особых плющек, т.к. ко всему этому нужен умный switch и полноценный pattern matching. Да, и Deconstruct(), если вы его реализуете, не поможет для типов которые имеют один member. Сорри! ■

Written by Dmitri

14 апреля 2017 at 0:47

Опубликовано в C#

Tagged with