Контракты vs. Монады?

DISCLAIMER: чтобы было легче понять, о чем пойдет речь в этой заметке, стоит прочитать заметку "Борьба с "нулевыми" ссылками в C#".

Q: Если бы в BCL был тип Optional<T> или Nullable<T> для ссылочных типов, ты бы его использовал в своем коде?

A: Да, конечно!

Q: Значит, тогда ты бы отказался и от контрактов?

A: …

Примерно такой диалог произошел у меня после прошедшей вчера встречи Kiev ALT.NET, посвященной вопросам борьбы с нулевыми ссылками в C# (вот презентация с выступления, а вот – код).

У этого вопроса есть один простой ответ, и звучит он так: «Нет, я не откажусь от контрактов!», но поскольку подобная форма ответа не слишком информативна, то я готов объяснить свою точку зрения более подробно.

Три уровня обороны

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

1. Система типов
2. Контракты
3. Юнит-тесты

Чем "выше" линия обороны, тем раньше она срабатывает и "докладывает" нам о возможной проблеме в коде. Если мы что-то можем выразить с помощью системы типов, то именно с ее помощью мы должны выражать свои намерения. Именно поэтому в С++ обязательные входные значения передаются по константной ссылке, необязательные входные значения – по константному указателю и т.п.

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

API класса/метода должен быть таким, чтобы его легко было пользовать правильно и сложно использовать неправильно!

Но что, если мы не можем выразить что-то через систему типов (ибо она недостаточно выразительна)? Например, в языке C# мы не можем выразить, что аргумент метода ссылочного типа является обязательным, поскольку любой ссылочный тип может принимать значение null. Иногда, когда это возможно, мы можем заменить его на тип-значение (value type) и уйти от проблемы, но далеко не всегда это возможно (ну и вы же помните о проблеме изменяемых значимых типах, правда?)

Когда система типов бессильна, нам на помощь приходят контракты: инструмент, который помогает выразить наши намерения в более явном виде. Как выразить с помощью системы типов, что метод Add интерфейса ICollection<T> может не добавлять еще один элемент, а метод Add любой реализации класса IList<T> обязана это сделать? (Помните обсуждение этого вопроса в статье "Принцип замещения Лисков и контракты"?).

Контракт располагается в самом методе и формально является частью его "сигнатуры", что делает его (метод) более описательным. При этом некоторые нарушения контрактов могут детектиться на этапе компиляции (с помощью статик-чекера, или инструментов, таких как R#), а некоторые – на этапе исполнения.

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

Контракты по своей природе тоже не могут выразить все тонкости ожидаемого поведения. Когда их выразительности становится недостаточно, нам на помощь приходит следующая линия обороны – юнит-тесты. Так, например, в контрактах невозможно выразить, что третьим числом Фибоначчи будет 2, или что при вызове метода Save вью-модели будет вызван метод SaveEmployee нашего сервиса.

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

ПРИМЕЧАНИЕ
Более детальное сравнение контрактов и юнит-тестов можно найти в статье "Контракты, состояние и юнит-тесты".

А как насчет Option<T>?

Чем полезен тип Option<T>, Maybe<T> или Nullable<T>, в качестве обертки над ссылочными типами?

Он полезен тем, что с его помощью мы выражаем четкие намерения метода вернуть (или получить) необязательное значение. Дальше уже второй вопрос, как его обработать, с помощью модного "монадического" синтаксиса, с помощью "сопоставления с образцом" (a.k.a. pattern-matching-а) или с помощью простого if-else).

Хорошо. Но какую проблему решают эти типы, со всеми этими Bind-ам, Apply-ами и Return-ами? (это я про составляющие паттерна "монада").

ПРИМЕЧАНИЕ
Если вас пугает это страшное слово, то зря. Просто посвятите сегодня один вечер, и прочтите отличное введение по этой теме от Эрика Липперта – Monads, part one (и дальше по ссылкам!).

Напомню, что у нас есть две задачи: во-первых, мы хотим упростить control flow и избавиться от множества вложенных проверок на null, поскольку не хотим видеть код вроде этого:

[CanBeNull]
public static IClrTypeName GetCallSiteTypeNaive(IInvocationExpression invocationExpression)
{
    Contract.Requires(invocationExpression != null);
    if (invocationExpression.InvokedExpression != null)
    {
        var referenceExpression = invocationExpression.InvokedExpression as IReferenceExpression;
        if (referenceExpression != null)
        {
            var resolved = referenceExpression.Reference.Resolve();
            if (resolved.DeclaredElement != null)
            {
                var declared = resolved.DeclaredElement as IClrDeclaredElement;
                if (declared != null)
                {
                    var containingType = declared.GetContainingType();
                    if (containingType != null)
                    {
                        return containingType.GetClrName();
                    }
                }
            }
        }
    }
    return null;
}

Нужно сказать, что подобные примеры не должны встречаться слишком часто, ведь такой код полностью нарушает закон Деметры. Но поскольку в реальном мире такой API все же встречается, поэтому мы хотим как-то уменьшить боль, и избавиться от вложенных if-statmeents. Один из способов решения, воспользоваться классом Option<T> или методами расширения, рассмотренными ранее:

[CanBeNull]
public static IClrTypeName GetCallSiteType(this IInvocationExpression invocationExpression)
{
    Contract.Requires(invocationExpression != null);
 
    var type = invocationExpression
        .With(x => x.InvokedExpression)
        .With(x => x as IReferenceExpression)
        .With(x => x.Reference)
        .With(x => x.Resolve())
        .With(x => x.DeclaredElement)
        .With(x => x as IClrDeclaredElement)
        .With(x => x.GetContainingType())
        .Return(x => x.GetClrName());
    return type;
}

