Denis Ivanov

Digging deeper into Rx sequences

Fri, 31 Jul 2015 22:40:00 +0000

Перейдём к более детальному обзору последовательностей в Rx. Тут будут обязательны знания LINQ, т.к. все построено на extension-методах к базовым абстракциям Rx (query-операторах) и вспомогательных статических типах. Так же не обойдется без знания основ функционального программирования.

Создание последовательностей

Пройдемся по фабричным методам для создания observable-последовательностей. Эти методы обычно получают в качестве параметра значение (экземпляр) некоторого типа, либо сам тип. С точки зрения функционального программирования это есть ничто иное, как анаморфизм, или функция unfold. Далее я перечислю фабричные методы рядом с их реализацией с использованием Subject.

Observable.Return

IObservable<int> observable = Observable.Return(1);

По поведению эквивалентно следующему:

var subject = new ReplaySubject<int>();
subject.OnNext(1);
subject.OnCompleted();

Observable.Empty

IObservable<int> observable = Observable.Empty<int>();

По поведению эквивалентно следующему:

var subject = new ReplaySubject<int>();
subject.OnCompleted();

Observable.Never

IObservable<int> observable = Observable.Never<int>();

По поведению эквивалентно следующему (бесконечная последовательность):

var subject = new ReplaySubject<int>();

Observable.Throw

IObservable<int> observable = Observable.Throw<int>(new Exception());

По поведению эквивалентно следующему:

var subject = new ReplaySubject<int>();
subject.OnError(new Exception());

Observable.Create

Метод Create - рекомендуемый способ создания observable-последовательностей. На это есть две причины:

Используя Subject, нам необходимо самостроятельно контролировать его состояние, а также время жизни, что может быть непросто в асинхронных сценариях.
Метод Create не блокирующий и “лениво” создает последовательность, в отличие от сценария с использованием Subject.

Вот сигнатуры метода Create:

IObservable<TSource> Create<TSource>(Func<IObserver<TSource>, IDisposable> subscribe);
IObservable<TSource> Create<TSource>(Func<IObserver<TSource>, Action> subscribe);

Пункт 2 в списке причин достигается за счет передачи делегата, который будет исполнен только после создания подписки:

public static class SequenceFactory
{
    public static IObservable<int> Create()
    {
        return Observable.Create((IObserver<int> observer) =>
        {
            // этот код будет исполнен только после создания подписки
            observer.OnNext(1);
            observer.OnCompleted();
            return Disposable.Create(() =>
            {
                // этот код выполнится после вызова Dispose у созданной подписки
                Console.WriteLine("Подписчик завершил работу");
            });
        });
    }
}

Сценарий же с использованием Subject не только “более императивен”, но и возвратит завершенную последовательность (можно использовать ReplaySubject для получения того же результата, т.к. значения будут закэшированы, однако отписку придется контролировать вызывающему коду):

public static class SequenceFactory
{
    public static IObservable<int> CreateUsingSubject()
    {
        var subject = new Subject<int>();
        subject.OnNext(1);
        subject.OnCompleted();
        return subject;
    }
}

Unfold и корекурсия

Unfold (наверное, можно перевести как развёртка (от слова “развёртывать”)) - функция высшего порядка, позволяющая строить следующий элемент, используя начальное значение и вызывая переданную функцию.

Корекурсия - функция, позволяющая получить следующее значение последовательности, используя текущее.

Можно реализовать pull-вариант функции unfold с использованием IEnumerable<T> и корекурсии:

IEnumerable<T> Unfold<T>(T seed, Func<T, T> accumulator)
{
    var nextValue = seed;
    while (true)
    {
        yield return nextValue;
        nextValue = accumulator(nextValue);
    }
}

С помощью этой фукнции можно получить, например, массив натуральных чисел:

var values = Unfold(1, x => x + 1).Take(10).ToArray();

Посмотрим, как это можно сделать в push-варианте с помощью Rx.

Observable.Range

Этот метод похож на одноименный метод статического класса Enumerable, но возвращает IObservable<T>. Чтобы получить значения, нужно начать “наблюдать” результат, создав подписку:

