День триста шестнадцатый. #DesignPatterns
Паттерны проектирования
2. Паттерн «Шаблонный метод» (Template Method). Начало
Шаблонный метод — это один из классических паттернов, который и по сей день используется в каноническом виде во многих приложениях. Он позволяет четко определить «контракт» между базовым классом и потомками.
Назначение: шаблонный метод определяет основу алгоритма и позволяет подклассам переопределять некоторые шаги алгоритма, не изменяя его структуры. То есть каркас, в который наследники могут подставить реализации недостающих элементов.
Причины использования:
Необходимость определить порядок действий, которому потомки должны строго следовать. Вместо дублирования логики в потомках можно описать основные шаги алгоритма в базовом классе и отложить реализацию конкретных шагов до момента реализации в потомках.
Классическая диаграмма приведена на рисунке ниже:
- AbstractClass — определяет невиртуальный метод TemplateMethod, который вызывает внутри себя примитивные операции PrimitiveOperation1(), PrimitiveOperation2() и т. д.;
- ConcreteClass — реализует примитивные шаги алгоритма.

Варианты реализации в .NET
1. Локальный шаблонный метод на основе делегатов
В некоторых случаях использование классического варианта шаблонного метода с наследованием является слишком тяжеловесным решением, поэтому в таких случаях переменный шаг алгоритма задается делегатом. Это устраняет дублирование кода и довольно часто применяется в современных .NET-приложениях, например, в WCF-сервисах.
Подход на основе делегатов может не только применяться для определения локальных действий внутри класса, но и передаваться извне другому объекту в аргументах конструктора.
2. Шаблонный метод на основе методов расширения
Реализация шаблонного метода в виде метода расширения для базового класса позволяет разгрузить базовый класс, убрав лишнюю функциональность (например, не соответствующую основной абстракции класса). Кроме того, класс и его методы расширения могут находиться в разных пространствах имен. Это позволит клиентам самостоятельно решать, нужно ли им импортировать метод расширения или нет (следование принципу разделения интерфейса). Также существует возможность разных реализаций метода в зависимости от контекста и потребностей. Например, метод может иметь одну реализацию в серверной части кода, а другую — в клиентской.
У этого подхода есть и недостатки:
- Переменные шаги алгоритма должны определяться открытыми методами.
- Может потребоваться приведение к конкретным типам наследников, если не вся информация доступна через базовый класс.

Продолжение следует…

Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 2.

День триста семнадцатый. #DesignPatterns
Паттерны проектирования
2. Паттерн «Шаблонный метод» (Template Method). Окончание
Шаблонный метод и обеспечение тестируемости
Типичным подходом для обеспечения тестируемости является использование интерфейсов. Определённое поведение, завязанное на внешнее окружение, выделяется в отдельный интерфейс, и затем интерфейс передается текущему классу. Затем с помощью mock-объектов можно эмулировать внешнее окружение и покрыть класс тестами в изоляции.
Однако, если у вас есть готовый класс (в легаси коде), можно воспользоваться разновидностью паттерна «Шаблонный метод» под названием «Выделение и переопределение» (Extract and Override). Я уже упоминал этот приём в посте про методы рефакторинга унаследованного (легаси) кода.
Суть техники заключается в выделении изменчивого поведения в виртуальный метод, поведение которого затем можно переопределить в тестовой среде.

public class PersonRepo {
  protected virtual IEnumerable<Person> GetPeople() {
    // получение данных из БД
  }
  // остальные методы
}

// В тестах
class FakePersonRepo : PersonRepo {
  // создаём mock-объект в personData
  // и наполняем его «данными»
  private readonly List<Person> personData = …;

  protected override IEnumerable<Person> GetPeople() {
    return personData;
  }
}

Далее можно тестировать остальные методы класса PersonRepo, получающие данные от GetPeople, используя объект FakePersonRepo. Однако, стоит иметь в виду, что даже при наличии тестов всей остальной функциональности через FakePersonRepo, класс PersonRepo не может считаться полностью протестированным. Сам исходный метод GetPeople также может приводить к ошибкам.

Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 2.

