Шаблон нулевого объекта

Ответ Мэтта Патнэма точен, и я его поддерживаю. Я бы добавил вот что: понятие «нулевой объект», когда вы его анализируете, похоже, сводится к математическому понятию < сильный>моноид. Вы можете думать об этом так: моноид — это тип, который имеет обе эти вещи:

1. "Добавление", "суммирование" или аналогичная операция, которая должна быть ассоциативной: a.op(b).op(c) совпадает с a.op(b.op(c)).
2. "Пустое", "нулевое" или "нулевое" значение, которое действует как нейтральный элемент или элемент идентификации операции.

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

Теперь проблема, с которой вы сталкиваетесь в своем примере Car, заключается в том, что Car на самом деле не является моноидом; нет понятия «пустая машина» или «нейтральная машина», и на самом деле нет разумной операции, которую вы могли бы использовать для объединения двух Car в один.

Таким образом, вы правильно получаете рекомендацию использовать что-то вроде Java 8 Optional< /а>. И фишка в том, что независимо от типа T, Optional<T> — это моноид:

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

Нулевая машина не имеет смысла. В этом случае кажется более подходящим, чтобы getCar() возвращал Optional<Car>.

Если вы не видите в этом смысла, то, вероятно, эта парадигма вам не подходит. Вся идея объектно-ориентированного программирования состоит в том, чтобы упростить ВАС. Не попадайте в ловушку, думая, что вам нужно перенять чью-то сложную систему, основанную на шаблонах. Часто требуется значительный объем работы, чтобы изучить различные шаблоны и эффективно их использовать, поэтому лучше дорасти до них, а не пытаться заставить себя их использовать.

Что касается этого конкретного шаблона, то он предполагает определенный стиль программирования, который может вам не подойти. Я бы никогда не использовал его сам, потому что я возвращаю нули как допустимые значения (отсутствующие данные), которые обрабатываются по-разному в каждом случае, поэтому «централизованная обработка» не имеет для меня смысла. Когда я возвращаю логические значения, я использую примитивы.

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

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

Если многие сервисы используют CarFactory, намного проще, чтобы Carfactory обрабатывал нулевой результат, чем каждый отдельный сервис. Кроме того, он гарантирует, что каждый нулевой результат обрабатывается одинаково, будь то ничегонеделание или определенная логика. Недостатком является то, что если это не обрабатывается правильно, это может привести к некоторым временным запутанным ошибкам (особенно потому, что исключения с нулевым указателем кричат ​​​​громко и гордо).

Я действительно больше не использую его. Существуют альтернативы использованию нулевых проверок, например использование Java 8 Optional. Есть люди, которые за и против этого, и это ни в коем случае не замена шаблону нулевого объекта.

String result = Optional.ofNullable(someInteger)
   .map(Integer::valueOf)
   .map(i -> i + 1)
   .map(Object::toString)
   .orElse("number not present");

System.out.println(result);

Шаблон проектирования NULL заполняет ОТСУТСТВИЕ объекта поведением ПО УМОЛЧАНИЮ и должен использоваться только тогда, когда один объект взаимодействует с другим.

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

Например, рассмотрим приведенный ниже пример псевдокода. Это простой класс Customer, который делегирует расчет скидки объекту скидки.

class Customer {
    IDiscount dis = new NormalDiscount();
    public double CalculateDiscount() {
        return dis.Calculate();
    }
    // Code removed for simplicity
}

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

class DefaultedCustomer : Customer {
    IDiscount dis = null;
    public double CalculateDiscount() {
        return dis.Calculate(); <---- This will crash in parent
    }
    // Code removed for simplicity
}

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

Таким образом, вместо того, чтобы исправлять это технически, проверяя NULL, мы можем создать класс DEFAULT DISCOUNT BEHAVIOR, как показано ниже, который возвращает нулевую скидку и использует то же самое для клиента по умолчанию. Это более чисто, чем проверка NULL.

public class DefaultDiscount : IDiscount {
    public void Calculate() {
        return 0;
    }
}

Нулевые значения необходимы, но для обработки исключений, а не для исправления отсутствия объекта в сотрудничестве, как показано выше. Шаблон проектирования NULL не имеет смысла, если нет совместной работы.

Из-за шаблона проектирования NULL проверки NULL избегаются, но это скорее последующий эффект и побочное преимущество, а не основное намерение.

Все вышеизложенные мысли я взял из этого паттерна NULL Design в C#, который объясняет, что можно и чего нельзя делать с NULL.

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

При возврате автомобиля вы должны проверить if(car != null). Точно так же при доступе к необязательным вы ДОЛЖНЫ проверить if(car.isPresent()), затем car.get().

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

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

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

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