var range = Observable.Range(1, 10);
range.Subscribe(Console.WriteLine);

Observable.Generate

Это и есть реализация функции unfold в Rx. Вот сигнатура метода:

IObservable<TResult> Generate<TState, TResult>(TState initialState, 
                                               Func<TState, bool> condition, 
                                               Func<TState, TState> iterate, 
                                               Func<TState, TResult> resultSelector);

Параметры метода по порядку:

начальное значение
предикат для завершения последовательности
корекурсивная логика
функция для преобразования результата

Observable.Range<int> может быть реализован с помощью Observable.Generate следующим образом:

IObservable<int> Range(int start, int count)
{
    var max = start + count;
    return Observable.Generate(
        start, 
        value => value < max, 
        value => value + 1, 
        value => value);
}

Observable.Interval

Метод для получения последовательности целых чисел, начиная с 0, через заданный промежуток времени.

Observable.Interval также может быть реализован с помощью Observable.Generate следующим образом:

public static IObservable<long> Interval(TimeSpan period)
{
    return Observable.Generate(
        0l,
        i => true,
        i => i + 1,
        i => i,
        i => period);
}

Тут использована еще одна перегрузка Observable.Generate с параметром для создания timer related-последовательностей:

IObservable<TResult> Generate<TState, TResult>(TState initialState,
                                               Func<TState, bool> condition, 
                                               Func<TState, TState> iterate, 
                                               Func<TState, TResult> resultSelector, 
                                               Func<TState, TimeSpan> timeSelector);

Как видно из примера выше, Observable.Interval создает бесконечную последовательность для подписчика, поэтому важно не забывать про Dispose.

Observable.Timer

Сигнальный метод, который публикует только одно значение (равное 0) после прошествия заданного промежутка времени, задаваемого с помощью параметра типа TimeSpan. Последовательность завершается сразу, однако если воспользоваться перегрузкой с типом параметра DateTimeOffset, то последовательность завершится в указанное время.

Есть и третья перегрузка с двумя параметрами типа TimeSpan для создания бесконечных временных последовательностей.

Observable.Timer также может быть реализован с помощью Observable.Generate следующим образом:

IObservable<long> Timer(TimeSpan dueTime)
{
    return Observable.Generate(
        0l,
        i => i < 1,
        i => i + 1,
        i => i,
        i => dueTime);
}

IObservable<long> Timer(TimeSpan dueTime, TimeSpan period)
{
    return Observable.Generate(
        0l,
        i => true,
        i => i + 1,
        i => i,
        i => i == 0 ? dueTime : period);
}

В свою очередь Observable.Interval может быть реализован с использованием Observable.Timer:

IObservable<long> Interval(TimeSpan period)
{
    return Observable.Timer(period, period);
}

Переход к push-модели

Возможно также создать observable-последовательность, выполнив переход из существующего синхронного или асинхронного императивного кода.

Observable.Start

Метод позволяет создать из экземпляра Func<T> или Action observable-последовательность с одним элементом, обработка которого будет выполнена асинхронно потоком из ThreadPool. В случае Action возращаемым значением Observable.Start является IObservable<Unit>. Тип Unit - конструкция из мира функционального программирования, представляющая собой нечно наподобие void. Unit не имеет значения и служит для передачи в метод OnNext:

IObservable<Unit> start = Observable.Start(
    () =>
    {
        Console.Write("Working away");
        for (int i = 0; i < 10; i++)
        {
            Thread.Sleep(100);
            Console.Write(".");
        }
    });

start.Subscribe(
  unit => Console.WriteLine("Unit published"), 
  () => Console.WriteLine("Action completed"));

Метод Observable.Start очень напоминает Task, т.к. позволяет создать значение, которое будет вычислено позже. Это отличает этот метод от Observable.Return, который возвращает observable-последовательность с одним заданным (вычисленным) элементом.

Observable.FromEventPattern

