Алгебраические типы данных и моделирование данных

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

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

Попутно возникают интересные проблемы, когда мы вводим новые типы для выражения концепции в нашем коде, будь то конкретная или абстрактная. И это как раз та тема, которую мы собираемся немного обсудить. Но прежде чем мы начнем, обратите внимание, что доступно довольно много вариантов, и я не собираюсь спорить, какой из них лучше другого. Вместо этого я хотел бы продемонстрировать, как использовать Алгебраические типы данных (ADT) в статически типизированном языке программирования для выполнения одной конкретной задачи, а затем посоветовать вам больше узнать об этом, попробовать, узнать его плюсы и минусы. , и на основе этого принимать собственные решения. Я буду использовать C ++ и Haskell, однако эти идеи можно применить и к другим языкам программирования.

Типы классные, давайте познакомимся с некоторыми

Рассмотрим следующий тип C ++, предназначенный для выражения результата операции чтения по каналу связи:

template <typename T>
struct ReadResult {
  enum class State {
    SUCCESS, FAILURE
  };
  State state;
  T payload;
  std::string error_code;
};

Возникают следующие вопросы: что означает полезная нагрузка, когда состояние равно Failure? Или, что эквивалентно, что означает error_code, когда state равно Success? Возможно, для T. не может даже существовать конструктор по умолчанию.

Я бы сказал, что это недопустимые сценарии. Однако, что касается наших типов, мы допускаем эти сценарии.

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

Сделать это необязательным или нет?

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

template <typename T>
struct ReadResult {
  enum class State {
    SUCCESS, FAILURE
  };
  State state;
  std::optional<T> payload;
  std::optional<std::string> error_code;
};

Теперь мы можем представлять «пустые» типы, используя нулевые параметры, то есть std :: nullopt. Код отлично компилируется даже для типа T, который не предоставляет конструктор по умолчанию.

Однако я бы сказал, что он просто исправляет проблему, а не исправляет ее, потому что мы все еще можем представлять недопустимые сценарии, то есть доступ к полезной нагрузке, когда state равно ОТКАЗ.

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

Либо то, либо то

Если мы внимательно проверим ReadResult ‹T›, мы увидим, что состояние не так тесно связано с полезной нагрузкой и error_code Как бы то ни было, возможные состояния и их соответствующие значения должны быть прочно связаны вместе таким образом, чтобы каждое возможное состояние выставляло только те элементы, которые имеют для него смысл.

template <typename T>
struct Success {
  T payload;
};
struct Failure {
  std::string error_code;
};
template <typename T>
using ReadResult = std::variant<Failure, Success<T>>;

data ReadResult a = Failure String | Success a

type ReadResult a = Either String a