День триста восемнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
14. Обзоры Кода
Вы должны делать обзоры кода. Зачем? Потому что они повышают качество кода и снижают процент ошибок. Но не обязательно по тем причинам, о которых вы могли бы подумать.
Многие программисты не любят обзоры кода, из-за негативного опыта в прошлом. Я встречал организации, которые требовали, чтобы весь код проходил официальную проверку перед развёртыванием. Часто этот обзор выполнял архитектор или ведущий разработчик, и эту практику можно охарактеризовать как анализ архитектором всего на свете. Это было прописано в руководстве по процессу разработки ПО в компании, поэтому программисты должны были следовать ему.
Может быть, некоторым организацям нужен такой жесткий и формальный процесс, но большинству нет. В большинстве организаций такой подход контрпродуктивен. Рецензируемые могут чувствовать себя как на комиссии по условно-досрочному освобождению. Рецензентам требуется время, как на чтение кода, так и на то, чтобы быть в курсе всех деталей системы. Они могут быстро оказаться узким местом всего процесса, и смысл такого обзора быстро теряется.
Вместо того, чтобы просто исправлять ошибки в коде, целью обзоров кода должен быть обмен знаниями и установление общих правил кодирования. Совместное использование вашего кода с другими программистами приводит к коллективному владению кодом. Пусть случайный член команды пройдется по коду с остальной командой. Вместо того, чтобы искать ошибки, лучше просмотреть код, пытаясь изучить и понять его.
Будьте вежливы при проверке кода. Убедитесь, что ваши комментарии конструктивные, а не язвительные. Введите разные роли для обзорного собрания, чтобы избежать влияния субординации среди членов команды на проверку кода. Например, один рецензент может сосредоточиться на документации, другой - на исключениях, а третий - на функциональности. Такой подход помогает распределить бремя проверки между членами команды.
Проводите регулярные обзоры кода каждую неделю. Потратьте пару часов на обзорную встречу. Меняйте рецензируемого каждый раз просто по очереди. Не забывайте менять роли между членами команды на каждой обзорной встрече. Вовлекайте новичков. Они могут быть неопытными, но у них свежие университетские знания, и они могут предложить иную точку зрения. Привлекайте экспертов из-за их опыта и знаний. Они будут выявлять подверженный ошибкам код быстрее и с большей точностью. Обзор кода будет проходить легче, если у команды есть соглашения по кодированию, которые проверяются автоматически. Таким образом, форматирование кода никогда не будет обсуждаться на обзорах.
Пожалуй, самый важный фактор успеха – делать обзоры кода весёлыми. Главные в обзорах – люди, а не код. Если обзор будет болезненным или скучным, мотивировать кого-то будет сложно. Сделайте его неформальным, основной целью которого является обмен знаниями между членами команды. Оставьте саркастические комментарии снаружи, и вместо этого принесите туда кофе и печеньки.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Mattias Karlsson

День триста девятнадцатый. #DesignPatterns
Паттерны проектирования
3. Паттерн «Посредник» (Mediator).
Посредник — это один из самых распространённых паттернов проектирования. Они десятками используются в любом приложении, хотя в именах классов это практически никогда не отражается.
Назначение: определяет объект, инкапсулирующий способ взаимодействия множества объектов. Другими словами, он связывает несколько независимых классов между собой, избавляя классы от необходимости ссылаться друг на друга и позволяя тем самым их независимо изменять и анализировать.
Причины использования:
Паттерн «Посредник» идеально подходит для объединения нескольких автономных классов или компонентов. Каждый раз, когда вы задаётесь вопросом, как изолировать классы А и Б, чтобы они могли жить независимо, подумайте об использовании посредника. В этом случае посредник будет содержать всю логику взаимодействия классов. Кроме того, посредник выступает барьером, который гасит изменения в одной части системы, не давая им распространяться на другие части. Любые изменения в одном компоненте приведут к модификации его и, возможно, посредника, но не потребуют изменений в другом компоненте или его клиентах.
Замечание: Не нужно разделять с помощью посредника тесно связанные вещи. Если классы всегда изменяются совместно, то, возможно, они должны знать друг о друге. Наличие посредника лишь усложнит внесение изменений: вместо изменения двух классов придется изменять три.
Классическая диаграмма приведена в верхней части рисунка ниже:
- Mediator — определяет интерфейс посредника. На практике базовый класс посредника выделяется редко, поэтому класс Mediator обычно содержит всю логику взаимодействия;
- ConcreteCollegue1, ConcreteCollegue2 — классы одного уровня абстракции, которые взаимодействуют друг с другом косвенным образом через посредника.
Обычно взаимодействующие компоненты не содержат общего предка (если не считать класса object) и совсем не обязательно знают о классе-посреднике. Иерархия посредников также применяется довольно редко.

Явный и неявный посредник
В классической реализации паттерна независимые классы не знают друг о друге, но знают о существовании посредника и всё взаимодействие происходит через него явным образом. Такой подход применяется в паттернах «Поставщик/Потребитель» (Producer/Consumer), «Агрегатор событий» (Event Aggregator) или в других случаях, когда классы знают о существовании общей шины взаимодействия. В то же время классы низкого уровня могут и не знать о существовании посредника. Это делает их более автономными, а дизайн — более естественным. Логика взаимодействия в этом случае содержится в посреднике. См. диаграмму в нижней части рисунка ниже.

Архитектурные посредники
Паттерн «Посредник» может применяться на разных уровнях приложения. Существуют классы-посредники, компоненты-посредники, есть целые модули или слои приложения, выполняющие эту роль.

Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 3.

День триста двадцатый. #ЧтоНовенького
Улучшения в Поиске по Файлам
Поиск по Файлам (Find in Files) - это одна из наиболее часто используемых функций в Visual Studio. В Microsoft решили переписать её с нуля. Улучшенный функционал будет доступен в Visual Studio 2019 версии 16.5 Preview 1 в быстром поиске (Ctrl+Q), а также в инструментах «Найти в файлах» (Ctrl+Shift+F) и «Заменить в файлах» (Ctrl+Shift+H). Поиск полностью реализован на C#, что позволило избежать ненужных вызовов, снизило потребление памяти и повысило производительность. См. скриншот ниже.

Указание путей
В поле «Поиск в» (Look in) появилась новая опция «Текущий Каталог» (Current Directory) для поиска в папке, содержащей открытый в данный момент документ. Также можно включить прочие файлы (не являющиеся частью решения). В поле «Типы файлов» (File types) теперь можно исключать файлы. Любой путь или тип файла с префиксом «!» будет исключён из поиска.

