DEV Community: Gabriel Suaki

Java 15 se tornou GA!

Gabriel Suaki — Wed, 16 Sep 2020 16:04:43 +0000

15/09/20 - Java 15 se torna GA.

Além das preview features, conhecidas das versões anteriores (Text Blocks, Pattern Matching para instanceof e Records), foi introduzido no Java 15 os conceitos de sealed classes e Local interfaces & enums.

1. Getting Started

Para começar vamos instalar a JDK 15. Eu utilizo o sdkman para gerenciar todas as JDKs do meu workspace, mas se achar mais conveniente baixar direto da OpenJDK, este é o link.

Utilizando o sdkman, primeiro listamos as JDKs disponíveis:

sdk list java

Em seguida, basta executar o comando com o identifier encontrado:

sdk install java 15.ea.36-open

Pronto! A JDK está instalada e pronta para ser usada. Agora basta configurar o IntelliJ:

2. Sealed Classes & Interfaces (Preview)

Essa funcionalidade permite assumir o controle da hierarquia de classes e interfaces através da keyword sealed e permits. Vamos ao exemplo:

sealed public interface Shape permits Circle, Square, Rectangle, Diamond { }

No código acima, definimos a interface Shape e marcamos como sealed. Classes sealed demandam a declaração da keyword permits para dizer ao compilador quais as classes ou interfaces poderão estender ou implementar Shape. Existe uma exceção a regra somente para casos onde as implementações estão no mesmo arquivo que a sealed class. Quando isto ocorre, podemos omitir a keyword permits da declaração da sealed class.

Classes cuja classe pai é sealed demandam declarar sua abrangência de hierarquia entre: final, non-sealed ou sealed.

Normalmente, as classes filhas serão final para evitar que possam ser herdadas. Ao tentar herdar, observará um erro de compilação.

final class Square implements Shape { }

class TimesSquare extends Square { } // Compilador fica chateado, pois Square é final.

Também é possível substituir o uso da final class por record, pois são classes imutáveis e, por baixo dos panos, o compilador gera um final class.

record Square() implements Shape { }

As estruturas filhas declaradas como non-sealed expandem a hierarquia, possibilitando-as de serem estendidas ou implementadas por qualquer outra classe ou interface.

non-sealed interface Diamond extends Shape { }

non-sealed class Circle implements Shape { }

class BigCircle extends Circle { }

interface ColoredDiamond extends Diamond {}

Deve-se atentar que non-sealed classes podem quebrar a coesão de seus modelos, pois voltam a expor tudo o que tentou proteger com sealed.

Por último, e não menos importante, podemos ter sealed classes implementando sealed classes. Dessa forma, não deixamos tão aberto quanto as non-sealed e nem tão engessado quanto as final, continuamos restringindo a herança ou composição.

sealed class Rectangle implements Shape permits CustomRectangle { }

final class CustomRectangle extends Rectangle { }

2.1. Type-Test Pattern matching

Com o controle de hierarquia que as sealed classes proveem ao compilador, seria possível fazer type-test-pattern igual ao que vemos no when do Kotlin.

public Double getAreaOfShape(final Shape shape) {
    return switch (shape) {
        case Circle c -> circleArea(c);
        case Diamond d -> diamondArea(d);
        case Rectangle r -> rectangleArea(r);
        case Square s -> squareArea(s);
    };
}

Atualmente esse código acima não compila, pois type-test-pattern no switch-case não é uma funcionalidade ainda, é apenas uma possibilidade. A razão disso, é por conta do precedente que foi adicionado ao Java 14: Pattern Matching for instanceof.

Indo mais além, pelo fato do compilador saber exatamente quem implementa determinada sealed class, seria possível omitir o default no switch-case, pois todas as possibilidades foram declaradas.

3. Local interfaces e enums

Com a segunda preview de Records (JEP 384) assomado no Java 15, a possibilidade de criar estruturas no escopo local de um método virou realidade. Além das records, agora podemos declarar classes, enums e interfaces dentro do escopo de métodos também!

  public List<TV> getTop5ExpensiveTV(final List<TV> tvs) {

    enum Price {EXPENSIVE, CHEAP}

    record TVPrice(TV tv, Double amount) { 

      Price price() {
        return amount > 4_000 ? Price.EXPENSIVE : Price.CHEAP;
      }
    }

    return tvs.stream()
        .map(tv -> new TVPrice(tv, calculateAmount(tv)))
        .sorted(Comparator.comparing(TVPrice::price))
        .map(TVPrice::tv)
        .limit(5)
        .collect(Collectors.toList());
  }

