Clojure: Record, protocol e multi method

Records, Java e OO - Introdução

Boas vindas ao curso Clojure: record, protocol e multimethod!

Em nossas aulas, veremos sobre diversas questões importantes da própria linguagem e do mundo de Clojure em relação ao seu redor.

Costumamos rodar em cima de uma virtual machine de Java, mas também é possível rodar em ClojureScript com outros suportes e outras características. Porém, como a primeira forma é mais comum, temos todo o ambiente de Java para realizar uma interoperação com esta linguagem.

Aprenderemos como trabalhar com sistemas de tipos através de records e protocols para essa interoperabilidade, analisando suas vantagens, características e implicações, bem como suas diferenças em relação as interfaces de Java. Porém, podemos optar por não usar esses recursos, para assim podermos criar nossos próprios componentes orientados a objetos quando fizer sentido dentro de Clojure.

Podemos implementar protocols em classes preexistentes que vão se assemelhar com classes abertas ou métodos de extensão, as quais não são exatamente como em outras linguagens. Veremos como funcionam e quais seriam as vantagens dessas abordagens.

Veremos como criar nosso próprio componente com protocol e record, com característica de orientação a objeto tentando encapsular o comportamento que queremos esconder do usuário final dessa estrutura gerada por nós.

Analisaremos inclusive outras abordagens de composição de comportamento além dessa invocação dinâmica.

Entenderemos mais sobre os multimethods e suas customizações, vantagens e desvantagens baseadas em tipos, vendo como utilizá-los sem depender de records, protocols e orientação a objeto.

Como trabalhamos com chaves, mapas e seus valores até o momento, veremos como fazer o dispatch de forma dinâmica por meio dos multimethods discutindo outras abordagens de outras linguagens que podemos implementar em Clojure, como um mapa de keywords para funções por exemplo.

Aprenderemos sobre esses códigos e suas implementações juntos neste curso.

Então, vamos lá!

Records, Java e OO - O problema das verificações manuais

Para dar início ao nosso curso, crie um novo projeto no IntelliJ IDEA clicando em "Create New Project". Depois, selecione "Clojure" na lista lateral com "Leiningen" e clique em "Next". Nomeie como "hospital" e salve no diretório de sua preferência para finalizar.

Começamos o projeto com um código composto basicamente por elementos que já conhecemos. Porém, a medida que o desenvolvemos, encontraremos problemas que trazem dificuldades no dia-a-dia conforme trabalhamos com tipos de mapas, vetores e escalares tradicionais do Clojure.

Na lista lateral, abra "Project > hospital > src > hospital" para acessar o arquivo core.clj. Comece apagando a função que é exibida automaticamente, deixando apenas o namespace.

Clique com o botão direito em "src > hospital" para selecionar "New > File" e criar um arquivo chamado "aula1.clj" para trabalharmos separadamente explorando alguns recursos. Declare o namespace hospital.aula1.

Dentro, crie uma função adiciona-paciente com defn que adiciona pessoas dentro de uma lista, recebendo tanto os pacientes quanto o paciente que queremos adicionar. pacientes é um hashmap com um número de id que representa cada indivíduo cujos valores são os pacientes em si.

Podemos inserir na definição da função uma documentação que descreve ao usuário como queremos que o parâmetro seja passado.

Primeiro, podemos fazer assoc pacientes na chave :id com paciente, adicionando paciente. Tudo isso pode ser feito dentro de um laço let, passando id com a mesma chave.

Clique com o botão direito sobre "project.clj" na lista lateral e selecione "Run 'REPL for hospital'" para executar.

Em seguida, crie outra função para teste chamada testa-uso-de-pacientes que não recebe nada para teste. Dentro, defina let para pacientes sendo vazio e um paciente guilherme cujo :id é 15, sendo :nome "Guilherme" com data de :nascimento "18/9/1981".

Depois deste laço, podemos chamar o adiciona-paciente para pacientes e guilherme, imprimindo o resultado com pprint. Não esqueça de importar esse recurso com :use no topo do código.

Por fim, invoque o (testa-uso-de-pacientes) e use o atalho "Ctrl + Shift + L" para carregar o arquivo.

