Validación de parámetros del método en Scala, con para comprensión y mónadas

Si está dispuesto a usar Scalaz, tiene un puñado de herramientas que hacen que este tipo de tarea sea más conveniente, incluida una nueva clase Validation y algunas instancias útiles de clases de tipo sesgadas hacia la derecha para scala.Either normales. Voy a dar un ejemplo de cada uno aquí.

Acumulando errores con Validation

Primero para nuestras importaciones de Scalaz (tenga en cuenta que tenemos que ocultar scalaz.Category para evitar el conflicto de nombres):

import scalaz.{ Category => _, _ }
import syntax.apply._, syntax.std.option._, syntax.validation._

Estoy usando Scalaz 7 para este ejemplo. Tendrías que hacer algo menor cambios de uso 6.

Asumiré que tenemos este modelo simplificado:{[58]]}

case class User(name: String)
case class Category(user: User, parent: Category, name: String, desc: String)

A continuación definiré el siguiente método de validación, que puede adaptar fácilmente si se mueve a un enfoque que no implique la comprobación de valores nulos:

def nonNull[A](a: A, msg: String): ValidationNel[String, A] =
   Option(a).toSuccess(msg).toValidationNel

La parte Nel significa "lista no vacía", y ValidationNel[String, A] es esencialmente lo mismo que Either[List[String], A].

Ahora usamos este método para comprobar nuestros argumentos:

def buildCategory(user: User, parent: Category, name: String, desc: String) = (
  nonNull(user,   "User is mandatory for a normal category")            |@|
  nonNull(parent, "Parent category is mandatory for a normal category") |@|
  nonNull(name,   "Name is mandatory for a normal category")            |@|
  nonNull(desc,   "Description is mandatory for a normal category")
)(Category.apply)

Tenga en cuenta que Validation[Whatever, _] no es una mónada (por las razones discutidas aquí, por ejemplo), pero ValidationNel[String, _] es un funtor aplicativo, y estamos usando ese hecho aquí cuando "levantamos" Category.apply en él. Consulte el apéndice a continuación para obtener más información sobre los funtores aplicativos.

Ahora si escribimos algo como esto:

val result: ValidationNel[String, Category] = 
  buildCategory(User("mary"), null, null, "Some category.")

Obtendremos un fallo con los errores acumulados: {[58]]}

Failure(
 NonEmptyList(
   Parent category is mandatory for a normal category,
   Name is mandatory for a normal category
  )
)

Si todos los argumentos se hubieran comprobado, tendríamos un Success con un valor Category en su lugar.

Fallando rápido con Either

Uno de los útiles las cosas sobre el uso de funtores aplicativos para la validación es la facilidad con la que puede intercambiar su enfoque para el manejo de errores. Si desea fallar en el primero en lugar de acumularlos, esencialmente puede cambiar su método nonNull.

Necesitamos un conjunto ligeramente diferente de importaciones:

import scalaz.{ Category => _, _ }
import syntax.apply._, std.either._

Pero no hay necesidad de cambiar las clases de casos anteriores.

Aquí está nuestro nuevo método de validación:

def nonNull[A](a: A, msg: String): Either[String, A] = Option(a).toRight(msg)

Casi idéntico al anterior, excepto que estamos usando Either en lugar de ValidationNEL, y la instancia de funtor aplicativo predeterminada que Scalaz proporciona para Either no acumula errores.

Eso es todo lo que necesitamos hacer para obtener el comportamiento deseado de fail-fast-no son necesarios cambios en nuestro método buildCategory. Ahora si escribimos esto:

val result: Either[String, Category] =
  buildCategory(User("mary"), null, null, "Some category.")

El resultado contendrá solo el primer error:

Left(Parent category is mandatory for a normal category)

Exactamente como queríamos.

Apéndice: Introducción rápida a los funtores aplicativos

Supongamos que tenemos un método con un único argumento:

def incremented(i: Int): Int = i + 1

Y supongamos también que queremos aplicar este método a algunos x: Option[Int] y obtener un Option[Int] espalda. El hecho de que Option es un funtor y por lo tanto proporciona un método map hace que esto sea fácil:

val xi = x map incremented

Hemos "levantado" incremented en el funtor Option; es decir, esencialmente hemos cambiado una función de mapeo Int a Int en una de mapeo Option[Int] a Option[Int] (aunque la sintaxis se enturbia un poco, la metáfora de "levantamiento" es mucho más clara en un lenguaje como Haskell).

Ahora supongamos que queremos aplicar el siguiente método add a x y y de una manera similar.

def add(i: Int, j: Int): Int = i + j

val x: Option[Int] = users.find(_.name == "John").map(_.age)
val y: Option[Int] = users.find(_.name == "Mary").map(_.age) // Or whatever.

El hecho de que Option es un funtor no es suficiente. El hecho de que es una mónada, sin embargo, lo es, y podemos usar flatMap para obtener lo que queremos:

val xy: Option[Int] = x.flatMap(xv => y.map(add(xv, _)))

O, equivalentemente:

val xy: Option[Int] = for { xv <- x; yv <- y } yield add(xv, yv)

En cierto sentido, sin embargo, la monadez de Option es excesiva para esta operación. Hay una abstracción más simple-llamado un aplicativo funtor-que es entre un funtor y una mónada y eso proporciona toda la maquinaria que necesitamos.

Tenga en cuenta que entre en un sentido formal: cada mónada es un aplicativo functor, cada aplicativo functor es un functor, pero no todo el aplicativo functor es una monada, etc.

Scalaz nos da una instancia de funtor aplicativo para Option, por lo que podemos escribir lo siguiente:

import scalaz._, std.option._, syntax.apply._

val xy = (x |@| y)(add)

La sintaxis es un poco extraña, pero el concepto no es más complicado que el funtor o ejemplos de mónadas anteriores - solo estamos elevando add en el funtor aplicativo. Si tuviéramos un método f con tres argumentos, podríamos escribir lo siguiente:{[58]]}

val xyz = (x |@| y |@| z)(f)

Y así sucesivamente.

Entonces, ¿por qué molestarse con los funtores aplicativos en absoluto, cuando tenemos mónadas? En primer lugar, simplemente no es posible proporcionar instancias de mónada para algunas de las abstracciones con las que queremos trabajar-Validation es el ejemplo perfecto.

Segundo (y relacionado), es solo una práctica de desarrollo sólida para utilice la abstracción menos poderosa que hará el trabajo. En principio, esto puede permitir optimizaciones que de otra manera no serían posibles, pero lo más importante es que hace que el código que escribimos sea más reutilizable.