O exemplo acima mostra uma forma de usufruir de estruturas locais. Foi utilizado local record e enum para fazer um filtro em uma lista.

5. What’s next?

Existem outras features de melhoria de performance e reimplementações de estruturas, não hesite em ler o release notes completo.

4. Referências

Programação Funcional em Java #2 - Descomplicando o Vavr

Gabriel Suaki — Thu, 10 Sep 2020 11:35:36 +0000

Descomplicando o Vavr

Se você está se perguntando "Qual a relação entre Programação Funcional e Vavr ?" não se preocupe, vou te explicar. A biblioteca Vavr é um superset de construções básicas que linguagens funcionais oferecem por padrão, com exceção do Java - o que dificulta a utilização do paradigma funcional no dia-a-dia.

A biblioteca conta com várias construções e aqui focaremos nas mais importantes: Functions, Monads, Collections e Pattern Matching.

1. Functions

Functions enriquece as funções de uma maneira jamais vista antes no Java. É considerado um dos pilares mais importantes, pois Programação Funcional é sobre valores e como manipulá-los através de funções. Esse módulo sobre funções é divido em cinco conceitos: Composition, Lifting, Partial application, Currying e Memoization.

1.1. Composition

Esse é o conceito mais simples (também encontramos nas interfaces do Java). É basicamente sobre compor as funções a fim de obter maior robustez e significância. Veja o exemplo:

final Function1<Integer, Integer> tributoIRRF = Function1.of(n -> n - 1000);

final Function1<Integer, Integer> contribuicaoINSS = Function1.of(n -> n - 100);

final Function1<Integer, Integer> calculaSalarioLiquido = tributoIRRF.andThen(contribuicaoINSS);

final Integer salarioLiquido = calculaSalarioLiquido.apply(2000); // Líquido de 900

Nesse exemplo acima definimos três funções. A primeira tributoIRRF recebe um inteiro e subtrai 1000. A segunda contribuicaoINSS também recebe um inteiro mas subtrai apenas 100. Na terceira função calculaSalarioLiquido não implementamos nenhuma lógica, ao invés disso foi feita uma composição entre as duas primeiras funções. Ao executar calculaSalarioLiquido seguimos a lógica em invocar tributoIRRF e, então, invocar contribuicaoINSS. Convertendo para funções matemáticas, podemos ler f(x): ((x - 1000) - 100).

Além do andThen, também é possível alterar a ordem da execução com o compose:

final Function1<Integer, Integer> calculaSalarioLiquido = tributoIRRF.compose(contribuicaoINSS);

final Integer salarioLiquido = calculaSalarioLiquido.apply(2000); // Líquido de 900

Dessa forma, o resultado obtido ainda é o mesmo, mas agora lê-se f(x): ((x - 100) - 1000) .

1.2. Lifting

Esse conceito consiste em envolver uma função que consideramos parcial gerando uma função total. Para entender melhor, veja este exemplo:

public Integer calculaImposto(final Integer tributoIRRF, final Integer contribuicaoINSS) {

  if (tributoIRRF < 0 || contribuicaoINSS < 0) {
    throw new IllegalArgumentException("Imposto não pode ser menor que 0");
  }

  return tributoIRRF + contribuicaoINSS;
}

Esse método calculaImposto retorna a soma entre os dois impostos da entrada, caso sejam maiores que 0, do contrário, lança uma exceção. O fato de lançar tal exceção o torna uma função parcial. Podemos tornar a mesma completa utilizando o Function2.lift.

Function2<Integer, Integer, Option<Integer>> calculadorDeImposto = 
  Function2.lift(this::calculaImposto);

Epa! Option, what!? Calma, por ora, o que você precisa saber é que este Option tem a semântica do Optional do Java e tem duas representações: None() quando é vazio e Some(n) quando há um valor.

Voltando ao exemplo, na nova função calculadorDeImposto, agora indicamos ao consumidor que a função pode ou não produzir um resultado. No caso, se o valor de um dos impostos for menor que zero e o método principal calculaImposto lançar uma exceção, o resultado da operação é None(). Por outro lado, caso os parâmetros estiverem OK, o resultado é Some(n).