(ns hospital.aula1)
    (:use clojure.pprint))

(defn adiciona-paciente
    "Os pacientes são um mapa da seguinte forma { 15 {paciente 15}, 23 {paciente 23} }.
    O paciente { :id 15 ... }"
    [pacientes paciente]
    (let [id (:id paciente)]
        (assoc pacientes id paciente)))

(defn testa-uso-de-pacientes []
    (let [pacientes {}
            guilherme {:id 15, :nome "Guilherme", :nascimento "18/9/1981"}]
        (pprint (adiciona-paciente pacientes guilherme))))

(testa-uso-de-pacientes

Com o código funcionando, podemos adicionar mais pacientes fictícios à lista realizando outros testes. Poderíamos chamar vários let, reduce entre outras maneiras.

Faremos da maneira mais simples por enquanto, copiando e colando as linhas de pprint para cada paciente alterando os nomes.

(defn testa-uso-de-pacientes []
    (let [pacientes {}
            guilherme {:id 15 :nome "Guilherme" :nascimento "18/9/1981"}]
            daniela {:id 20 :nome "Daniela" :nascimento "18/9/1982"}
            paulo { :nome "Paulo", :nascimento "18/10/1983"}
            ]
        (pprint (adiciona-paciente pacientes guilherme))
        (pprint (adiciona-paciente pacientes daniela))
        (pprint (adiciona-paciente pacientes paulo))
        ))

(testa-uso-de-pacientes)

O resultado no REPL é um nulo para Paulo. Isso acontece porque adiciona-paciente recebe um mapa que segue o padrão de lista de pacientes e um paciente que também segue o mesmo padrão. Então, por mais que a função esteja esperando um tipo simples que responda à função :id, é importante que Paulo possua um id, afinal é este que é utilizado no assoc.

Quando passamos Paulo sem id, chama-se o paciente usado com valor nulo pois está vazio. Então, o :id é nulo porque o chama dentro de paciente sem possuir seu número de identificação, associando à chave nula, e não é o que queremos.

O problema aqui é de tipos e garantias. Poderíamos querer ter uma garantia de que quem chama a função adiciona-paciente está passando um paciente que tem um id próprio. Também poderíamos apenas deixar um valor padrão, como 1 no let de adiciona-paciente, mas ainda assim não é o que queremos.

Em algumas situações de programas podemos resolver esse tipo de questão com um valor padrão, mas não sempre. Neste caso, não resolve.

Poderíamos tentar desconstruir o mapa paciente já extraindo o id, o que geraria o mesmo problema. Logo, temos que pensar o que fazer caso não consigamos um padrão desejado e não seja passado o que deveria ser passado.

Seria possível verificar essa passagem com um if dentro de let dessa mesma função. Caso id tenha sido passado, associamos. Caso não, podemos lançar uma exceção.

Como já vimos alguns casos de erros de erro, podemos usar throw com uma exception padrão do Clojure chamada ex-info, a qual recebe uma mensagem "paciente não possui id" e um mapa com alguns valores como dica para quem tratará os bugs do programa.

Por exemplo, poderíamos passa o :paciente como sendo o próprio paciente em exceção.

(defn adiciona-paciente
    "Os pacientes são um mapa da seguinte forma { 15 {paciente 15}, 23 {paciente 23} }.
    O paciente { :id 15 ... }"
    [pacientes paciente]
    (let [id (:id paciente)]
        (if id
            (assoc pacientes id paciente)
            (throw (ex-info "Paciente não possui id" {:paciente paciente})))))

Rodando com esse novo código, a ExceptionInfo é exibida na janela para podermos tratar este erro.

Isso poderia ser no caso de assumirmos que queremos tratar essa condição como uma exceção ao caso. Uma exception costuma ser criada e utilizada quando realmente o que foi passado pela invocação como um erro de desenvolvimento sem precaução.

Refinamos o código para pensar em uma forma de tratar a exceção. No caso de adiciona-paciente, o uso de let e if é tão comum que já existe if-let exercendo as mesmas funções ao substituir o let.

