В C# с типами все в порядке

Полностью не согласен. Иначе можно дойти до:
Зачем нам нужна эта противная сборка мусора. Всегда были стандартные средства для ручного управления памятью. Усложнять систему созданием гарбадж коллектора совсем необязательно.

И вообще основной смысл систем со статической типизацией: отловить потенциальную ошибку до того, как код вообще станет рабочим. Вариант с Option/Maybe/Nullable крайне хорош в этом плане. Контракты несколько хуже.

Основная проблема null, в том что он не сохраняет тип. Зачем это нужно хорошо описано в Types and Programming Languages

В целом поддерживаю (поставил плюс статье), однако есть несколько замечаний/предложений:

1.

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

— а почему вы решили, что контейнер Maybe обязательно должен быть ссылочным типом? Что мешает его сделать значимым, наподобие контейнера Nullable? В критикуемой вами статье есть таблица с реализациями, так вторая реализация Strilanc — May использует значимый тип (public struct May<T> : IMayHaveValue, IEquatable<May<T>>).

2.

В случае если метод ModifyItem подменил объект, то метод SomeMethod вернет контейнер со старым объектом. Иди потом, ищи этот баг.

— а вот здесь поподробнее, пожалуйста. Метод SomeMethod() из вашего примера вернёт старый объект в контейнере лишь и только в том случае, если при создании экземпляра контейнера Maybe его код выполняет глубокую копию своего значения и сохраняет именно эту копию. Все же контейнеры, если они написаны адекватно, хранят лишь ссылку на значение, которая может быть NULL (в этом случае метод контейнера HasValue возвратит false).

3. В целом же я согласен со статьёй, и для себя в таких ситуациях использую шаблон Boolean TryGet(ID, out Result).

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

Data access layer должен достать объект из репозитория и передать клиенту. Он не знает как обработать отсутствие объекта и вообще не в курсе плохо ли это. За это отвечает уровень логики.

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

Очень тяжело сопоставить предыдущую статью и эту, ощущение что они обе из разных областей.
В первой озвучивается типичный для меня при следовании DDD подход к реализации Repository: методы Get и Find (в практике еще часто встречаю метод Exists для других сценариев). При чем первый не должен возвращать null ни в коем случае — либо результат, либо exception, который должен быть более конкретным чем NRE, хотя бы RecordNotFound.

Второй момент в исходной статье — Null Object pattern, который в приведеннои примере позволяет следовать функциональному («ленивому») подходу.

Контракт сам по себе — описывает как должна вести себя система. Раньше такое делали при помощи Assert'ов (по крайней мере во время c++ & mfc 4.2), а теперь с контрактами можно хоть на интерфейс проверки навесить.

В данной же статье «забыт» метод Find, остается только Get и усиленно критикуется.
Ну и про Null Object pattern:

Ссылочный тип может ссылаться на null. Зачем засовывать один ссылочный тип в другой и добавлять в контейнер свойство HasValue, для меня решительно не понятно.

Типичная реализация, вполне согласована с Nullable<> по синтаксису.
А приведенный код где используется ref вообще никак не согласуется с предыдущим «функциональным» принципом (согласно книге Framework Design Guidelines кода с ref и out следует избегать).

> Ссылочный тип может ссылаться на null. Зачем засовывать один ссылочный тип в другой и добавлять в контейнер свойство HasValue, для меня решительно не понятно. Для проверки на HasValue? Что мешает обратится к содержимому объекту без этой проверки? Можно точно так-же безалаберно не проверить на null через неравенство.

У null нет семантики. Это что-то из до ООП мира C. Он не значит «значение найдено, это пустое значение» или «значение не найдено».

Использование Maybe даёт понимание когда данные вернулись, а когда нет. И заставляет проконтролировать наличие возврата.

> В случае если метод ModifyItem подменил объект, то метод SomeMethod вернет контейнер со старым объектом. Иди потом, ищи этот баг.