1.3. Partial application

Partial application consiste em reduzir gradativamente a quantidade de parâmetros de uma função aplicando aqueles que estão disponíveis. É parecido com o conceito Currying, mas não se engane, pois eles são diferentes. Vamos ao exemplo:

Exemplo 1. Reduzindo parâmetros até o último

final Function3<Integer, Integer, Integer, Integer> calculaSalarioLiquido = 
  (salario, tributoIRRF, contribuicaoINSS) -> salario - (contribuicaoINSS + tributoIRRF);

final Function2<Integer, Integer, Integer> salarioBruto = calculaSalarioLiquido.apply(2000);

final Function1<Integer, Integer> salarioMenosIRRF = salarioBruto.apply(1000);

final Integer salarioLiquido = salarioMenosIRRF.apply(100);

Nesse exemplo 1, a função calculaSalarioLiquido é de aridade três, ou seja, demanda três parâmetros de entrada. Supondo que no momento da execução não temos todos os três valores, como proceder? Felizmente, o Vavr está preparado para receber os valores individualmente e ir reduzindo a aridade da função, exatamente como no exemplo 1.

Primeiramente aplicamos o valor do salário (2000) e a função calculaSalarioLiquido nos retornou uma nova função de aridade dois, a qual chamamos de salarioBruto. Em seguida, aplicamos o próximo valor (1000) referente ao tributoIRRF e o resultado foi uma nova função de aridade um, a qual chamamos de salarioMenosIRRF. Por fim, aplicamos o valor de 100 referente a contribuicaoINSS e obtivemos o resultado final que é o salário líquido no valor de 900.

O Vavr também possibilita fazer de outras formas. No próximo exemplo utilizamos os métodos reversed() e .apply(p1, p2) de aridade dois, veja:

Exemplo 2. Invertendo a ordem e aplicando dois parâmetros de uma só vez

final Function3<Integer, Integer, Integer, Integer> calculaSalarioLiquido =
  (salario, tributoIRRF, contribuicaoINSS) -> salario - (contribuicaoINSS + tributoIRRF);

final Function1<Integer, Integer> salarioMenosIRRFeINSS = calculaSalarioLiquido.reversed().apply(100, 1000);

final Integer salarioLiquido = salarioMenosIRRFeINSS.apply(100);

Nesse segundo cenário fizemos basicamente a inversão dos parâmetros de entrada para que pudéssemos aplicar os dois impostos de uma só vez e, então, gerar função salarioMenosIRRFeINSS cuja aridade caiu de três para um. Dessa forma, para o cálculo da aridade da função resultante utilizamos a fórmula: aridade original - parâmetros aplicados.

1.4. Currying

Currying é a técnica de quebrar a aridade de uma função em funções de aridade única. Ficou confuso? Vamos ao exemplo:

final Function3<Integer, Integer, Integer, Integer> calculaSalarioLiquido =
  (salario, tributoIRRF, contribuicaoINSS) -> salario - (contribuicaoINSS + tributoIRRF);

final Function1<Integer, Function1<Integer, Function1<Integer, Integer>>> calculoSeparado =
  calculaSalarioLiquido.curried();

Aqui, podemos ver nossa conhecida função, de aridade três e bastante complexa, calculaSalarioLiquido. Com o uso do .curried() possibilitamos desmembrá-la em três funções encadeadas de um único parâmetro.

Para invocar a função resultante de .curried(), faremos desta forma:

final Integer salarioLiquido = calculoSeparado.apply(2000).apply(1000).apply(100);

Resumindo, a diferença entre Currying e Partial application é que Currying quebra a função em funções de aridade única encadeadas, enquanto o Partial application é flexível, pois resulta sempre em uma função com o restante dos parâmetros não aplicados.

1.5. Memoization

Memoization consiste em cachear o resultado de uma função com base nos parâmetros.

final Function3<Integer, Integer, Integer, Integer> calculaSalarioLiquido =
  (salario, tributoIRRF, contribuicaoINSS) -> salario - (contribuicaoINSS + tributoIRRF);

final Function1<Integer, Integer> salarioMenosDescontos =
  calculaSalarioLiquido.reversed().apply(100, 1000).memoized();

final Integer salarioLiquido = salarioMenosDescontos.apply(2000); // Calcula e cacheia