Метод позволяет перейти к push-модели из существующей в .NET модели событий (event). Есть много перегрузок этого метода, чтобы иметь возможность использовать его во всех случаях (обычный EventHandler/специфичный наследник EventHandler и специфичный наследник EventArgs/ обобщенный (generic) EventHandler<TEventArgs>). Вот пример для второго случая - UnhandledExceptionEventHandler и UnhandledExceptionEventArgs:

IObservable<EventPattern<UnhandledExceptionEventArgs>> unhandledExceptionObservable =
    Observable.FromEventPattern<UnhandledExceptionEventHandler, UnhandledExceptionEventArgs>(
        x => AppDomain.CurrentDomain.UnhandledException += x,
        x => AppDomain.CurrentDomain.UnhandledException -= x);

ToObservable()

У AsyncSubject<T>, о котором я писал в прошлом посте, много общего с Task<T>. Они оба возвращают одно значение из асинхронного источника, кэшируют результат для последующих обращений. Одна из перегрузок метода ToObservable() - extension-метод к типу Task<T>, который работает следующим образом:

если task в статусе RanToCompletion, значение добавляется в последовательность, после чего она завершается
если task в статусе Cancelled, будет опубликована ошибка с экземпляром TaskCanceledException
если task в статусе Faulted, будет опубликована ошибка внутренним исключением task-а
если task еще не завершен, к task-е добавляется continuation, чтобы выполнить перечисленное выше

Вот пример:

var task = Task.Run(() => "Task started");
var observable = task.ToObservable();
observable.Subscribe(Console.WriteLine, () => Console.WriteLine("Observable completed"));

На консоль будет выведено

Task started
Observable completed

Еще одна перегрузка метода ToObservable() - extension-метод к типу IEnumerable<T>, который семантически использует Observable.Create, передавая в качестве делегата функцию, в которой перечисляются все элементы исходной последовательности. При использовании этого метода стоит помнить, что блокирующая синхронная pull-модель IEnumerable<T> противоположна асинхронной push-модели IObservable<T> и хорошо продумывать сценарии использования этого метода.

Observable.FromAsync

Cуществовавший до .NET 4.5 async pattern (пара методов BeginXXX/EndXXX), известный также как Asynchronous Programming Model (APM), был поддержан в Rx с помощью метода Observable.FromAsyncPattern, который на текущий момент в статусе obsolete, как и весь APM. Пришедший ему на замену способ реализации асинхронных сценариев с возвращаемым значением в виде экземпляра Task или Task<T> также поддержан в Rx посредством метода Observable.FromAsync. Вот пример, в котором на консоль выводятся адреса всех UDP-клиентов:

var udpClient = new UdpClient("www.contoso.com", 11000);
var udpResultsObservable = Observable.FromAsync(udpClient.ReceiveAsync);
udpResultsObservable.Subscribe(x => Console.WriteLine(x.RemoteEndPoint.Address));

Summary

Мы пробежались по всем способам создания observable-последовательностей, рассмотрели понятия unfold и корекурсии и их реализации в Rx. Научились создавать временные последовательности, из одного элемента и бесконечные. Так же как получать observable-последовательности из императивного кода. Вот методы, которые были рассмотрены:

Factory Methods
Observable.Return
Observable.Empty
Observable.Never
Observable.Throw
Observable.Create
Unfold methods
Observable.Range
Observable.Interval
Observable.Timer
Observable.Generate
Paradigm Transition
Observable.Start
Observable.FromEventPattern
Task.ToObservable
Task<T>.ToObservable
IEnumerable<T>.ToObservable
Observable.FromAsync

Далее рассмотрим, как стоить запросы к observable-последовательностям.

Stay tuned!

Reactive Extensions: sequences and subscriptions

Thu, 30 Jul 2015 14:30:00 +0000

Подписки и управление временем жизни

Работая с observable-последовательностью, мы не можем знать когда она начинается и когда заканчивается. Этим знанием обладает источник, но не подписчик. Тем не менее, необходим детерминированный механизм управления подпиской - мы самостоятельно должны контролировать момент подписки и начала получения данных/событий/элементов последовательности, также как и момент окончания работы с observable-последовательностью. Давайте еще раз взглянем на интерфейс IObservable:

public interface IObservable<out T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

Важно обратить внимание на два аспекта. Вызывая Subscribe, мы явно создаем подписку и начинаем работать с элементами последовательности. Однако возвращаемое значение метода - не какой-либо объект, определяющий абстракцию подписки (хотя внутри Rx такая абстракция есть), но объект, реализующий IDisposable. Именно этот объект дает нам возможность явно закончить работать с последовательностью, вызывав метод Dispose.

var subject = new Subject<int>();
var subscription1 = subject.Subscribe(x => { Console.WriteLine($"subscription1, value: {x}"); });
var subscription2 = subject.Subscribe(x => { Console.WriteLine($"subscription2, value: {x}"); });

// будет обработано и subscription1, и subscription2
subject.OnNext(1);

subscription2.Dispose();

// будет обработано только subscription1
subject.OnNext(2);

subscription1.Dispose();

Как и обычно при использование IDisposable-объектов можно вызывать Dispose сколько угодно раз.

В Rx есть несколько служебных типов, реализующих IDisposable, которые удобно использовать в различных ситуациях (позже мы рассмотрим некоторых из таких ситуаций). Их можно использовать, например, с помощью статического класса Disposable, содержащего свойство Empty и фабричный метод Create:

public static class Disposable
{
    public static IDisposable Empty
    {
        get { return DefaultDisposable.Instance; }
    }

    public static IDisposable Create(Action dispose)
    {
        if (dispose == null)
            throw new ArgumentNullException("dispose");

        return new AnonymousDisposable(dispose);
    }
}

Стоит отдельно отметить, что подписчик, вызывая Subscribe и получая экземпляр IDisposable (подписку), обязан сам вызвать Dispose. Если этого не сделать, либо вообще проигнорировать возвращемое методом Subscribe значение, это может привести к наличию в памяти нежелательных объектов и утечке памяти (а также снижению производительности), т.к. ссылки на подписки сущесвуют в райнтайме Rx и они не будут собраны GC автоматически. Также нужно помнить про то, что будет с подписками после завершения последовательности или в случае возникновения исключения. Об этом чуть ниже.

Обработка исключений

Как уже отмечалось ранее, мы можем вызывать Subscribe, передавая не только IObserver<T>, но и делегаты. Вот набор extension-методов для Subscribe:

IDisposable Subscribe<TSource>(this IObservable<TSource> source);
IDisposable Subscribe<TSource>(this IObservable<TSource> source, 
                               Action<TSource> onNext);
IDisposable Subscribe<TSource>(this IObservable<TSource> source, 
                               Action<TSource> onNext, 
                               Action<Exception> onError);
IDisposable Subscribe<TSource>(this IObservable<TSource> source, 
                               Action<TSource> onNext, 
                               Action onCompleted);
IDisposable Subscribe<TSource>(this IObservable<TSource> source, 
                               Action<TSource> onNext, 
                               Action<Exception> onError,
                               Action onCompleted);

Эти методы позволяют нам указывать делегаты, которые будут вызваны для каждого элемента последовательности (onNext), для обработки ошибок на стороне источника (onError) и для обработки окончания последовательности (onCompleted).

По-умолчанию, реализация метода OnError в Subject<T> пробрасывает исключение, если подписка была создана без определения делегата onError. Это означает, что при использовании try/catch/finally в catch нужно оборачивать именно вызов метода OnError источника последовательности. То есть подписчик ничего не узнает об исключении. Поэтому, если требуется обрабатывать исключения, нужно использовать перегрузку Subscribe с определением делегата onError.

Не верно:

var subject = new Subject<int>();
try
{
    subject.Subscribe();
}
catch (Exception)
{
    // сюда не придет выполнение
}

// исключение будет выбрашено в этой строке
subject.OnError(new Exception("Exception"));

Верно:

var subject = new Subject<int>();
subject.Subscribe(
    x => { },
    ex =>
    {
        // исключение будет обработано здесь
        Console.WriteLine($"Exception occured: {ex}");
    });
subject.OnError(new Exception("Exception"));