Множественный поиск
Возможность сохранять результаты предыдущих поисков уже была в Visual Studio и продолжает поддерживаться с помощью кнопки «Сохранить результаты» (Keep Results). В настоящее время эта функция поддерживает до пяти результатов поиска. Если у вас уже есть пять результатов поиска, при следующем поиске будет повторно использована самая старая вкладка результатов. Также кнопка «Сохранить результаты» доступна для функции «Найти все ссылки» (Find All References).

Конструктор регулярных выражений
В версии 16.5 Preview 2 будет доступен конструктор регулярных выражений. Флажок «Использовать регулярные выражения» (Use regular expressions) позволит вам указать регулярное выражение в качестве шаблона для совпадения (например, для поиска многострочных выражений). Также будет доступен конструктор регулярных выражений, который выдаст несколько примеров и ссылку на документацию.

Источник: https://devblogs.microsoft.com/visualstudio/modernizing-find-in-files/

День триста двадцать первый. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
Async/await были добавлены в .NET более 7 лет назад. За это время было выпущено множество улучшений в инфраструктуре, дополнительных языковых конструкций, API-интерфейсов. Однако один из аспектов async/await, который продолжает вызывать вопросы, - это ConfigureAwait. В серии постов #AsyncAwaitFAQ мы ответим на несколько наиболее часто задаваемых вопросов про контекст синхронизации в async/await.
1. Что такое контекст синхронизации?
Документация по System.Threading.SynchronizationContext утверждает, что он «обеспечивает базовую функциональность для распространения контекста синхронизации в различных моделях синхронизации». Не совсем понятное описание.
В 99,9% случаев SynchronizationContext - это тип, который предоставляет виртуальный метод Post, принимающий делегат для асинхронного выполнения (в SynchronizationContext есть множество других виртуальных членов, но они гораздо реже используются). Метод Post базового типа просто вызывает ThreadPool.QueueUserWorkItem для асинхронного вызова предоставленного делегата. Однако производные типы переопределяют метод Post, чтобы разрешить выполнение этого делегата в наиболее подходящем месте и в наиболее подходящее время.
В Windows Forms переопределённый метод Post, создаёт эквивалент Control.BeginInvoke. То есть любые вызовы метода Post приведут к тому, что делегат будет вызван позже в потоке, связанном с этим элементом управления, т.е. в UI-потоке. Windows Forms полагается на обработку сообщений Win32 и имеет «цикл сообщений», работающий в UI-потоке, который просто ожидает поступления новых сообщений для обработки (движения и щелчки мыши, ввод с клавиатур, системные события, делегаты и т. д.). Таким образом, имея экземпляр SynchronizationContext для UI-потока приложения Windows Forms, чтобы получить делегат для выполнения в UI-потоке, просто нужно передать его в Post.
WPF имеет свой собственный производный от SynchronizationContext тип с переопределённым Post, который аналогично «маршализирует» делегат в UI-поток (через Dispatcher.BeginInvoke), в данном случае управляемый диспетчером WPF, а не элементом управления Windows Forms.
В Windows RunTime (WinRT) переопределённый метод Post, также ставит делегат в очередь UI-потока через CoreDispatcher.
Это выходит за рамки простого «запуска этого делегата в UI-потоке». Любой может реализовать SynchronizationContext с методом Post, который делает всё что угодно.
Преимуществом такого подхода в том, что он предоставляет единый API, который можно использовать для постановки в очередь делегата для обработки, как того пожелает создатель реализации, без необходимости знать детали этой реализации. Итак, если я пишу библиотеку, и я хочу асинхронно выполнить некоторую работу, а затем поставить делегат в очередь обратно в «контекст» исходного местоположения, мне просто нужно захватить SynchronizationContext, сохранить его, а затем, когда я закончу свою работу, вызвать Post в этом контексте и передать делегат, который я хочу вызвать. Мне не нужно знать, что для Windows Forms я должен взять Control и использовать его BeginInvoke, или для WPF я должен взять Dispatcher и использовать его BeginInvoke, и т.п. Мне просто нужно взять текущий SynchronizationContext и использовать его позже. Чтобы достичь этого, SynchronizationContext предоставляет свойство Current, так что для достижения вышеупомянутой цели можно написать такой код:

public void DoWork(Action worker, Action completion)
{
  SynchronizationContext sc = SynchronizationContext.Current;
  ThreadPool.QueueUserWorkItem(_ =>
  {
    try { worker(); }
    finally { sc.Post(_ => completion(), null); }
  });
}

Платформа, которая хочет предоставить свой контекст в свойстве Current, использует метод SynchronizationContext.SetSynchronizationContext.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/

День триста двадцать второй. #ЧтоНовенького
Наткнулся (как обычно) в ютубе на следующее видео серии Visual Studio Toolbox. Новый фреймворк (привет Javascript) для .Net позволяет писать мультиплатформенный код на C# и XAML, который с минимальными доработками можно запускать на Windows (естественно), Android, iOS и даже запускать как веб-приложение на основе WebAssembly.
В решении создаётся сразу 5 проектов: с общим кодом, где будет 95% логики, формы XAML и файлы ресурсов, а также проекты под каждую платформу. Можно использовать как один интерфейс под все платформы, так и настроить его под родные элементы для каждой платформы. Более того, все приложения (включая веб) могут подстраиваться под тему, установленную на устройстве.
Конечно, пока есть некоторый скепсис по поводу того, что это (а тем более что-то более сложное) действительно будет безшовно и бескостыльно работать на всех платформах, но пока выглядит довольно впечатляюще.