Podemos extrair as duas últimas linhas da definição que contém assoc e throw retirando if. Se tem o id, o programa associa e se não, a exceção é lançada.

(defn adiciona-paciente
    "Os pacientes são um mapa da seguinte forma { 15 {paciente 15}, 23 {paciente 23} }.
    O paciente { :id 15 ... }"
    [pacientes paciente]
    (if-let [id (:id paciente)]
            (assoc pacientes id paciente)
            (throw (ex-info "Paciente não possui id" {:paciente paciente}))))

Ao rodar, o resultado é o esperado. Desta forma, podemos tratar o erro da melhor maneira que acharmos cabível.

O grande problema que estamos discutindo é a não garantia de um mapa, ou seja, devemos validar para o mapa o que achamos necessário e não o contrário. Para ter certeza da validação, entramos nas questões dos tipos; em várias linguagens, criamos nossos próprios tipos para que possamos colocar restrições sobre o que pode ser passado de um lado ao outro.

Por exemplo, gostaríamos que fosse passado apenas um paciente com uma identificação que pode ser dada por uma string, ou inteiro, ou id gerado de maneira específica. Ou ainda, poderíamos querer que pacientes fosse um mapa cujas chaves fossem números ou strings.

As possíveis restrições podem ser colocadas e serão discutidas adiante com várias abordagens, sendo a primeira lembrando um caminho de orientação a objeto, vendo quando utilizar em Clojure ou não.

Records, Java e OO - O record

Vimos que, em certas situações, queremos definir melhor o que é um tipo de valor enviado ou função invocada de um lado ao outro.

Por exemplo, pode ser que queiramos dizer que em nosso sistema, em parte dele ou em determinada função, um paciente é a agregação de três valores: um id, um :nome e um :nascimento.

Comece comentando a linha (testa-uso-de-pacientes) para evitar o erro exibido. Agora, definimos um tipo próprio que funcione como um registro destes três valores.

Por isso, o tipo é defrecord em Clojure chamado Paciente, que possui os três elementos como parâmetro. Não usamos um keyword e sim como um símbolo. A partir de agora, trabalhamos com Paciente fabricando-o usando o símbolo de threading.

Já existe a função ->Paciente, e passamos os três valores: 15, "Guilherme" e "18/9/1981. Imprima com println e rode o seguinte código:

(defrecord Paciente [id nome nascimento])

(println (->Paciente 15 "Guilherme" "18/9/1981"))

O tipo Paciente é definido dentro do namespace hospital.aula1, e por isso aparece no console REPL.

Em seguida, imprima a mesma última linha com pprint ao invés de println e rode novamente. O resultado desta última impressão é um HashMap; aparentemente, um record em Clojure funciona similarmente a um mapa, o que exploraremos mais adiante.

Na prática, Paciente é uma classe de Java, pois Clojure está sendo rodado em uma virtual machine desta linguagem. Desta forma, podemos utilizar as instruções ligadas às suas formas e classes. Por exemplo, podemos utilizar um nome seguido de ., significando a invocação de um construtor de uma classe em Java.

Ao fazermos a interoperabilidade e quisermos instanciar uma classe de Java, basta adicionar . ao final do nome. O construtor recebe um objeto id, nome e nascimento.

Note que Clojure está criando a classe Paciente por debaixo dos panos, com um construtor que recebe os objetos que podem ser de qualquer tipo em Java, como indica a exibição de ^.

Lembrando que em Clojure não forçamos tipos por padrão, qualquer coisa pode ser recebida por Paciente.. Imprima a última linha com pprint e rode no REPL.

(defrecord Paciente [id nome nascimento])