В случае возникновения исключения, а также в случае окончания последовательности, подпичики не “отключаются” от источника автоматически (это происходит только в случае использования метода SubscribeSafe). Поэтому важно не забывать отписываться явно, вызывая Dispose. Это также важно и в случае бесконечных последовательностей, когда IObserver.OnCompleted никогда не будет вызван.

Summary

Rx позволяет явно управлять временем жизни подписок, поэтому важно не забывать “диспозить” создаваемые при вызове IObservable.Subscribe подписки. Это нужно делать даже в случае окончания последовательности или возникновения исключения.

Исключения же обрабатываются не с помощью привычного try/catch/finally-паттерна, с помощью определения делегата onError при создании подписки. Также есть и другие способы, но об этом в следующих постах.

Stay tuned!

Reactive Extensions overview

Tue, 12 May 2015 00:30:00 +0000

Что такое Reactive Extensions

Итак, продолжая тему Reactive, пробежимся по библиотеке Reactive Extensions. Как следует из первой же строки описания проекта, Reactive Extensions (Rx) - это библиотека для создания асинхронных, основанных на событиях, программ с помощью observable-последовательностей и LINQ-style операторов. Используя Rx, мы представляем асинхронные потоки данных абстракцией Observables, делаем к ним запросы посредством LINQ-операторов и параметризуем конкурентный доступ к асинхронных потокам данных с помощью Планировщиков (Schedulers). Итого, Rx = Observables + LINQ + Schedulers.

В каких случаях мне использовать Rx?

Далее я буду использовать довольно много текста из книги Lee Campbell “Introduction to Rx”, онлайн-версия которой доступна по ссылке.

Если вы работаете с предметной областью, где приходится оперировать с последовательностью событий, то Rx - то, о чем неплохо бы вспомнить.

Нужно использовать Rx

Rx создана для управления такими видами событий как:

UI-события, то есть при разработке клиентских приложений
Доменные события, такие как “Заказ оформлен”, “Заказ утвержден”, “Списание средств выполнено” и т.п. К этому приходят, например, применяя практику проектирования по предметной области (Domain-Driven Design, DDD)
Всяческие инфраструктурные события, источником которых может быть filewatcher, WMI, ETW и т.п.
События из broadcast-источников, таких как шины сообщений, всевозможные датчики (тут можно вспомнить про модные сейчас IoT-устройства) и прочее
События из Complex event processing (CEP) сервисов

Можно использовать Rx для асинхронных вызовов методов, возвращающих Task или Task<T>, т.к. это есть ничто иное, как последовательность из одного элемента. Возможно также использование и с APM-методами вида BeginXXX/EndXXX.

Не стоит использовать Rx для выполнения задач, которые успешно решаются с помощью IEnumerable<T>, тем самым заменяя pull-модель взаимодействия push-моделью.

Основы Rx

Как я отмечал в предыдущем посте, в основе Rx лежит паттерн Observer. В Rx есть два базовых интерфейса:

public interface IObservable<out T>
{
	IDisposable Subscribe(IObserver<T> observer);
}

public interface IObserver<in T>
{
	void OnNext(T value);
	void OnError(Exception error);
	void OnCompleted();
}

Все, что реализует IObservable<T> стоит воспринимать как поток объектов типа T. Не нужно путать IObservable<T> с также существующей в .NET абстракцией Stream из неймспейса System.IO, т.к. последняя поддерживает возможность чтения и записи, а также “просмотра” потока (seek). Тем не менее, в Rx присутствуют концепции следования по потоку (push), освобождения ресурсов (закрытия) и завершения работы с потоком (EOF). Однако, кроме этого Rx предоставляет возможность конкурентного доступа, трансформации потока, слияния потоков, агрегации и расширения (expanding).

Важно также, что observables - это не коллекции в привычном понимании. Значения из IObservable<T> обычно не материализованы, как этого можно ожидать от коллекции. Таким образом, observables - это последовательности. Чтобы не путать их с последовательностями IEnumerable<T> Lee Campbell предлагает воспринимать экземпляры IEnumerable<T> как данные в статичном состоянии, в то время как экземпляры IObservable<T> - данные в движении.