Источник (на английском): https://www.youtube.com/watch?v=fyo2BI4rn0g

День триста двадцать третий. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
2. Что такое планировщик задач?
Планировщик задач (TaskScheduler) представляет собой объект, выполняющий низкоуровневую работу с очередями в потоках. Он гарантирует, что работа в задаче рано или поздно будет выполнена.
Когда задачи представляют из себя делегаты, которые могут быть поставлены в очередь и выполнены, они связываются с System.Threading.Tasks.TaskScheduler. Так же, как SynchronizationContext предоставляет виртуальный метод Post для постановки в очередь вызова делегата (с реализацией, позже вызывающей делегат с помощью типичных механизмов вызова делегата), TaskScheduler предоставляет абстрактный метод QueueTask (с реализацией, позже вызывающей эту задачу через метод ExecuteTask).
Класс TaskScheduler также служит точкой расширения для всей настраиваемой логики планирования. Планировщик по умолчанию, возвращаемый TaskScheduler.Default, является пулом потоков, но можно унаследовать от TaskScheduler и переопределить соответствующие методы для изменения того, когда и где вызывается Task. Например, в базовых библиотеках есть тип System.Threading.Tasks.ConcurrentExclusiveSchedulerPair. Экземпляр этого класса предоставляет два свойства типа TaskScheduler: ExclusiveScheduler и ConcurrentScheduler. Задачи, запланированные через ConcurrentScheduler, могут выполняться одновременно, но до определённого предела, назначенного ConcurrentExclusiveSchedulerPair при его создании. Но никакие задачи ConcurrentScheduler не будут выполняться, когда выполняется задача, запланированная для ExclusiveScheduler, в котором только одна задача может выполняться в определённый момент времени. Таким образом, поведение ExclusiveScheduler очень похоже на блокировку чтения/записи.
Как и SynchronizationContext, TaskScheduler также имеет свойство Current, которое возвращает «текущий» TaskScheduler. Однако, в отличие от SynchronizationContext, здесь нет способа установки текущего планировщика. Вместо этого текущий планировщик - тот, который связан с текущей выполняющейся задачей, и он предоставляется системе как часть процесса запуска задачи. Так, например, следующая программа выведет «True», так как лямбда-выражение в StartNew выполняется в ExclusiveScheduler объекта ConcurrentExclusiveSchedulerPair, и оно «увидит», что на этот планировщик установлен TaskScheduler.Current:

using System;
using System.Threading.Tasks;
class Program {
  static void Main() {
    var cesp = new ConcurrentExclusiveSchedulerPair();
    Task.Factory.StartNew(() => {
        Console.WriteLine(TaskScheduler.Current == cesp.ExclusiveScheduler);
    }, default, TaskCreationOptions.None, cesp.ExclusiveScheduler).Wait();
  }
}

TaskScheduler также предоставляет статический метод FromCurrentSynchronizationContext, возвращающий новый TaskScheduler, связанный с SynchronizationContext.Current. Все экземпляры Task, поставленные в очередь возвращённого планировщика, будут выполнены с помощью вызова метода Post в этом контексте.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/

День триста двадцать четвёртый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
15. Программируйте Осознанно
Попытка обосновать правильность кода вручную приводит к формальному доказательству, которое длиннее кода и с большей вероятностью содержит ошибки. Автоматизированные инструменты предпочтительнее, но не всегда возможны. Далее описано промежуточное решение: полуформальное определение правильности кода.
Основная идея в том, чтобы разделить весь рассматриваемый код на короткие секции - от одной строки, например, вызова функции, до блоков длиной менее 10 строк - и аргументировать их правильность. Аргументы должны быть достаточно убедительными, например, для коллеги-программиста, который будет играть роль вашего оппонента.
Блок должен быть выбран так, чтобы:
1. В каждой конечной точке состояние программы (счетчик программы и состояния всех «живых» объектов) удовлетворяло легко описываемому свойству.
2. Функциональность этого блока (преобразование состояния программы) можно легко описать как одну задачу.
Эти рекомендации упростят процесс обоснования правильности. Эти свойства конечных точек обобщают такие понятия, как пред- и постусловия для функций и инварианты для тел циклов и экземпляров классов. Стремление к тому, чтобы блоки были максимально независимы друг от друга, упрощает обоснование их правильности и необходимо для лёгкого изменения этих блоков.
Многие из хороших практик кодирования, которые хорошо известны (хотя, возможно, не так хорошо соблюдаются), облегчают обоснование правильности. Следовательно, просто попытавшись обосновать правильность своего кода, вы уже начинаете двигаться к хорошему стилю и структуре кода. Неудивительно, что большинство из этих практик могут быть проверены статическими анализаторами кода:
1. Избегайте операторов goto, так как они делают удаленные друг от друга блоки сильно связанными.
2. Избегайте изменяемых глобальных переменных, поскольку они делают все блоки, которые их используют, зависимыми.
3. Каждая переменная должна иметь наименьшую возможную область видимости. Например, локальный объект может быть объявлен непосредственно перед его первым использованием.
4. Делайте объекты неизменяемыми, когда это уместно.
5. Делайте код читаемым, используя отступы (как горизонтальные, так и вертикальные), например, выравнивая связанные структуры и используя пустую строку для разделения блоков.
6. Делайте код самодокументируемым, выбрав описательные (но относительно короткие) имена для объектов, типов, методов и т. д.
7. Если вам нужен вложенный блок, сделайте его методом.
8. Делайте свои функции короткими и сфокусированными на одной задаче. Старый лимит в 24 строки всё ещё актуален. Хотя размер экрана и разрешение изменились с 1960-х годов, способность человека воспринимать информацию осталась той же.
9. Функции должны иметь ограниченное число параметров (четыре - хорошая верхняя граница). Это не ограничивает количество данных, передаваемых функциям: группируйте связанные параметры в единый объект, что упростит понимание их связанности и согласованности.
10. В более общем смысле каждая единица кода, от блока до библиотеки, должна иметь минимальный интерфейс. Чем меньше связей блока с другими блоками, тем меньше требуется обосновывать правильность его работы. Это означает, что аксессоры (get) свойств объекта увеличивают его сложность. Не запрашивайте информацию у объекта для её обработки. Вместо этого попросите объект обработать уже имеющуюся у него информацию. Инкапсуляция – лучшее средство для минимализации интерфейсов.
11. Чтобы сохранить инварианты класса, не рекомендуется использовать мутаторы (set). Они, как правило, допускают нарушение инвариантов, управляющих состоянием объекта.

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yechiel Kimchi