(println (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (Paciente. 15 "Guilherme" "18/9/1981"))

O resultado é o mesmo, demonstrando que . chama o construtor. Se este é chamado e vimos que ^ funciona como uma dica, poderíamos usá-la na interoperabilidade, dizendo que gostaríamos de forçar o tipo ^Long na definição de Paciente.

Assim, um erro é apresentado em ->Paciente. Retire ^Long e tente rodar novamente, mas dessa vez com a ordem dos elementos errada para testarmos.

(defrecord Paciente [id nome nascimento])

(println (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (Paciente. 15 "Guilherme" "18/9/1981"))
(pprint (Paciente. "Guilherme" 15 "18/9/1981"))

O resultado apresenta os valores invertidos, como se 15 fosse o nome, seguindo a ordem da definição do registro.

Quando Clojure cria o construtor, diz que cada um dos elementos é um objeto, pois não falamos em nenhum momento que nome deveria ser uma ^String ao definirmos Paciente, fazendo com que Clojure aceite a troca.

Mesmo se forçássemos que id fosse ^Long, nome e nascimento fossem ^String, ainda poderíamos trocar estes dois últimos. Assim, temos a noção de que tipos não garantem o correto funcionamento do programa.

A vantagem do tipo Paciente não está sendo garantir que cada elemento esteja tipado, pois não estamos validando isso. Mesmo se o fizéssemos, ainda haveria buracos na tipagem.

A verdadeira vantagem de record é a interoperabilidade com Java e seus elementos já existentes, o trabalho de forma orientada a objetos quando necessário e a agregação de definições. Passamos a deixar de ter somente os valores e o mapa, possuindo agora um Paciente que agrega as três coisas.

Para esta última solução, veremos outras abordagens e soluções para este cenário adiante.

Da maneira como escrevemos, nem sempre ficará claro o que é cada parâmetro. Então, outra forma de fabricar o construtor Paciente através de um mapa; mapeamos um Paciente onde falamos que :id é 15, :nome é "Guilherme" e :nascimento é "18/9/1981" entre chaves.

(defrecord Paciente [id nome nascimento])

(println (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (->Paciente 15 "Guilherme" "18/9/1981"))
(pprint (Paciente. 15 "Guilherme" "18/9/1981"))
(pprint (Paciente. "Guilherme" 15 "18/9/1981"))
(pprint (Paciente. 15 "18/9/1981" "Guilherme"))
(pprint (map->Paciente {:id 15, :nome "Guilherme", :nascimento "18/9/1981"}))

Literalmente, estamos passando para Paciente um mapa. Apesar de o resultado ser o mesmo no REPL, deixamos os elementos mais explícitos.

Ao invés do construtor em Java ser posicional, temos as chaves dizendo o que é cada campo em um mapa de Paciente. Se criamos um mapa, provavelmente podemos trabalhar com este recurso.

Na sequência, crie um laço let com guilherme sendo o Paciente, pegando a primeira linha para deixar claro que não precisa ser construção através de map.

Assim, podemos imprimir o :id do guilherme como se este fosse um mapa por exemplo. Agora usamos println com os vals de guilherme.

Note que a classe Paciente criada é imutável e possui três valores. Para ver se aceita mais algum elemento, copie e cole na sequência a linha que contém map que tentamos criar e tente inserir o :rg fictício "222222".

(let [guilherme (->Paciente 15 "Guilherme" "18/9/1981")]
    (println (:id guilherme))
    (println (vals guilherme)))

(pprint (map->Paciente {:id 15, :nome "Guilherme", :nascimento "18/9/1981", :rg "222222"}))

Ao rodar no REPL, o resultado expõe que permite aceitar mais elementos como um mapa. Agora, testamos para ver se permite elementos a menos sem :id. Copie e cole novamente a última linha, retirando :id 15 e rodando novamente. Permitida a exclusão do elemento, retorna o valor nulo para esta chave :id.

Através de um mapa, essa ação é permitida. Porém, devemos ver se é possível com os demais construtores posicionais, como o Paciente..

(let [guilherme (->Paciente 15 "Guilherme" "18/9/1981")]
    (println (:id guilherme))
    (println (vals guilherme)))

(pprint (map->Paciente {:id 15, :nome "Guilherme", :nascimento "18/9/1981", :rg "222222"}))
(pprint (Paciente. "Guilherme" "18/9/1981"))
(pprint (map->Paciente { :nome "Guilherme", :nascimento "18/9/1981", :rg "222222"}))

Visto que não é possível, o próprio editor já indica o erro em Paciente., pois a construção requer três parâmetros. Repare que o mapa nos possibilita ir por um caminho de coisas opcionais, e quando usamos o contrutor, orientação a objeto e demais questões de tipagem, vamos pelo caminho de obrigações.

São dois caminhos distintos com vantagens e desvantagens. Comente a linha (pprint (Paciente. "Guilherme" "18/9/1981")), copie-a e cole-a logo abaixo passando nil no lugar do id após Paciente..

Podemos pegar um Paciente. já criado e, lembrando de que se trata de um mapa, podemos utilizar assoc e inserir :id 38.

O resultado do assoc é um mapa, e em uma outra cópia da linha na sequência, imprima a class do segundo assoc para ver que a classe ainda é Paciente.

(let [guilherme (->Paciente 15 "Guilherme" "18/9/1981")]
    (println (:id guilherme))
    (println (vals guilherme)))

(pprint (map->Paciente {:id 15, :nome "Guilherme", :nascimento "18/9/1981", :rg "222222"}))
;(pprint (Paciente. "Guilherme" "18/9/1981"))
(pprint (Paciente. nil "Guilherme" "18/9/1981"))
(pprint (map->Paciente { :nome "Guilherme", :nascimento "18/9/1981", :rg "222222"}))

(pprint (asssoc (Paciente. nil "Guilherme" "18/9/1981") :id 38))
(pprint (class (asssoc (Paciente. nil "Guilherme" "18/9/1981") :id 38)))

Quando criamos a classe Paciente e adicionamos mais elementos com assoc, continua sendo Paciente. Recapitulando, a classe que criamos é em Java, imutável, expansível, seus campos na construção com construtor são posicionais e obrigatórios por poderem ser nulos, enquanto com mapa são opcionais e trabalha com os elementos que possui.

Logo, outra vantagem é, se é uma classe em Java, são campos de verdade em Java e podemos ter otimizações por não estarmos utilizando reflection por baixo dos panos e etc.

Se isso é uma grande vantagem de desempenho em seu sistema real, é outra questão a ser medida.

Há outros ganhos que uma classe nos traz; temos o paciente "Guilherme" e podemos conferir se este é igual com = do Clojure já implementado para este tipo ao imprimir e rodar, retornando true. Se mudarmos o id, o retorno é false.

(pprint (= (->Paciente 15 "Guilherme" "18/9/1981")(->Paciente 15 "Guilherme" "18/9/1981")))
(pprint (= (->Paciente 153 "Guilherme" "18/9/1981")(->Paciente 15 "Guilherme" "18/9/1981")))

Assim, já temos alguns ganhos.

Vimos como usar o :id, vals, class de guilherme, podemos perguntar se é uma classe de Java gerada através de defrecord com record? para imprimir o retorno true confirmando e como chamar os campos de Java por meio de .nome guilherme. Desta forma, temos o binding em tempo de compilação que costuma ser mais rápido do que chamar dinamicamente em tempo de execução, em teoria.

Portanto, há várias ações que podemos realizar uma vez que estamos trabalhando com esses elementos.

Já havíamos visto sobre interoperabilidade ao usar Thread/sleep para chamar um método estático de threading. Agora, realizamos outros trabalhos com Paciente através de defrecord, apresentando algumas vantagens ao trabalhar com Java em Clojure, ou quando queremos otimizar de alguma forma já citada, podendo ou não fazer sentido dentro do programa.

Ainda, usamos quando queremos algumas garantias de tipos que podem ou não fazer sentido também, afinal ainda pode-se criar um Paciente de valor nulo.

Como uma validação de esquema, ainda não resolveu nosso problema, o qual será deixado de lado pois a grande questão é a interoperabilidade com Java que nos permite trabalhar orientados a objeto quando fizer sentido no sistema.

Veremos mais casos a seguir.

Sobre o curso Clojure: Record, protocol e multi method

O curso Clojure: Record, protocol e multi method possui 126 minutos de vídeos, em um total de 29 atividades. Gostou? Conheça nossos outros cursos de Clojure em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Records, Java e OO
• Procols e polimorfismo
• Criando um componente OO na mão
• Defmulti e defmethod
• Multimethods