Также важно упомянуть, что IObservable<T> является функционально сопряженным (functional dual) к IEnumerable<T>. Напомню, как выглядят IEnumerable<T>

public interface IEnumerable
{
    IEnumerator GetEnumerator();
}

public interface IEnumerable<out T> : IEnumerable
{
    new IEnumerator<T> GetEnumerator();
}

и IEnumerator<out T>

public interface IEnumerator
{
    bool MoveNext();
    Object Current { get; }
    void Reset();
}

public interface IEnumerator<out T> : IDisposable, IEnumerator
{    
    new T Current { get; }
}

Для тех, кто помнит функциональный анализ и хочет поглубже разобраться, рекомендую посмотреть это видео на Channel 9. Если вкратце, то это значит, что также как IEnumerable<T> позволяет реализовать три свойства - следующее значение (MoveNext() и Current), обработку исключений (обычный try/catch/finally и Dispose()) и окончание последовательности (MoveNext(), возвращающий false) с помощью IEnumerator<T>, так же и IObservable<T> позволяет сделать то же самое с помощью IObserver<T> - методы OnNext(T), OnError(Exception) и OnCompleted() соотвественно.

Rx предоставляет четкий контракт, которому необходимо следовать, если вы решите реализовывать базовые интерфейсы самостоятельно. В такой реализации стоит учитывать, что опционально может быть вызван метод OnNext(T) и далее возможен (но не обязятелен) вызов одного из OnError(Exception) или OnCompleted(). То есть, если последовательность завершается, то обязательно вызовом либо OnError(Exception), либо OnCompleted(). Однако, ни один из этих трех методов может быть и не вызван вовсе, что дает возможность реализации пустых или бесконечных последовательностей.

Subject

Rx конечно же предоставляет реализацию этих базовых интерфейсов, тем самым избавляя нас от необходимости делать это самостоятельно - это тип Subject<T>. Этот тип реализует сразу оба интерфейса, предоставляя вызывающему коду целостно использовать концепцию publisher/subscriber (или publisher/consumer). Вот пример:

var subject = new Subject<string>();
subject.Subscribe(Console.WriteLine);
subject.OnNext("a");
subject.OnNext("b");
subject.OnNext("c");

Это рабочий код, так как в Rx есть множество extension-методов, в том числе метод Subscribe(Action<T>). В результате работы кода на консоль будет выведено abc.

Но Subject<T> - это самая простая имплементация. Существуют также еще три, существенно меняющие поведение при использовании каждой из них.

ReplaySubject

ReplaySubject<T> - реализация, позволяющая “повторить” события для подписчиков, которые начали слушать последовательность не с начала. ReplaySubject<T>, созданный при помощи конструктора по-умолчанию кэширует все значения и воспроизводит их для всех подписчиков. Однако, это может привести к memory pressure, поэтому сущеуствует конструктор, позволяющий задать размер буфера, то есть количество кэшируемых значений. Код ниже выведет на консоль bc. Даже, если до вызова Subscribe(Action<T>) вызвать OnCompleted().

var subject = new ReplaySubject<string>(2);
subject.OnNext("a");
subject.OnNext("b");
subject.OnNext("c");
subject.Subscribe(Console.WriteLine);

Существуют также конструкторы, позволяющие задать временно окно для кэширования, а также и то, и другое.

BehaviorSubject

BehaviorSubject<T> - реализация, запоминающяя последнее опубликованное значение. Для BehaviorSubject<T> требуется задать значение T по-умолчанию. Отличие от ReplaySubject<T> в том, что, во-первых, размер буфера равен 1 и, во-вторых, ничего не будет получено, если подписка была выполнена после завершения последовательности, то есть, например, вызова OnCompleted(). Код ниже выведет на консоль bc

var subject = new BehaviorSubject<string>("x");
subject.OnNext("a");
subject.OnNext("b");
subject.Subscribe(Console.WriteLine);
subject.OnNext("c");

А этот код ничего не выведет