final Integer salarioLiquido2 = salarioMenosDescontos.apply(2000); // Utiliza valor do cache

final Integer salarioLiquido3 = salarioMenosDescontos.apply(3000); // Calcula e cacheia

Supondo que calculaSalarioLiquido demande uma computação enorme e que os parâmetros tributoIRRF e contribuicaoINSS não se alterem com muita frequência, podemos aplicar os parâmetros de impostos e marcar a função resultante como .memoized(), assim, a nova função salarioMenosDescontos terá o comportamento de cachear o resultado em memória, sendo a chave o parâmetro de entrada. Ou seja, ao aplicar o valor 2000, toda computação é feita e ao final armazena-se o resultado. Se o valor for inputado novamente o cache estará populado, retornando o resultado computado previamente.

2.1. Monads

Monads são typeclasses que encapsulam um valor a um comportamento específico. Você conhece o java.util.Optional ? É um Monad. Ele encapsula um valor que pode, ou não, estar presente.

2.1. Option

Option é um container que representa um valor opcional. Por baixo dos panos, a interface Option tem duas implementações: Some(value) quando há valor dentro do Option e None() para quando não há.

Option<String> maybeName = Option.of("Gabriel"); // Some(string)

Option<String> maybeName = Option.of(null); // None()

Veja que, diferentemente do Optional, o factory method padrão do Option contém a inteligência de fazer a triagem do valor null, sem precisar de um outro método como Optional.ofNullable. Além disso, existe outra diferença muito importante no comportamento do .map que ,se você não se atentar, pode resultar em NPEs.

Exemplo 1. Optional padrão do Java

final Optional<String> name = Optional.of("gabriel") // (1)
  .map(value -> (String) null) // (2)
  .map(value -> value.toLowerCase()); // (3) Não acontece

assertFalse(name.isPresent());

Optional com valor interno "gabriel".
Optional se torna vazio pois null é retornado.
Não é invocado pois o Optional está vazio.

No exemplo acima, ao retornar null no primeiro .map, podemos observar que o comportamento é de desconsiderar os próximos .map, pois o valor interno tornou-se vazio. Caso prosseguisse para o próximo .map(value -> value.toLowerCase()) o resultado seria, inevitavelmete, NPE, já que value passou a ser null.

Exemplo 2. Option do *Vavr*

final Option<String> name = Option.of("gabriel") // (1)
  .map(value -> (String) null) // (1)
  .map(value -> value.toLowerCase()); // (3) throws NullPointerException

Option com valor interno Some("gabriel").
Option se torna Some(null).
.map é invocado com valor null e um NPE é lançado.

Simulando o mesmo cenário, mas com Option do Vavr, observamos que NullPointerException é lançado ao tentar invocar .toLowerCase em uma variável null. Isso acontece porque a semântica do .map do Vavr preserva o conceito matemático de que invocar .map em um Some resulta em outro Some, e invocar .map em um None resulta em outro None. No Optional do Java, o resultado null ao invocar o .map altera o contexto interno de Some para None.

Sabendo disso, o que fazer para voltar a estar seguro contra null ? É simples. Ao invés de .map, flatMap that shit!.

final Option<String> name = Option.of("gabriel")
  .flatMap(value -> Option.of((String) null))
  .map(value -> value.toLowerCase()); // we are safe

assertFalse(name.isPresent());

Para conhecer mais sobre o assunto, recomendo este post The agonizing death of an astronaut.

2.2. Try

Try é um container que representa uma execução que pode resultar em sucesso ou em uma exceção.

// Simples try com valor padrão em caso de erro.
Try.of(() -> calculaImpostos())
   .getOrElse(valorDefault);

// Exemplo um pouco mais avançado utilizando Try with resources para ler um InputStream
Try.withResources(() -> readFile())
   .of(stream -> IOUtils.toString(stream))
   .getOrElse("");

Em caso de erro, esse mônada fornece métodos utilitários que nos permite fazer tratamentos, tais como:

Try.of(this::calculaImposto)
   .recover(AException.class, t -> recoverFromA(t))
   .recover(BException.class, t -> recoverFromB(t))
   .recoverWith(CException.class, t -> Try.of(() -> recoverFromC(t)))

Ou, podemos utilizar Pattern Matching - conceito que veremos mais à frente - e unificar os .recover com rebuscado fancy switch-case funcional Match, fornecido pelo Vavr:

Try.of(this::calculaImposto)
   .recover(error -> Match(error).of(
     Case($(instanceOf(AException.class)), t -> recoverFromA(t)),
     Case($(instanceOf(BException.class)), t -> recoverFromB(t)),
     Case($(instanceOf(CException.class)), t -> recoverFromC(t)),
     Case($(), t -> recoverFromUnknown(t))
   ))
   .getOrElse(impostoPadrao);

No exemplo acima, fica notável como Vavr nos permite desenvolver códigos funcionais e expressivos. Além dos métodos exemplificados, Try conta com hooks como .onFailure, .onSuccess, .andFinally, .andThen, entre outros.

2.3. Lazy

Lazy é um container que representa um valor que não precisa ser computado no momento em que é criado, apenas quando solicitado. Diferentemente do Supplier, cuja semântica é parecida, no Lazy o resultado é cacheado ao ser evaluado.

final Lazy<UUID> id = Lazy.of(UUID::randomUUID); // (1)
id.isEvaluated(); // (2)

final UUID newID = id.get(); // (3)
id.isEvaluated(); // (4)

final UUID cachedID = id.get(); // (5)
assertEquals(newID, cachedID);

Cria-se instância do Lazy a partir de um supplier de UUID.
isEvaluated é false por não ter sido invocado o .get.
Invoca-se o .get que invoca o supplier UUID.randomUUID gerando o UUID aleatório.
isEvaluated passa a ser true.
Invoca-se o .get e retorna o UUID cacheado do passo 3.

Outra funcionalidade muito interessante é o suporte a interfaces, onde a instância da implementação é feita via Proxy na primeira chamada de qualquer método da interface. Não entendeu ? Vamos ao exemplo:

final CalculadoraImposto inss = Lazy.val(CalculadoraINSS::new, CalculadoraImposto.class);
inss.calcular(); // (1)
inss.calcular(); // (2)

public interface CalculadoraImposto {
  Integer calcular();
}

public class CalculadoraINSS implements CalculadoraImposto {
  public CalculadoraINSS() {
    System.out.println("Instanciando calculadora INSS");
    // Computação custosa e demorada
  }

  @Override
  public Integer calcula() {
      return 1000;
  }
}

Invoca-se o método calcular, o qual passa pelo proxy e invoca o supplier CalculadoraINSS::new, cacheando o resultado e depois invocando o método.
Invoca-se o método calcular, o qual também passa pelo proxy, mas desta vez, o resultado do supplier está cacheado e não passa pelo CalculadoraINSS::new, indo direto ao método.

Nesse exemplo, temos a interface CalculadoraImposto e a implementação CalculadoraINSS. Supondo que instanciar CalculadoraINSS demande muito poder computacional e tempo, obviamente não gostaríamos de instanciar sem realmente precisar. Utilizando factory method Lazy.val, passamos como primeiro parâmetro o Supplier, responsável por construir o objeto, e como segundo parâmetro o .class da interface, a qual a implementação pertence (CalculadoraImposto). Repare que o retorno do Lazy.val é a própria interface e não Lazy<CalculadoraImposto>, como no exemplo anterior com Lazy.of. O truque aqui é que o Vavr cria um Proxy dinâmico da interface envolvendo o Supplier em um Lazy. Quando qualquer invocação é feita, nos métodos da interface, primeiro passa-se pelo Proxy que invoca o Lazy.get e depois invoca-se a implementação real do método, caso necessário. Como vimos acima, Lazy.get faz cache do resultado, ou seja, só invocamos o construtor CalculadoraINSS uma vez e a instância fica em memória para ser reutilizada.

2.4. Either

Either é um container que representa um valor que pode se apresentar de duas maneiras diferentes. Por debaixo dos panos, a interface Either tem duas implementações: Left() e Right() .
Este mônada é bastante utilizada para representar um valor que deu certo (right) ou que falhou (left). Imagino que você esteja se perguntando "qual a diferença entre Either e Try" ? Bom, assim como o Either, a semântica do Try também representa um valor que pode ser um sucesso ou um erro. A grosso modo, é possível visualizar o Try sendo um Either<Throwable, R>, todavia, seu contexto é inteiro voltado para isso e apenas isso. Por outro lado, o Either é flexível e não representa, necessariamente, sucesso ou falha.