День триста двадцать пятый. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
3. Как SynchronizationContext и TaskScheduler связаны с await?
Представьте кнопку в приложении. Нажав на кнопку, мы хотим загрузить текст с веб-сайта и установить его в качестве текста кнопки. Доступ к кнопке возможен только из UI-потока, которому она принадлежит, поэтому, когда мы успешно загрузили новый текст и хотим установить его как текст кнопки, мы должны сделать это из потока, которому принадлежит элемент управления (из UI-потока). Если мы этого не сделаем, мы получим исключение:

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.' (Вызывающий поток не может получить доступ к этому объекту, поскольку он принадлежит другому потоку).

Если бы мы писали это вручную, мы могли бы использовать SynchronizationContext, чтобы выполнить установку текста в исходном контексте, например через TaskScheduler:

private static readonly HttpClient сlient = new HttpClient();
private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
   сlient.GetStringAsync("https://example.com/gettext")
    .ContinueWith(downloadTask => {
        downloadBtn.Text = downloadTask.Result;
    }, TaskScheduler.FromCurrentSynchronizationContext());
}

Либо можно напрямую использовать SynchronizationContext:

private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
  SynchronizationContext sc = SynchronizationContext.Current;
  сlient.GetStringAsync("https://example.com/gettext")
    .ContinueWith(downloadTask => {
      sc.Post(delegate {
        downloadBtn.Text = downloadTask.Result;
      }, null);
    });
}

Однако оба этих подхода явно используют функции обратного вызова. Вместо этого мы можем написать код естественным образом с помощью async/await:

private async void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    string text = await сlient.GetStringAsync("https://example.com/gettext");
    downloadBtn.Text = text;
}

Этот код «просто работает», успешно устанавливая текст в UI-потоке, потому что, как и в случае с вручную реализованными версиями выше, ожидание задачи по умолчанию запоминает текущий контекст (SynchronizationContext.Current) или текущий планировщик (TaskScheduler.Current).
Когда вы ожидаете чего-либо в C#, компилятор использует паттерн awaitable и просит «ожидаемый» (awaitable) объект (в данном случае Task) предоставить ему объект «ожидателя» (awaiter) – в данном случае TaskAwaiter<string>. Этот «ожидатель» отвечает за создание метода обратного вызова (часто называемого «продолжением»), который «вернёт выполнение в исходный код» после того, как задача завершит работу. И делает он это с захватом текущего контекста/планировщика. В упрощённом виде это выглядит так:

object scheduler = SynchronizationContext.Current;
if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default)
{
  scheduler = TaskScheduler.Current;
}

Другими словами, сначала проверяется, установлен ли SynchronizationContext, и, если нет, установлен ли «нестандартный» TaskScheduler. Если таким образом контекст/планировщик будет захвачен, он будет использован для выполнения метода обратного вызова соответственно в контексте или через планировщик. В противном случае чаще всего метод обратного вызова выполнится в том же контексте, что и ожидаемая задача.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Друзья. Маленькое дополнение к сегодняшнему посту.
Мой канал участвует в конкурсе для авторов в сфере IT. Поэтому, если вам нравится, что я делаю, пожалуйста, поддержите меня.

https://tproger.ru/best-it-media-2019-user-voting/
(найти в списке можно просто поиском по "Net Разработчик")

Спасибо, что читаете.

