Цепочка проверки в Scala

Довольно просто преобразовать каждый Option в экземпляр правильной проекции Either:

def validateConfig(config: Config): Either[String, Config] = for {
  _ <- config.emailAddress.toRight("Email Address").right
  _ <- config.firstName.toRight("First Name").right
  _ <- config.lastName.toRight("Last Name").right
  _ <- config.password.toRight("Password").right
} yield config

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

Если вы предпочитаете получить Try, вы можете просто преобразовать полученное Either:

import scala.util._

val validate: Config => Try[Config] = (validateConfig _) andThen (
  _.fold(msg => Failure(new IllegalArgumentException(msg)), Success(_))
)

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

Это case-класс, так почему бы вам не использовать сопоставление с образцом?

def validateConfig(config: Config): Try[Config] = config match {
  case Config(None, _, _, _) => Failure(new IllegalArgumentException("Email Address")
  case Config(_, None, _, _) => Failure(new IllegalArgumentException("First Name")
  case Config(_, _, None, _) => Failure(new IllegalArgumentException("Last Name")
  case Config(_, _, _, None) => Failure(new IllegalArgumentException("Password")
  case _ => Success(config)
}

В вашем простом примере моим приоритетом было бы забыть монады и цепочки, просто избавиться от этого неприятного if...else запаха.

Однако в то время как класс case отлично работает для короткого списка, для большого количества параметров конфигурации это становится утомительным и возрастает риск ошибки. В этом случае я бы рассмотрел что-то вроде этого:

1. Добавьте метод, который возвращает карту ключей-> значений параметров конфигурации, используя имена параметров в качестве ключей.
2. Попросите метод Validate проверить, является ли какое-либо значение на карте None
3. Если такого значения нет, вернуть успех.
4. Если хотя бы одно значение совпадает, верните это имя значения с ошибкой.

Итак, если предположить, что где-то определено

type OptionMap = scala.collection.immutable.Map[String, Option[Any]]

и класс Config имеет такой метод:

def optionMap: OptionMap = ...

то я бы написал Config.validate так:

def validate: Either[List[String], OptionMap] = {
  val badOptions = optionMap collect { case (s, None) => s }
  if (badOptions.size > 0)
    Left(badOptions)
  else
    Right(optionMap)
}

Итак, теперь Config.validate возвращает либо Left, содержащее имя всех неверных параметров, либо Right, содержащее полную карту параметров и их значения. Честно говоря, вероятно, не имеет значения, что вы поместите в Right.

Теперь все, что хочет проверить Config, просто вызывает Config.validate и проверяет результат. Если это Left, он может выдать IllegalArgumentException, содержащий одно или несколько названий неверных вариантов. Если это Right, он может делать все, что захочет, зная, что Config действителен.

Таким образом, мы могли бы переписать вашу функцию validateConfig как

def validateConfig(config: Config): Try[Config] = config.validate match {
  case Left(l) => Failure(new IllegalArgumentException(l.toString))
  case _ => Success(config)
}

Вы видите, насколько более функциональным становится и объектно-ориентированный подход?

• Нет императивной цепочки if...else
• Объект Config проверяет себя
• Последствия недопустимости объекта Config остаются на усмотрение более крупной программы.

Я думаю, что реальный пример был бы еще более сложным. Вы проверяете параметры, говоря: «Содержит ли он Option[String] или None?» но не проверяя действительность самой строки. Действительно, я думаю, что ваш класс Config должен содержать карту опций, где имя сопоставляется со значением и с анонимной функцией, которая проверяет строку. Я мог бы описать, как расширить приведенную выше логику для работы с этой моделью, но я думаю, что оставлю это вам в качестве упражнения. Я дам вам подсказку: вы можете захотеть вернуть не только список неудачных вариантов, но и причину отказа в каждом случае.

Да, кстати... Я надеюсь, что ни один из вышеперечисленных не означает, что я думаю, что вы должны хранить параметры и их значения как optionMap внутри объекта. Я думаю, что полезно иметь возможность извлекать их таким образом, но я бы никогда не поощрял такое раскрытие фактического внутреннего представления;)

Вот решение, которое я придумал после некоторого поиска и чтения scaladocs:

def validateConfig(config: Config): Try[Config] = {
  for {
    _ <- Try(config.emailAddress.
             getOrElse(throw new IllegalArgumentException("Email address missing")))
    _ <- Try(config.firstName.
             getOrElse(throw new IllegalArgumentException("First name missing")))
    _ <- Try(config.lastName.
             getOrElse(throw new IllegalArgumentException("Last name missing")))
    _ <- Try(config.password.
             getOrElse(throw new IllegalArgumentException("Password missing")))
  } yield config
}

Подобно ответу Трэвиса Брауна.