Когда SomeMethod может изменять аргумент, а тем более заменять его? Аргументы должны быть immutable.

Посмотрите на функциональные языки, поймете откуда Maybe берет свои истоки.
В новых языках (например котлине) из коробки есть nullability check — все типы могут Nullable или нет (определяется знаком вопроса в декларации типа).
На практике null это исключение, а не наоборот. Поэтому выделять nullable значение в отдельную сущность — удобно.
Одно из решений — ввести аттрибуты: Nullable/NotNull (говорю про яву), но есть и решение средствами языка — как раз описанная возможность с помощью Maybe.
И мне кажется это хорошо повышает как безопасность кода по поводу NullRefExc, так и его читаемость. Конечно же если весь код написан в таком стиле.

>> Maybe добавляет сложности, но не добавляет решений.
Решение NullRefExc оно точно добавляет.

Как ещё один вариант: паттерн special case. Фаулер обычно дело говорит. Если репозиторий может вернуть NULL вместо пользователя, то пусть это (в некоторых случаях) будет NullUser.

Я уже писал в той статье, проблему решат нультипы. Если объект не найден то вернуть заранее созданый валидный спец объект этого же типа. После этого, можно обрабатывать логику на любом уровне. А все промежуточные слои не трогать, пусть они выполняют только свою работу. Очень полезно при изменчивой разработке, когда логика пишется параллельно с данными. Можно добавлять данные и удалять, менять проверки и все будет работать.

Можно втиснуть проверку на null внутрь метода и в случае, если объект не найден, бросить Exception. Но этим мы просто переименовываем NullReferenceException в, к примеру, ItemNotFoundException.
Выброс исключения делает не с целью замены NRE на что то другое, а для лучшей диагностики ошибок. Чтобы исключение возникло именно тогда, когда у тебя уехала логика. Если ты не кинешь исключение, то NRE у тебя возникнет через пол часа в коде абсолютно не связанным с GetItem

На самом деле, как мне кажется, можно и исключение кидать, и null вернуть, если логика приложения подразумевает такую возможность.

Спор здесь очень странный развернулся — надо или не надо возвращать null. Вам не кажется, что это вообще-то зависит от того, может вообще «не быть» передаваемого объекта, или нет?

Скажем, если я возвращаю трамвайный билет тому, кто дал мне деньги (я — кондуктор), то вариант null означает поломку в системе и его надо оборачивать исключением, которое отобразится в виде «обратитесь к разработчику — вот вам лог».

А если я возвращаю ФИО человека по его номеру телефона, то null — обычное дело и должен обрабатываться (в зависимости от ситуации) на уровне пользовательского интерфейса — я вижу 2 случая: телефон не валиден, телефон не личный (а корпоративный, например) и владельца как такового нет. Про оба случая должен узнать пользователь (или как минимум контроллер)

Во втором примере надо вернуть null контроллеру — пусть разбирается, что с ним делать. Это уже не вопрос dao.

А оборачивать null во что-то, чтобы его не проверять — это почти то же самое, что пытаться спрятаться в песок от опасности (да, я знаю, что страуссы так не делают, зато так делают некоторые люди) :)

А такой вариант с поддержкой LINQ автор тоже раскритикует?

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

1. Автор приводит несколько, назовем их так, странные реализации GetItem, неявно постулируя, что они вытекают из первичной статьи. Однако же, они из нее ничуть не следуют.

Из нее может следовать, например, вот такая реализация, гарантирующая либо объект, либо исключение:

public Item GetItem(int itemId)
{
    return dataAccessor
		.getItemById(itemId)
		.ToMaybe()
		.OrElse(() => new ItemNotFound(itemId));
}

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

public Maybe<Item> FindItem(int itemId) // а Get выше тогда должен реализовываться через этот Find для устранения дублирования
{
    return dataAccessor.getItemById(itemId).ToMaybe(); 
}

2.

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

При этом «противоречие принципам» автор иллюстрирует якобы необходимостью вставить в сторожевое условие сам код метода:

Что бы достать объект из репозитория, нужно сначала вытащить объект из репозитория.

Но если мы посмотрим на GetItem из п.1 моего комментария, то видим, что туда нужно только вставить Contract.Ensures(Contract.Result() != null); и более ничего; никакого коллапса вселенной бесконечной рекурсии это не вызывает.

3.

Правда в том, что никто не может гарантировать существование объекта в репозитории.

Я уже писал, что именно репозитории тут не специфичны. Но если в каком-то конкретном случае правда именно в этом (что объекта где-то может быть), я вовсе не предлагаю пытаться гарантировать наличие объекта, а предлагаю явно выразить эту правду, вернув Maybe.

4.

Я перефразирую: nullable reference. Масло масляное

Только потому кажется «масляным», что в виду ошибки проектирования языка классы в Algol C# по умолчанию снабжены значением null.

Anthony Hoare

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W)…

посмотреть на человека-легенду

Если старичок Хоар покажется слишком далеким от нашего времени, вот цитата из Барта Де Смета, для .NET человека «изнутри», книга C# Unleashed, одна из Must-Read по классификации замечательного SergeyT:

Цитирую врезку из этой книги под характерным названием «Жизнь без null»

Давайте явно уясним одну вещь: (a) возможность/невозможность принимать значение null и (b) различие между значимыми и ссылочными типами — это ((a) vs (b)) ортогональные (независимые) свойства и это правильно. Было бы хорошо, если бы любой тип мог явно задекларировать, поддерживает ли он значение null, или нет.

И далее по тексту Барт говорит, что проектировщики C# не могли сделать эту ортогональность полной, т.е. в классах нет возможности «отключить null», и это вызвано лишь причинами совместимости. Например, в экспериментальном Spec# (где можно не думать так сильно о совместимости) такая возможность есть.

И раз современные средства позволяют в некотором локальном пространстве (проекте) ее исправить, то странно говорить о том, что это неверный подход. Что не мешает ему быть неоправданным в конкретном проекте по тысяче разных причин.

5.

Что мешает обратится к содержимому объекту без этой проверки? Можно точно так-же безалаберно не проверить на null через неравенство.

Я считаю, что вероятность первого много ниже, чем вероятность второго. Чтобы обратиться к содержимому Maybe без проверки, нужно совершить явное действие — добавить «.Value». Чтобы не проверить на null делать не нужно ничего, это уже сделано :).

Спотыкание об это «.Value» — это вроде как если бы у программиста был ангел-хранитель, который при каждом случае, когда тот написал GetSome().DoStuff(), волшебным образом смотрел бы в исходник GetSome(), и при необходимости стучал бы его по плечу и говорил: «А кстати, там может быть null».

Замечу, что как раз невозможность случайно игнорировать Maybe здорово стимулирует к тому, чтобы проектировать систему с минимальным количеством необязательных возвращаемых значений. И оказывается, что далеко не так часто нужны nullable-классы, как это кажется на первый взгляд. Они нужны приблизительно так же часто, как nullable-структуры. Иногда.

6. Для аргументирования вредности подхода автор приводит код:

public Maybe<Item> SomeMethod()
{
    var mbItem = GetMbItem();

    if(mbItem.HasValue)
    {
        var item = mbItem.Value;

        ModifyItem(ref item); 
    }

    return mbItem;
}

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

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

public Maybe<Item> SomeMethod()
{
    return GetMbItem().Select(ModifyItem);
}

где ModifyItem имеет вид Item ModifyItem(Item item){...}

Или, если очень приспичило, даже с ref:

public Maybe<Item> SomeMethod()
{
    return GetMbItem().Select(i => { ModifyItem(ref i); return i; });
}

7. Что же касается тезиса

для того, чтобы не допускать NullReferenceException, нужно быть внимательным,

готов принять даже более широкий тезис, например, такой: «нужно быть внимательным».

И да удастся это нам всем :)