День триста двадцать шестой. #DesignPatterns
Паттерны проектирования
4. Паттерн «Итератор» (Iterator).
Практически любое приложение в той или иной мере работает с коллекциями данных. В некоторых случаях для обработки данных коллекции используется специфический интерфейс конкретных коллекций, но в большинстве случаев доступ к элементам осуществляется через специальный абстрактный слой — итератор.
Назначение: Итераторы предоставляют абстрактный интерфейс для доступа к содержимому составных объектов, не раскрывая клиентам их внутреннюю структуру. В результате получается чёткое разделение ответственности: клиенты получают возможность работать с разными коллекциями унифицированным образом, а классы коллекций становятся проще за счёт того, что ответственность за перебор элементов возлагается на отдельную сущность.
Классическая схема паттерна «Итератор» и реализация паттерна в .Net представлены на рисунке ниже:
- Iterator (IEnumerator<T>) — определяет интерфейс итератора. В .Net имеет методы: MoveNext (переход на следующий элемент, возвращает false, если достигнут конец последовательности), Current (возвращает текущий элемент) и Reset (возвращает итератор к началу коллекции, реализуется не всегда).
- Aggregate (IEnumerable<T>) — коллекция, по которой может
перемещаться итератор. В .Net интерфейс имеет единственный метод GetEnumerator для получения экземпляра итератора.
- ConcreteAggregate1 (List<T>) — конкретная реализация коллекции;
- ConcreteIterator (List<T>.Enumerator) — конкретная реализация
итератора для определённой коллекции.
Итераторы в .NET являются однонаправленными и только для чтения. То есть при изменении коллекции последующий вызов MoveNext итератора выбросит InvalidOperationException. По той же причине нельзя изменять элементы коллекции в цикле foreach. Цикл foreach является универсальным инструментом для обработки коллекций/последовательностей. Компилятор преобразует его в (в упрощённом варианте) вызов метода MoveNext и обращение к свойству Current в цикле while. Для поддержки цикла foreach не обязательно наличие интерфейса IEnumerable. Достаточно, чтобы класс коллекции содержал метод GetEnumerator, который будет возвращать тип с методом MoveNext, возвращающим bool, и свойством Current.

Блоки итераторов
Процесс создания итераторов вручную довольно утомителен и включает управление состоянием и перемещением по элементам коллекции при вызове MoveNext. С помощью блока итераторов реализовать итератор существенно проще:

public static IEnumerator<int> CustomArrayIterator(this int[] array) {
  foreach (var n in array) { yield return n; }
}

Блок итераторов преобразуется компилятором языка C# в конечный автомат с несколькими состояниями, соответствующими начальному положению итератора (когда он указывает на –1-й элемент), конечному положению (когда итератор прошёл все элементы) и «среднему» положению, при котором он указывает на определённый элемент.
С помощью блока итераторов можно создавать итераторы для своих коллекций, существующих коллекций или вообще для внешних ресурсов, таких как файлы. Для этого достаточно открыть файл в начале метода и возвращать прочитанные блоки данных с помощью yield return.
Итераторы, полученные с помощью блока итераторов, являются «ленивыми»: их тело исполняется не в момент вызова метода, а при переборе элементов с помощью метода MoveNext.
Кроме того, блоки итераторов можно использовать для создания генераторов последовательностей. Например, «бесконечного» генератора чисел Фибоначчи.

Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 4.

День триста двадцать седьмой. #Оффтоп
Все выходные зависал на Codewars. Не то, чтобы я не знал раньше об этом сайте, просто как-то не доходили руки. А тут, как обычно, наткнулся в ютубе на видео парня, который работает в Гугле. Так вот, он рассказывал про то, как попал в Гугл, начав кодить за полгода до этого. Да, я тоже сначала не поверил, пока он не показал свой рейтинг на Codewars в почти 4500. Впрочем, про этого парня чуть позже напишу. А пока я решил проверить, насколько тяжело столько набрать.
Я уже писал про подобный сайт. Проблема в том, что там тебе сначала даются элементарные задачи, которые «щёлкаешь» и вроде даже входишь в раж, но в итоге их столько, что это быстро надоедает. Понятно, что начинающим это помогает «набить руку», но опытным после дцатой задачи на поиск элемента в массиве становится скучно. А поскольку прогресс построен на «пути от простого к сложному», то сложные задачи закрыты, пока не решены простые. Поэтому я заниматься там как-то быстро забросил. Да и Codewars тоже не спешил пробовать по этой же причине: пока доберёшься до интересных заданий, потратишь кучу времени.
Однако, всё оказалось совсем не так. При регистрации можно указать свой уровень: начинающий/джун/мидл/сениор, - и задачи выдаются соответственно уровню. То есть рейтинг то твой, конечно, сначала нулевой, и самый низкий 8kuy (ку? кю? куй?) уровень, короче, но задачи система даёт уже не элементарные, а чуть более сложные, и можно быстро добраться до более высокого уровня и более интересных задач. Кроме того, можно в принципе взять любую задачу любого уровня (хоть самого высокого 1го) и решать её.
Задачи построены по методу разработки через тестирование. Вам даётся задача и открытый список из 2-3 тестов, которые программа должна пройти, и собственно поле для написания кода. Хотя, без IntelliCode и автоформатирования писать там довольно грустно, поэтому писал в VS, а потом туда копировал. Да, испорчен, признаю. Что интересно, после этого можно попытаться отправить своё решение, и тогда код будет протестирован расширенным списком тестов, которые от вас скрыты. То есть вы не видите, что не так, просто факт, что какой-то тест выдал false вместо true. Это позволяет не подгонять решение под ответ, а действительно решать задачу.
За выходные набрал 185 баллов рейтинга и дошёл до 6 уровня. На задачи, как мне кажется, я тратил уйму времени. Дело в том, что в веб-разработке, которой я занимаюсь, довольно редко приходится развивать «мелкую моторику» (парсить строки, работать с байтами, писать низкоуровневые алгоритмы и т.п.). Зачастую это всё уже давно решено, написано в библиотеках, и ты просто вызываешь метод одной библиотеки, второй библиотеки, коллекции обрабатываешь LINQом и складываешь приложение, как паззл. А тут приходится попотеть: например, написать упрощённый интерпретатор для языка BrainFuck или разбить квадрат числа на сумму квадратов. И оказывается, что то, чем редко пользуешься, забывается очень быстро. Так что поставил себе цель периодически практиковаться там, а то даже стыдно перед собой.

