Estou ciente de que o conceito de invariantes existe em vários paradigmas de programação. Por exemplo, invariantes de loop são relevantes em OO, programação funcional e processual.

No entanto, um tipo muito útil encontrado no OOP é um invariante dos dados de um tipo específico. É isso que estou chamando de "invariantes baseados em tipo" no título. Por exemplo, um Fractiontipo pode ter um numeratore denominator, com o invariante que a sua gcd é sempre 1 (isto é, a fracção está numa forma reduzida). Só posso garantir isso tendo algum tipo de encapsulamento do tipo, não permitindo que seus dados sejam configurados livremente. Em troca, nunca tenho que verificar se é reduzido, para simplificar algoritmos como verificações de igualdade.

Por outro lado, se eu simplesmente declarar um Fractiontipo sem fornecer essa garantia por meio do encapsulamento, não posso escrever com segurança nenhuma função nesse tipo que assuma que a fração seja reduzida, porque no futuro alguém mais poderia aparecer e adicionar uma maneira de se apossar de uma fração não reduzida.

Geralmente, a falta desse tipo de invariante pode levar a:

• Algoritmos mais complexos, pois as pré-condições precisam ser verificadas / garantidas em vários locais
• Violações DRY, pois essas pré-condições repetidas representam o mesmo conhecimento subjacente (que o invariante deve ser verdadeiro)
• Ter que impor condições prévias através de falhas de tempo de execução, em vez de garantias em tempo de compilação

Então, minha pergunta é qual é a resposta da programação funcional para esse tipo de invariante. Existe uma maneira idiomática funcional de conseguir mais ou menos a mesma coisa? Ou há algum aspecto da programação funcional que torna os benefícios menos relevantes?

Algumas linguagens funcionais, como o OCaml, possuem mecanismos internos para implementar tipos de dados abstratos, portanto, reforçando alguns invariantes . Os idiomas que não possuem esses mecanismos dependem do usuário "não olhar embaixo do tapete" para impor os invariantes.

Tipos de dados abstratos no OCaml

No OCaml, os módulos são usados ​​para estruturar um programa. Um módulo possui uma implementação e uma assinatura , sendo o último um tipo de resumo dos valores e tipos definidos no módulo, enquanto o primeiro fornece as definições reais. Isso pode ser pouco comparado ao díptico .c/.hfamiliar aos programadores em C.

Como exemplo, podemos implementar o Fractionmódulo assim:

# module Fraction = struct
  type t = Fraction of int * int
  let rec gcd a b =
    match a mod b with
    | 0 -> b
    | r -> gcd b r

  let make a b =
   if b = 0 then
     invalid_arg "Fraction.make"
   else let d = gcd (abs a) (abs b) in
     Fraction(a/d, b/d)

  let to_string (Fraction(a,b)) =
    Printf.sprintf "Fraction(%d,%d)" a b

  let add (Fraction(a1,b1)) (Fraction(a2,b2)) =
    make (a1*b2 + a2*b1) (b1*b2)

  let mult (Fraction(a1,b1)) (Fraction(a2,b2)) =
    make (a1*a2) (b1*b2)
end;;

module Fraction :
  sig
    type t = Fraction of int * int
    val gcd : int -> int -> int
    val make : int -> int -> t
    val to_string : t -> string
    val add : t -> t -> t
    val mult : t -> t -> t
  end

Esta definição agora pode ser usada assim:

# Fraction.add (Fraction.make 8 6) (Fraction.make 14 21);;
- : Fraction.t = Fraction.Fraction (2, 1)

Qualquer pessoa pode produzir valores da fração de tipo diretamente, ignorando a rede de segurança incorporada em Fraction.make:

# Fraction.Fraction(0,0);;
- : Fraction.t = Fraction.Fraction (0, 0)

Para evitar isso, é possível ocultar a definição concreta do tipo Fraction.tassim:

# module AbstractFraction : sig
  type t
  val make : int -> int -> t
  val to_string : t -> string
  val add : t -> t -> t
  val mult : t -> t -> t
end = Fraction;;

module AbstractFraction :
sig
  type t
  val make : int -> int -> t
  val to_string : t -> string
  val add : t -> t -> t
  val mult : t -> t -> t
end

A única maneira de criar um AbstractFraction.té usar a AbstractFraction.makefunção

Tipos de dados abstratos no esquema

A linguagem do esquema não possui o mesmo mecanismo de tipos abstratos de dados que o OCaml. Ele conta com o usuário "não olhando embaixo do tapete" para alcançar o encapsulamento.

No esquema, é habitual definir predicados, como fraction?reconhecer valores, dando a oportunidade de validar a entrada. Na minha experiência, o uso dominante é permitir que o usuário valide sua entrada, se forjar um valor, em vez de validar a entrada em cada chamada da biblioteca.

No entanto, existem várias estratégias para impor a abstração dos valores retornados, como retornar um fechamento que gera o valor quando aplicado ou retornar uma referência a um valor em um pool gerenciado pela biblioteca - mas nunca vi nenhum deles na prática.

Encapsulamento não é um recurso que acompanha o OOP. Qualquer linguagem que suporte modularização adequada possui.

Aqui está mais ou menos como você faz isso em Haskell:

-- Rational.hs
module Rational (
    -- This is the export list. Functions not in this list aren't visible to importers.
    Rational, -- Exports the data type, but not its constructor.
    ratio,
    numerator,
    denominator
    ) where

data Rational = Rational Int Int

-- This is the function we provide for users to create rationals
ratio :: Int -> Int -> Rational
ratio num den = let (num', den') = reduce num den
                 in Rational num' den'

-- These are the member accessors
numerator :: Rational -> Int
numerator (Rational num _) = num

denominator :: Rational -> Int
denominator (Rational _ den) = den

reduce :: Int -> Int -> (Int, Int)
reduce a b = let g = gcd a b
             in (a `div` g, b `div` g)

Agora, para criar um Rational, você usa a função ratio, que impõe a invariável. Como os dados são imutáveis, você não pode mais tarde violar o invariável.

No entanto, isso custa algo para você: não é mais possível que o usuário use a mesma declaração de desconstrução que o denominador e o numerador.

Você faz da mesma maneira: crie um construtor que imponha a restrição e concorde em usá-lo sempre que criar um novo valor.

multiply lhs rhs = ReducedFraction (lhs.num * rhs.num) (lhs.denom * rhs.denom)

Mas Karl, no OOP, você não precisa concordar em usar o construtor. Sério?

class Fraction:
  ...
  Fraction multiply(Fraction lhs, Fraction rhs):
    Fraction result = lhs.clone()
    result.num *= rhs.num
    result.denom *= rhs.denom
    return result

De fato, as oportunidades para esse tipo de abuso são menores no PF. Você tem que colocar o construtor por último, por causa da imutabilidade. Eu gostaria que as pessoas parassem de pensar no encapsulamento como algum tipo de proteção contra colegas incompetentes, ou como obvia a necessidade de comunicar restrições. Não faz isso. Apenas limita os lugares que você deve verificar. Bons programadores de FP também usam encapsulamento. Ele vem apenas na forma de comunicar algumas funções preferidas para fazer certos tipos de modificações.