final Either<String, Integer> impostoINSS = calculaINSS();

final Integer inss = impostoINSS
  .map(imposto -> salario - imposto) // (1)
  .getOrElseThrow(left -> handleError(left)); // (2)

.map só será executado caso o Either seja Right, ou seja, sucesso.
Caso seja Left, lidamos com erro invocando handleError.

No exemplo acima, Either foi utilizado para indicar cálculo do INSS com sucesso (right) ou falha (left). calculaINSS poderia retornar Try ao invés de Either ? Sim, mas repare que a assinatura é Either<String, Integer>, se fosse Try lidaríamos com Throwable ao invés de String, o que pode fazer toda diferença para o contexto da aplicação e a maneira como lidamos com a falha.
Existem outras formas de trabalhar com o Either, conheça o .fold:

final Integer inss = impostoINSS.fold(
  left -> 1000, // (1) 
  imposto -> salario - imposto // (2)
);

Ignora-se a mensagem de erro left e retorna o valor padrão 1000. Poderíamos obter o mesmo resultado alterando a implementação do leftMapper por left -> { throw handleError(left); }.
Mantém o mesmo comportamento que o exemplo anterior para caso de sucesso.

Diferentemente do .map e .getOrElseThrow encadeados, o .fold recebe ambos os mappers (leftMapper e rightMapper) e utiliza um deles dependendo de seu estado interno (left ou right).

3 Collections

As coleções do Vavr são uma evolução das que encontramos no Java. Todas são imutáveis e cada tentativa de mutação gera uma nova lista, ou seja, são estruturas persistentes.

Exemplo 1. java.util.List vs io.vavr.collection.List

// Java 8
final java.util.List<Integer> list = Arrays.asList(1, 2, 3);
list.add(4);
list.add(5);
list.add(0, 9);
list.set(1, 6);

list
  .stream()
  .max(Integer::compareTo)
  .ifPresent(System.out::print);

// Vavr - io.vavr.collection.List
List.of(1, 2, 3) // List(1, 2, 3) 
    .append(4) // List(1, 2, 3, 4)
    .append(5) // List(1, 2, 3, 4, 5)
    .insert(0, 9) // List(9, 1, 2, 3, 4, 5)
    .pop()
    .update(1, 6) // List(9, 6, 2, 3, 4, 5)
    .max() // Option(9)
    .peek(System.out::print); // 9

Parece complexo, mas na verdade é bem simples. No exemplo acima, ambas collections iniciam-se com valores de 1, 2 e 3. Em seguida, adicionam-se os inteiros 4 e 5. Depois disso, insere-se o número 9 como primeiro elemento da lista e atualiza-se o valor do elemento de índice 1 para 6. Na próxima etapa devemos ir à procura do maior valor da lista e imprimir no console.

Podemos observar que a lista do Vavr é bem mais simples de se manipular. Cada manipulação gera uma nova lista e não corremos o risco de algum side-effect indesejado.

Exemplo 2. io.vavr.collection.HashMap

final HashSet<String> setOfNames = HashSet.of("Gabriel", "Joao", "Caio", "Pedro", "Fernando");

final Map<String, Integer> nameWithSize = setOfNames.toMap(Function.identity(), String::length);

nameWithSize.filterValues(size -> size > 4)
            .computeIfAbsent("Priscila", String::length)
            ._2()
            .computeIfPresent("Gabriel", (name, size) -> name.length())
            ._2()
            .maxBy(entry -> entry._2())
            .peek(System.out::println);

Todas as coleções são otimizadas no quesito Time Complexity, para saber mais: Performance Characteristics.

4. Pattern Matching

Finalmente chegamos na parte mais poderosa do Vavr - e aquela que eu mais utilizo!

Pattern Matching é a habilidade de comparar um valor aos padrões estipulados. Caso surja algum match, aplica-se a função correspondente ao valor. Na prática é um hiper switch-case, veja o exemplo:

import static io.vavr.API.*;
// io.vavr.API.Match, io.vavr.API.Case e io.vavr.API.$
final String value = "Gabriel";
final Number number = Match(value).of(
  Case($("gab"), name -> 3),
  Case($(isNull()), name -> 0),
  Case($(isIn("Monica", "Cebolinha", "Joao")), name -> 0),
  Case($(instanceOf(CharSequence.class)), name -> name.length()),
  Case($(name -> name.length() > 10), name -> -1),
  Case($(), name -> -1)
);