Во-вторых, мы хотим избавиться от ошибок (а.к.а. багов) вообще, и связанных с доступом к пустым ссылкам, в частности.

С первой задачей (избавление от обилия if-ов) такие "монадические" решения справляются отлично, но насколько они помогают решить проблему с нулевыми ссылками?

Давайте рассмотрим такой пример. Допустим, нам нужно найти сотрудника по имени:

Option<Employee> FindByName(string name) {...}

Помогает ли Option<T> в этом случае? Частично. С возвращаемым значением код становится более самоописательным, но как мы можем выразить "обязательность" аргумента? Есть мнение, что в случае передачи в качестве имени null мы должны вернуть None, но насколько это разумно? Как нам понять, что означает этот None? Отсутствие такого сотрудника с заданным именем или баг в коде, который подсунул невалидные входные данные?

Да, если подобный код находится вблизи пользовательского интерфейса и name приходит прямо из UI, не ограничивающего ввод пользователя, то такой подход может быть оправдан. Но обычно, мы все же выделяем некий слой вью-моделей, которые валидируют входные данные и обращаются к моделям, для которых null в качестве аргументов является недопустимым.

Давайте я приведу другой пример. Насколько будет разумным, если метод Enumerable.FirstOrDefault возвращал бы null, при вызове на null-коллекции, или при передаче null в качестве предиката?

IEnumerable<Employee> sequence = null;
var result = sequence.FirstOrDefault((Func<Employee, bool>)null);
Debug.Assert(result == null); // Hello, rude world!

Очевидно, что этот код неверный, и было бы печально, если бы реализация метода FirstOrDefault прятала бы ошибку, путем возвращения null при передаче этому методу ошибочных входных данных. (Кстати, обратите внимание, что при замене возвращаемого значения с Employee на Option<Employee> наша логика не изменится. null не является валидным входным значением, поэтому нельзя возвращать None в этом случае).

Наши инструменты не должны скрывать ошибки, а должны следовать идиоме Fail Fast и бросать исключения, или прерывать исполнение как можно раньше (помните, нарушение контрактов может вести себя аналогично нарушению Debug.Assert!).

Почему нужно следовать идиоме Fail Fast? Чтобы избавиться от того самого эффекта бабочки, когда изменение в одной части системы проявится на несколько слоев ниже, или на несколько модулей правее, от места возникновения ошибки! (Мы просто будем сидеть и думать, а какого лешего при обработке этого запроса мы сохранили null в этом поле базы данных?)

Контракты в ФП мире

Почему-то принято считать, что контракты являются частью ОО мира. На самом деле, это не так. В основе контрактов лежит принцип, описанный Тони Хоаром в конце 60-х годах прошлого века, под названием тройка Хоара:

И звучит она так: любое выполнение команды С начинается в состоянии, где утверждение P истинно, завершится и в заключительном состоянии будет истинным утверждение Q. При этом C – это операция (или команда), P – предусловие, а Q – постусловие.

ПРИМЕЧАНИЕ
Подробности см. в первой статье по контрактам: Проектирование по контракту. Корректность ПО.

Звучит мудрено, но по сути, все довольно просто. Давайте в качестве примера рассмотрим метод Enumerable.Single:

public static class Enumerble
{
    public static T Single<T>(this IEnumerable<T> source, 
        Func<T, bool> predicate)
    { }
}

В данном случае P (предусловие): source != null, predicate != null, source.Contains(predicate).
С (команда): Enumerable.Single
Q (постусловие): элемент из source, удовлетворяющий предикату!

Т.е. если мы вызовем метод Single на коллекции, не равной null, с предикатом не равным null, то метод вернет значение из последовательности, удовлетворяющему этому предикату. При этом искомый элемент обязательно должны быть в коллекции, в противном случае прилетит исключение InvalidOperationException (так что по сути, тип возвращаемого значения является не T, а non-nullable T).

Если же предусловие P не выполняется, то никакие обязательства на метод С не возлагаются, и он перестает быть должен вызывающему коду хоть что-то.

Обратите внимание, что тройка Хоара вообще никакого отношения к ООП не имеет. Более того, весь LINQ – это воплощение функционального стиля программирования, описать контракты которого существенно проще, чем, например, для ОО-классов коллекций.

В недавнем интервью Бертран Мейер как раз подчеркивал важность ФП-техник для обеспечения корректности кода. Посудите сами, какой контракт проще проанализировать: контракт метода с массой побочных эффектов или контракт ФП-метода без побочных эффектов? Контракт чистой функции очевиден: все что идет ей на вход является частью предусловия, а постусловие выражается в качестве возвращаемого значения! Контракт экземплярного метода с четырьмя изменяемыми полями потенциально содержит 4 входных аргумента и 4 выходных аргумента.

И в этом же плане неизменяемые типы являются отличным инструментом любого ОО разработчика. Контракт неизменяемого типа проще, поскольку единственным местом проверки контракта является конструктор. При этом предусловие конструктора автоматом становится инвариантом класса, ведь все, что истинно в конструкторе останется истинным на протяжении всего времени жизни объекта!

Так что насчет Контракты vs. Монады?

Да, кажется я несколько отвлекся от исходной темы. Так вот, проясню в качестве заключения: всяческие монады, и методы расширения для упрощения обхода графов объектов упрощают control flow, но они не имеют никакого отношения к тому, что делают контракты!

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

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

Дополнительные ссылки

• Анонс встречи Kiev ALT.NET
• Борьба с "нулевыми" ссылками в C#
• Мой R# Plugin для упрощения контрактного программирования
• Интервью с Бертраном Мейером
• О вреде изменяемых значимых типов
• О культе карго в программировании
• Проектирование по контракту. Корректность ПО
• Принцип замещения Лисков и контракты
• Контракты, состояние и юнит-тесты

З.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)