var subject = new BehaviorSubject<string>("x");
subject.OnNext("a");
subject.OnNext("b");
subject.OnCompleted();
subject.Subscribe(Console.WriteLine);
subject.OnNext("c");

AsyncSubject

AsyncSubject<T> - реализация, очень похожая на BehaviorSubject<T>. Она также кэширует последнее значение, однако публикует его только по окончанию последовательности. То есть этот код ничего не выведет

var subject = new AsyncSubject<string>();
subject.OnNext("a");
subject.OnNext("b");
subject.Subscribe(Console.WriteLine);
subject.OnNext("c");

а этот код выведет c

var subject = new AsyncSubject<string>();
subject.OnNext("a");
subject.OnNext("b");
subject.Subscribe(Console.WriteLine);
subject.OnNext("c");
subject.OnCompleted();

Интерфейс ISubject

Описанные выше типы реализуют IObservable<T> и IObserver<T> через специальный интерфейс

public interface ISubject<in TSource, out TResult> : IObserver<TSource>, IObservable<TResult>
{
}

Точнее даже через интерфейс с одинаковыми типами TSource и TResult

public interface ISubject<T> : ISubject<T, T>, IObserver<T>, IObservable<T>
{
}

Важно заметить, что все четыре реализации, описанные выше реализуют лишь контракт ISubject<T> и не имеют общих базовых классов.

Также стоит упомянуть, что существует фабричный метод

 public static ISubject<TSource, TResult> Create<TSource, TResult>(
 	IObserver<TSource> observer, 
	IObservable<TResult> observable)
{...}

позволяющий создать ISubject<TSource, TResult> из имеющихся IObserver<TSource> и IObservable<TResult>.

Summary

В этом посте мы пробежались по самой сути Rx, а также посмотрели на имеющиеся реализации базовых контрактов. Однако, в продакшен коде очень редко придется использовать интерфейс IObserver<T> и subject-типы. Тем не менее, их знание и понимание принципов работы очень важно для правильного использования Rx. Напротив, интерфейс IObservable<T> очень широко используется в Rx в качестве возвращаемого значения, представляя тем самым последовательность данных в движении. Для этого интерфейса реализовано огромное количество extension-методов для возможности использования Rx в LINQ-стиле для оперирования этими последовательностями. Что это за возможности - рассмотрим одном из следующих постов.

Stay tuned!

The basics of the reactive

Thu, 23 Apr 2015 22:00:00 +0000

Reactive manifesto

Начать изучение reactive programming как подхода к программированию, конечно же, стоит с reactive manifesto. Этот документ объясняет базовые концепции, которые лежат в основе реактивного программирования. Или даже лучше сказать, свойства системы, которые хочется достичь.

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

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

Мы хотим, как утверждается в манифесте, строить системы, обладающие свойствами Отзывчивости (Responsive), Упругости (Resilient), Эластичности (Elastic) и Управления с помощью сообщений (Message Driven). Собственно, такие системы и есть Reactive systems.

Рассмотрим вкратце каждое свойство:

Responsive: система отвечает очень быстро, и это время ответа, находясь в определенных границах, не выходит за верхний предел. Тем самым достигается постоянное качество обслуживания (quality of service)
Resilient: система отвечает даже в момент сбоя. Это достигается за счет репликации, локальности, изоляции и делегирования. Сбои локализуются внутри компонента, тем самым он может быть восстановлен отдельно, не влияя на систему в целом. Восстановлением занимается отдельный компонент
Elastic: система отвечает под изменяющейся нагрузкой. Реактивные системы могут увеличивать или уменьшать свои ресурсы. Дизайн системы построен так, чтобы не допускать неоднозначного поведения или центральных узлов-bottleneck-ов, что позволяет распределять входящую нагрузку. Реактивные системы поддерживают алгоритмы масштабирования, измеряя производительность в реальном времени
Message Driven: все основано на асинхронной (неблокирующей) передаче сообщений, позволяя тем самым прочертить границы между компонентами и достичь слабой связанности, изоляции, независимости от расположения компонентов (location transparency), а также воспринимать ошибки тоже как сообщения

Вот как эти свойства связаны:

Далее, небольшие системы складываются в большие, которые также сохраняют эти Реактивные свойства на всех уровнях масштабирования.

Также рекомендую почитать глоссарий терминов и подписать манифест, если вы со всем согласны. Если не согласны - давайте обсудим это в комментариях.

Observer pattern

Плавно переходя к библиотеке для .NET, созданной для построения систем на перечисленных принципах, - Reactive Extensions, важно заметить, какие концепции там использованы. Всё базируется на паттерне Observer. Кратко пробежимся по нему.

Итак, observer, он же наблюдатель, он же publisher/subriber, “создает механизм у класса, который позволяет получать экземпляру объекта этого класса оповещения от других объектов об изменении их состояния, тем самым наблюдая за ними”. Вот диаграмма классов с википедии:

Также приведу код на C#, тоже с википедии, но с пояснениями.

Пусть у нас есть абстракция IObserver (он же subcriber), которая выполняет некоторое действие Update - обновление своего состояния.

interface IObserver 
{
    void Update(string state);
}

По сути, это функциональная абстракция, которую вызывающий код должен использовать для выполнения действия. Пока все просто.

Дальше, пусть есть еще одна абстракция IObservable (он же publisher), которая позволяет что-то делать с IObserver, а именно - добавлять/удалять и нотифицировать.

interface IObservable
{
    void AddObserver(IObserver observer);
    void RemoveObserver(IObserver observer);
    void NotifyObservers(string s);
}

Имея эти абстракции, можем написать такой псевдокод:

IObserver observer1;
IObserver observer2;

IObservable observable;

observable.AddObserver(observer1);
observable.AddObserver(observer2);

observable.NotifyObservers("some event");

Тут мы имеем публикатора observable и двух его подписчиков (наблюдателей) observer1 и observer2. Публикатор для нотификации подписчиков вызывает у них метод Update. Опять же все просто.

Как гласит википедия, “шаблон «наблюдатель» применяется в тех случаях, когда система обладает следующими свойствами:

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

Данный шаблон часто применяют в ситуациях, в которых отправителя сообщений не интересует, что делают получатели с предоставленной им информацией.”

Таким образом, паттерн позволяет чётко выделить отвественности и достичь слабой связанности. Причем топология системы может меняться в рантайме.

Summary

Подводя здесь черту, стоит еще раз обратить внимание на тот факт, что

Реактивные системы обладают свойствами Отзывчивости (Responsive), Упругости (Resilient), Эластичности (Elastic) и Управления с помощью сообщений (Message Driven)
Существует библиотека Rx для множетва языков программирования, которая призвана помогать делать системы с такими свойствами, то есть Реактивные системы
В основе Rx лежит шаблон проектирования Observer

В следующем посте разберёмся с основными артефактами Reactive Extensions. Stay tuned!

P.S. Сколько не пытался добавить риббон, так и не смог подружить его с общим дизайном. Вместо этого вот: we are reactive!

P.P.S. Aren’t we?

Привет!

Wed, 15 Apr 2015 15:00:00 +0000

Этим постом я хочу положить начало написанию не только кода, но и всевозможных текстов. Хотя вставки кода в этих текстах все равно будут.

Исторически, это уже третья версия моего блога. Первая была на кастомизированном BlogEngine.NET и ее я хостил сам. Вторая была на WordPress, без особых кастомизаций. Теперь это GitHub Pages на основе Project Zeppelin.

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

Rx: Мне очень хочется глубоко разобраться с Reactive Programming и имплементацией для .NET - Reactive Extensions
Reactive UI: С этим фреймворком для клиенстких приложений я работал и хочется поделиться опытом и рассказать о нюансах
CodeFest App for Windows: Open Source приложение конференции CodeFest. Я занимаюсь организацией Backend-трека этой конфереции и делаю приложение для участников, которое, по оригинальной задумке, должно работать на всех Windows-платформах. Пока это только Windows Phone 8.1 (и не особо оптимально :)). Оно, кстати, работает на Reactive UI.

Как-то так. Очень надеюсь, что следующий пост будет, и будет скоро.

Stay tuned!