O exemplo acima é bastante simples, mas exibe as possibilidades que Pattern Matching nos dá. A estrutura apresenta-se como:

Match(valor) entrando com valor que será comparado aos padrões.
Case(padrão, função) definindo o padrão que será comparado e, se servir, a função na qual será aplicado o valor.

Os possíveis padrões, dentro do Case, podem ser:

$() - Padrão genérico/default
$(value) - Padrão equals
$(predicate) - Padrão condicional

Caso não queira usar o padrão genérico $(), é necessário utilizar o Match().option ao invés de Match().of e tratar manualmente.

final Option<Number> plusOne = Match(number).option(
  Case($(instanceOf(Integer.class)), i -> i + 1),
  Case($(instanceOf(Double.class)), d -> d + 1)
);

5. What’s next?

A biblioteca Vavr ainda tem muito mais a ser explorada, não hesite em ler a documentação completa.

6. Referências

Programação Funcional em Java #1 - Fundamentos básicos do paradigma

Gabriel Suaki — Tue, 01 Sep 2020 19:15:07 +0000

Fundamentos básicos do paradigma + Estrutura de dados

1. Fundamente-se

É comum ouvir palpites em Pull Requests como: "ei, você pode refatorar esse código usando programação funcional. Use filter, map ou reduce". Mas será que programação funcional é sobre isso? Bom, já adianto que não. O que define o paradigma funcional são suas características: Comportamento reproduzível (Referencial transparency), funções puras (The absence of side-effects) e valores imutáveis (Immutability).

1.1. Referencial transparency

Referencial transparency refere-se a substituição de uma função pelo seu valor. No código abaixo, ao substituir a função sum pelo valor da soma, não há alteração no comportamento da aplicação, independente de quantas vezes é invocada.

final int dez = 10;
final int result = Math.sum(7, 3);
assertEquals(dez, result); // NAIL IT

// outro exemplo com Strings
final String snaked = "Invoice_ID";
final String result = "Invoice ID".replace(" ", "_");
assertEquals(snaked, result); // NAIL IT

Já no código abaixo isso não ocorre. Não podemos prever o valor de result por ser randômico.

  final int cinco = 5;
  final int result = new Random().nextInt();
  assertEquals(cinco, result); // FAIL IT

1.2. Pure functions

Essa característica é dividida em dois aspectos:

O valor da função será sempre o mesmo para a mesma entrada. Não importa quantas vezes chamamos Math.sum(7, 3), o resultado sempre será 10. Caso a entrada mude (Math.sum(10, 3)), o resultado muda também. É importante ressaltar que esse fator descarta qualquer tipo de apontamento externo ou referência mutável. Veja o exemplo abaixo:

private static Integer NINE = 9;

public Integer plusNine(final Integer n) {
  return n + NINE;
}

A função plusNine parece ser pura, tendo seu valor reproduzível. Entretanto, ela aponta para uma variável estática e mutável externa à seu escopo, tornando-a impura.

Sua execução não possui side-effects. Comportamentos como apontar para uma variável estática, apontar para uma variável fora do escopo da função ou alterar algum estado interno (ou de um parâmetro) são qualificados como side-effects. Dito isto, fica claro que funções void possuem side-effects, do contrário, por que invocar uma função que não produz valor ?

1.3. Immutability

Imutabilidade é um conceito bastante conhecido porém pouco trabalhado, principalmente em linguaguem orientada a objetos. Essa característica implica em construir um objeto e não poder alterar o seu estado interno, ou seja, seu valor. No Java as classes mais utilizadas são imutáveis como, por exemplo: String, LocalDate, LocalDateTime, BigInteger, BigDecimal.

Exemplo 1. Strings

final String nome = "Gabriel";
final String nomeEmMinusculo = nome.toLowerCase();

assertEquals("Gabriel", nome); // NAIL IT
assertEquals("gabriel", nomeEmMinusculo); // NAIL IT

Exemplo 2. BigInteger

final BigInteger age = BigInteger.valueOf(15L);
final BigInteger agePlusFive = age.add(BigInteger.valueOf(5L));

assertEquals(15, age); // NAIL IT
assertEquals(20, agePlusFive); // NAIL IT