Кстати, если вы ищете, какую бы программу написать себе для портфолио или просто для практики, Codewars, по-моему, идеальный вариант. Берёте задания 1-2го уровня – а это зачастую уже полноценные приложения - и вперёд. Языков программирования там, кстати, целая куча, поэтому подкачать скиллы можно почти в любом. А вот сам сайт, конечно, только на английском.

День триста двадцать восьмой. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
4. Что делает ConfigureAwait(false)?
Метод ConfigureAwait, принимающий параметр continueOnCapturedContext («продолжитьВЗахваченномКонтексте»), возвращает структуру ConfiguredTaskAwaitable, которая содержит специальным образом настроенный «ожидатель» (awaiter). Поскольку await может использоваться с любым типом, соответствующим паттерну awaitable (не только с Task напрямую), возврат другого типа вместо задачи позволяет изменить логику захвата контекста/планировщика (см. предыдущий пост) на что-то вроде этого:

object scheduler = null;
if (continueOnCapturedContext)
{
  // захват контекста/планировщика
}

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

Зачем использовать ConfigureAwait(false)?
Этот метод используется, чтобы избежать принудительного вызова метода обратного вызова в исходном контексте или планировщике. Это даёт несколько преимуществ:
1. Улучшает производительность. Требуется дополнительная работа, чтобы поставить в очередь метод обратного вызова вместо того, чтобы просто вызывать его. Кроме того, некоторые оптимизации времени выполнения, не могут быть использованы. Иногда даже проверка текущих контекста и планировщика (что включает в себя доступ к статическим потокам) могут добавить измеримые накладные расходы. Если код после await фактически не требует запуска в исходном контексте, использование ConfigureAwait(false) поможет избежать всех этих затрат.
2. Позволяет избежать взаимных блокировок. Взаимная блокировка чаще всего возникает при использовании кода, блокирующего текущий поток (при вызове .Wait(), .Result или .GetAwaiter().GetResult() на задаче, внутри которой используется await). Если в текущем контексте явно или неявно ограничено число параллельных операций, либо если код блокирует UI-поток, получается ситуация, когда контекст/поток заблокирован в ожидании завершения асинхронной задачи, а метод обратного вызова этой задачи ставится в очередь для вызова на заблокированном контексте/потоке и поэтому не может быть выполнен (взаимная блокировка). Такая ситуация может возникать, когда ресурсы ограничены любым способом и так или иначе оказываются заняты. Если задача использует ConfigureAwait(false), метод обратного вызова не ставится в очередь в исходный контекст, что позволяет избежать сценариев взаимоблокировки.

Зачем использовать ConfigureAwait(true)?
Поскольку захват контекста происходит по умолчанию, то ConfigureAwait(true) практически никогда не используется, за исключением случаев, когда вы хотите показать, что вы намеренно не используете ConfigureAwait(false) (например, чтобы отключить предупреждения статического анализа кода). Метод ConfigureAwait принимает логическое значение, поскольку существуют некоторые нишевые ситуации, в которых вы хотите передать переменную для управления конфигурацией. Но в 99% случаев используется жестко закодированное значение false. Поэтому вызовы ConfigureAwait(true) можно безболезненно удалять.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/

День триста двадцать девятый. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
5. Когда использовать ConfigureAwait(false)?
Это зависит от того, реализуете ли вы код уровня приложения или код библиотеки общего назначения. При написании приложений обычно предпочтительно поведение по умолчанию. Если модель приложения или среда (например, Windows Forms, WPF, ASP.NET Core и т. д.) публикует собственный SynchronizationContext, почти наверняка для этого есть веская причина: контекст позволяет коду правильно взаимодействовать с моделью приложения/средой. Поэтому, если вы пишете обработчик событий в приложении Windows Forms, модульный тест в xunit, код в контроллере ASP.NET MVC, то независимо от того, опубликовала ли модель приложения SynchronizationContext, вы предпочли бы использовать его, если он существует. Поэтому по умолчанию используется ConfigureAwait(true). Вы просто используете await, и обратные вызовы/продолжения отправляются обратно в исходный контекст, как и должны. Общее правило: если вы пишете код уровня приложения, не используйте ConfigureAwait(false). Если вернуться к обработчику события Click в примере с кнопкой, то код

downloadBtn.Text = text;

должен быть выполнен в исходном контексте. В этом примере вызов асинхронного кода с

ConfigureAwait(false)