Em ambos exemplos o estado interno do objeto não se alterou, tanto BigInteger.add quanto String.toLowerCase
produzem o resultado esperado, porém em um novo objeto. Neste próximo exemplo, entretanto, o mesmo não se aplica:

Exemplo 3. ArrayList

final List<Integer> integers = Arrays.asList(1, 2);
final Integer size = integers.size();
integers.add(3);

assertEquals(size, 2); // FAIL IT

O método List.add produz um boolean, logo, fica evidente que altera o estado interno da lista para armazenar o novo inteiro, do contrário,List.add produziria uma nova lista. Podemos dizer então que há side-effect e ArrayList não é imutável.

2. Estrutura de dados

No paradigma Funcional não trabalhamos com classes que encapsulam comportamento e estado. Ao invés, trabalhamos com estrutura de dados as quais são divididas em três tipos: Estruturas mutáveis, estruturas imutáveis e estruturas persistêntes.

2.1. Estruturas mutáveis

É basicamente o que vimos no exemplo 3. A estrutura ArrayList do Java é mutável por padrão. Toda operação altera o estado interno da estrutura.

2.2. Estruturas imutáveis

Essas estruturas não se alteram pós construção e, no Java, as operações lançam erros. Veja o exemplo abaixo:

final List<Integer> integers = Collections.unmodifiableList(Arrays.asList(1, 2));
integers.add(3); // throws UnsupportedOperationException

O método unmodifiableList transforma uma lista mutável em uma nova lista imutável e, feito isso, toda tentativa de alterar o estado interno resulta no erro UnsupportedOperationException.

2.3. Estruturas persistentes

Nesse tipo de estrutura é possível operar em cima dela mesma. Todavia, o resultado da operação sempre retorna uma nova estrutura baseada na antiga, compartilhando os elementos para otimizar uso da memória. No Java não temos essas estruturas e é ai que entra o Vavr. Na biblioteca Vavr temos a estrutura que representa uma lista ligada conhecida como List.

final List<Integer> count = List.of(1, 2, 3);

Podemos visualizar a lista count como sendo:

O que acontece se manipularmos a lista substituindo o primeiro elemento por 0 ?

final List<Integer> newCount = count.tail().prepend(0);

A operação acima descarta o primeiro elemento "cabeça" newCount, retornando a "calda" .tail(), além de adicionar o elemento 0 como primeiro elemento .prepend(0). Por ser uma lista persistente, as operações resultam em uma nova lista chamada newCount, mantendo a anterior count intacta com mesmo valor (1, 2 e 3).

O truque aqui é gerar uma nova versão da lista primária, reutilizando os mesmos elementos para otimizar o uso de memória.

3. Conclusão sobre FP

Não pense que trabalhar com linguagens funcionais é estar 100% conforme as características. Existem momentos onde não da para escapar dos side-effects. Por exemplo, qualquer funcionalidade que faz I/O (log, stream, req/res, etc.) é um side-effect.

Estamos falando tanto em funções, fiquei curioso, você saberia me dizer qual a diferença entre um método e um função?
Bom, um método não existe por si só, ele precisa de uma classe para existir.
A função, por outro lado, pode viver sozinha, flutuando em um arquivo.

4. Próximos passos

Em breve trarei o segundo post da série: Programação Funcional em Java #2 - Descomplicando Vavr.

DEV Community: Gabriel Suaki

Java 15 se tornou GA!

1. Getting Started

2. Sealed Classes & Interfaces (Preview)

2.1. Type-Test Pattern matching

3. Local interfaces e enums

5. What’s next?

4. Referências

Programação Funcional em Java #2 - Descomplicando o Vavr

Descomplicando o Vavr

1. Functions

1.1. Composition

1.2. Lifting

1.3. Partial application

1.4. Currying

1.5. Memoization

2.1. Monads

2.1. Option

2.2. Try

2.3. Lazy

2.4. Either

3 Collections

4. Pattern Matching

5. What’s next?

6. Referências

Programação Funcional em Java #1 - Fundamentos básicos do paradigma

Fundamentos básicos do paradigma + Estrutura de dados

1. Fundamente-se

1.1. Referencial transparency

1.2. Pure functions

1.3. Immutability

2. Estrutura de dados

2.1. Estruturas mutáveis

2.2. Estruturas imutáveis

2.3. Estruturas persistentes

3. Conclusão sobre FP

4. Próximos passos

5. Referências