приводил бы к ошибке. То же самое относится и к коду в классическом приложении ASP.NET, зависящем от HttpContext.Current. Использование ConfigureAwait(false), а затем попытка использования HttpContext.Current скорее всего приведёт к проблемам.
И наоборот, библиотеки общего назначения являются «универсальными» отчасти потому, что их не волнует среда, в которой они используются. Вы можете использовать их в веб-приложении, в клиентском приложении или в тесте, это не имеет значения, поскольку код библиотеки не зависит от модели приложения, в которой он может быть использован. Эта независимость также означает, что код не собирается делать что-то, что должно взаимодействовать с моделью приложения строго определённым образом. Например, он не будет получать доступ к элементам управления UI, потому что библиотека общего назначения ничего не знает о них. Поскольку отпадает необходимость запускать код в какой-либо конкретной среде, мы можем избежать принудительного возврата продолжений/обратных вызовов в исходный контекст через ConfigureAwait(false), получая преимущества как в производительности, так и в надёжности. Здесь общее правило такое: если вы пишете код библиотеки общего назначения, используйте ConfigureAwait(false). Вот почему, например, практически любое (за некоторыми исключениями) ожидание в библиотеках среды выполнения .NET Core использует ConfigureAwait(false).
В любых правилах, конечно, могут быть исключения. Например, стоит обдумать решение для библиотек общего назначения с API, принимающим делегаты. В таких случаях пользователь библиотеки передаёт для вызова в библиотеке код приложения. Рассмотрим, например, асинхронную версию LINQ метода Where:

public static async IAsyncEnumerable<T> WhereAsync(this IAsyncEnumerable<T> source, Func<T, bool> predicate);

Нужно ли здесь вызывать predicate в исходном SynchronizationContext вызывающей стороны? Это зависит от реализации WhereAsync. По этой причине можно отказаться от использования ConfigureAwait(false).

Гарантирует ли ConfigureAwait(false), что обратный вызов не будет выполняться в исходном контексте?
Нет. Он гарантирует, что он не будет поставлен в очередь в исходный контекст… но это не означает, что код после

await task.ConfigureAwait(false) 

не будет исполнен в исходном контексте. Это связано с тем, что код, расположенный после уже завершённых задач, просто продолжает исполняться синхронно, а не ставится в продолжение/обратный вызов. Таким образом, если вы ожидаете задачу, которая уже выполнена к тому времени, когда вызывается await, независимо от того, использовали ли вы ConfigureAwait(false), последующий код сразу продолжит выполняться в текущем потоке, в текущем контексте.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/

День триста тридцатый. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
6. Можно ли использовать ConfigureAwait(false) только в первом ожидании методе, но не в остальных?
В общем случае нет. Смотрите предыдущий пост. Если ожидание

await task.ConfigureAwait(false) 

включает в себя задачу, которая уже завершена (что на самом деле случается очень часто), то ConfigureAwait(false) будет бессмысленным, и поток продолжит выполнять код метода дальше в том же контексте.
Исключением является ситуация, когда вы точно знаете, что первое ожидание всегда завершается асинхронно, а обратному вызову задачи не нужен текущий контекст и планировщик задач. Например, CryptoStream в библиотеках .NET Runtime хочет, чтобы его потенциально требовательный к вычислительным ресурсам код не выполнялся как часть синхронного вызова вызывающей стороны, поэтому он использует настраиваемый ожидатель, чтобы весь код после первого ожидания выполнялся в потоке из пула. Однако даже в этом случае можно заметить, что в следующем ожидании всё равно используется ConfigureAwait(false). Технически это не является необходимым, но это делает обзор кода намного проще, так как при чтении этого кода не нужно ломать голову, почему в остальных случаях нет вызова ConfigureAwait(false).

Можно ли использовать Task.Run, чтобы избежать использования ConfigureAwait(false)?
Да. В следующем коде

Task.Run(async delegate {
  await SomethingAsync();
});

использование ConfigureAwait(false) для SomethingAsync не имеет смысла, т.к. делегат, переданный в Task.Run, будет выполняться в потоке из пула без учёта контекста. Кроме того, Task.Run неявно использует TaskScheduler.Default, что означает, что запрос TaskScheduler.Current внутри делегата также возвратит Default. Это означает, что ожидание будет демонстрировать одинаковое поведение независимо от того, использовался ли ConfigureAwait(false). Кроме того, нет никаких гарантий относительно того, что может делать код внутри этого делегата. Если у вас есть код:

Task.Run(async delegate
{
  SynchronizationContext.SetSynchronizationContext(new SomeCoolSyncCtx());
  await SomethingAsync();
});

тогда код внутри SomethingAsync на самом деле увидит в SynchronizationContext.Current экземпляр SomeCoolSyncCtx, и как это ожидание, так и любые ненастроенные ожидания внутри SomethingAsync будут отправлять обратные вызовы в этот контекст. Поэтому, чтобы использовать этот подход, вам необходимо понимать, что может и что не может делать код, который вы ставите в очередь, и могут ли его действия что-то испортить.
Также заметим, что при этом подходе необходимо создавать/ставить в очередь дополнительный объект задачи. Это может иметь или не иметь значения для вашего приложения или библиотеки в зависимости от того, критична ли для вас производительность.
Кроме того, имейте в виду, что такие уловки могут вызвать больше проблем, чем принесут пользы, и иметь другие непредвиденные последствия. Например, инструменты статического анализа (например, анализаторы Roslyn) были написаны для отметки ожиданий, которые не используют ConfigureAwait(false), предупреждением CA2007. Если вы включили такой анализатор, но затем применили хитрость, подобную этой, просто чтобы избежать использования ConfigureAwait, есть большая вероятность, что анализатор всё равно пометит его предупреждением.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/