Conheça o conceito Mônada no Java

A Programa��o Funcional est� introduzindo conceitos novos para os desenvolvedores que trabalham com a Orienta��o a Objetos, como as m�nadas, programa��o declarativa, imutabilidade, higher-order functions, first-class function, transpar�ncia referencial, dentre outros. Nesse artigo abordaremos as m�nadas.

A Programa��o funcional, em linhas gerais, � um paradigma onde a computa��o � centrada nas transforma��es de dados atrav�s da aplica��o de fun��es. Neste modelo de computa��o, as fun��es s�o cidad�s de primeira classe e devem ser livres de efeitos colaterais (n�o produzir estados mut�veis).

J� a m�nada � um conceito oriundo da Teoria das Categorias, conforme podemos ver na Figura 1. Essa teoria � um ramo da matem�tica que tem muita influ�ncia na programa��o funcional.

A defini��o formal de m�nada, segundo a Teoria das Categorias � que ela � uma tripla (T,n,u), onde T � um endo-functor C => C e n e u s�o duas transforma��es naturais associadas a esse functor. n � uma transforma��o natural de 1[C] => T (1[C] � o functor identidade em C) e u � uma transforma��o natural TxT => T (TxT � o functor T o T) ... " (Ver Ref[1] � I/O Haskell)

Felizmente n�o precisamos entender matematicamente esse conceito para us�-lo no Java 8. Martin Odersky, criador da linguagem Scala, tem a seguinte defini��o: "M�nadas s�o tipos parametrizados com duas opera��es principais, flatMap e unit, e que seguem algumas leis alg�bricas". Ou seja, as m�nadas s�o cont�iner que encapsulam valores e/ou computa��es.

Para ficar mais claro vamos para um exemplo, onde teremos opera��es de soma entre n�meros e "n�o-n�meros", como a seguir:


double soma = "A" + 1 + 3.2 + Carro + 0.3 + laranja + "string" + "10"
double soma = 4.5

Como n�meros devemos considerar apenas 1, 3.2 e 0.3. E "10" � uma String, portanto um n�o-n�mero (valor 0), assim como Carro e laranja.

A codifica��o dessa opera��o est� na Listagem 1.


import java.util.Date;
 
public class Teste1 {
    
    public static double soma(Object obj1, Object obj2, Object obj3) {
        
        double valor = 0.0;
        
        if(obj1 instanceof Number) {
            valor += ((Number)obj1).doubleValue();
        }
        if(obj2 instanceof Number) {
            valor += ((Number)obj2).doubleValue();
        }
        if(obj3 instanceof Number) {
            valor += ((Number)obj3).doubleValue();
        }        
        
        return valor;
    }
    
    public static void main(String ...args) {
        
        double valor = soma("hello", 1.0, new Date());
        System.out.println("valor = " + valor);
    }    
}

Listagem 1. Somando N�meros e N�o-N�meros

Para a computa��o de n�meros e n�o-n�meros, podemos definir n�mero, nesse contexto, como sendo qualquer classe que estenda Number, e tudo que n�o estende ser� considerado como elemento neutro (0).

Ao analisar o c�digo da Listagem 1, � poss�vel aplicar uma refatora��o para eliminar a duplica��o de c�digo, como vemos na Listagem 2.


import java.util.Date;
 
public class Teste2 {
    
    private static double converte(Object obj) {
        return (obj instanceof Number) ? ((Number)obj).doubleValue() : 0.0;
    }
    
    public static double soma(Object obj1, Object obj2, Object obj3) {
        return converte(obj1) + converte(obj2) + converte(obj3);
    }
    
    public static void main(String ...args) {
        
        double valor = soma("hello", 1.0, new Date());
        System.out.println("valor = " + valor);
    }    
}

Listagem 2. C�digo refatorado da Listagem 1

Veja que, independentemente dos c�digos apresentados:

Lidamos com tipos num�ricos e "n�o-num�ricos";
Temos sempre um teste para validar o tipo(n�mero vs n�o n�mero);
N�o-n�meros s�o considerados elementos neutros (0).

No c�digo da Listagem 2 eliminamos a duplica��o de c�digo. Por�m, se fosse pedido para dois ou mais desenvolvedores criarem um m�todo que aceite tr�s argumentos Object e s� somassem os de tipo Number, provavelmente haveria l�gica em comum na solu��o deles, que s�o os conceitos mencionados anteriormente. � a chamada "duplica��o entre desenvolvedores" (Programador Pragm�tico), que fere o princ�pio DRY (Don't Repeat Yourself).

Qual seria a solu��o para evitar duplica��es de l�gica inadvertidas entre os desenvolvedores? Nesse caso, precisar�amos "conter" tanto os dados (num�ricos e n�o-num�ricos), como suas opera��es de teste e tipo, numa �nica representa��o e fazer os desenvolvedores usarem esse novo m�dulo. E isso nos lembra a defini��o de M�nada, que s�o cont�iner que encapsulam valores e/ou computa��es.

O c�digo de uma M�nada para esse problema pode ser visto na Listagem 3.


import java.util.Objects;
import java.util.function.Function;

public final class MaybeNumber<T> {

   private final T value;

   private static final MaybeNumber<?> EMPTY = new MaybeNumber<>();

 private MaybeNumber() {
     this.value = null;
 }

 private MaybeNumber(T value) {
     this.value = value;
 }
 
 public static <T> MaybeNumber<T> empty() {
     @SuppressWarnings("unchecked")
     MaybeNumber<T> t = (MaybeNumber<T>) EMPTY;
     return t;
 }

 public static <T> MaybeNumber<T> unit(T value) {
     if (value instanceof Number) {
         return new MaybeNumber<>(value);
     } else {
         return empty();
     }
 }

 public <R> MaybeNumber<R> flatMap(Function<T, MaybeNumber<R>> mapper) {
       if(value == null) {
           return empty();
       } else {
           return mapper.apply(this.value);
       }
   }

   @Override
   public int hashCode() {
       int hash = 7;
       hash = 43 * hash + Objects.hashCode(this.getValue());
       return hash;
   }

   @Override
   public boolean equals(Object obj) {
       if (obj == null) {
           return false;
       }
       if (getClass() != obj.getClass()) {
           return false;
       }
       final MaybeNumber<?> other = (MaybeNumber<?>) obj;
       return Objects.equals(this.getValue(), other.getValue());
   }
   
   public <R> MaybeNumber<R> map(Function<? super T, ? extends R> mapper) {
       if (value == null)
           return empty();
       else {
           return MaybeNumber.unit(mapper.apply(value));
       }
   }    
   
   public Double getValue() {
       return value == null ? 0.0 : ((Number)value).doubleValue();
   }
}

Listagem 3. M�nada MaybeNumber

Em linhas gerais, � como se os conceitos 1, 2 e 3 da quest�o dos n�meros e n�o-n�meros estivessem contidos numa �nica unidade computacional. Vejamos na Listagem 4 como fica o c�digo da Listagem 2 utilizando a m�nada MaybeNumber.


import java.util.Date;
 
public class Teste3 {
    
    public static double soma(MaybeNumber<Object> obj1, MaybeNumber
    <Object> obj2, MaybeNumber<Object> obj3) {
        return obj1.getValue() + obj2.getValue() + obj3.getValue();
    }
    
    public static void main(String ...args) {        
        double valor = soma(MaybeNumber.unit("hello"), MaybeNumber.unit(1.0),  
        MaybeNumber.unit(new Date()));
        System.out.println("valor = " + valor);
    }    
}

Listagem 4. Usando MaybeNumber

Encapsulamos os tr�s conceitos da classe MaybeNumber que vimos na Listagem 3 numa m�nada, eliminando uma poss�vel redund�ncia de l�gica (e c�digo) entre desenvolvedores. Assim, temos:

Temos que lidar com tipos num�ricos e "n�o-num�ricos":
Agora s� lidamos com um tipo: MaybeNumber;
Temos sempre um teste para validar o tipo:
MaybeNumber cuida disso;
N�o-n�meros s�o considerados elementos neutros (0):
MaybeNumber cuida disso.

Uma m�nada sempre tem duas opera��es fundamentais: unit e flatMap.

O m�todo unit "coloca" o dado (tanto num�rico como n�o-num�rico) dentro do cont�iner.

E a flatMap faz duas coisas:

Permite chamadas encadeadas, favorecendo um estilo de programa��o mais declarativo do que imperativo (veremos em breve um exemplo disso). Uma forma mais declarativa de expressar computa��es � um dos benef�cios das linguagens funcionais;
Permite recuperar o valor contido numa m�nada e aplicar uma transforma��o sem sair da m�nada.
Na Listagem 5 temos um exemplo do uso da flatMap.


public class Teste4 {
    
    public static MaybeNumber<Object> multiplicacao(Object value1, double value2) {
        return MaybeNumber.unit(MaybeNumber.unit(value1).getValue() * value2);
    }
    
    public static MaybeNumber<Object> divisao(Object value1, double value2) {
        return MaybeNumber.unit(MaybeNumber.unit(value1).getValue() / value2);
    }
    
    public static void main(String ...args) {        
        MaybeNumber<Double> obj1 = MaybeNumber.unit(10.0);        
        double valor1 = obj1.flatMap(x -> multiplicacao(x, 100)).flatMap(x -
        > divisao(x, 100)).getValue();
        System.out.println("Valor = " + valor1); // Igual a 10.0
        
        MaybeNumber<String> obj2 = MaybeNumber.unit("10.0");
        double valor2 = obj2.flatMap(x -> multiplicacao(x, 100)).flatMap(x -
        > divisao(x, 100)).getValue();
        System.out.println("Valor = " + valor2);  // Igual a 0, pois "10.0" � uma string (valor = 0)      
    }    
}

Listagem 5. Usando flatMap

Para calcular o valor1 e valor2 usamos encadeamento de chamadas usando flatMap e transforma��es (a partir de lambdas). Esse � o estilo funcional.

E quantos as leis alg�bricas, h� tr�s que uma m�nada deve seguir:

Identidade:
m flatMap unit = m // onde m = unit(x);
Unidade:
unit(x) flatMap f = f(x);
Associativa:
m flatMap f flatMap g = m flatMap (x -> f(x) flatMap g) // onde m = unit(x).

Vamos verificar se a classe MaybeNumber segue essas leis:

Lei da Identidade

Pela lei da Identidade -m flatMap unit = m // onde m = unit(x) - temos, em Java:


MaybeNumber<Integer> m = MaybeNumber.unit(10);        
// Lei da Identidade
m.flatMap(MaybeNumber::unit) == m

Repare nesse c�digo e no resto da demonstra��o, o sinal de igual == � usado matematicamente, e n�o para comparar refer�ncias.

Como a entrada � 10 (um n�mero v�lido), o retorno do flatMap pode ser traduzido para:


m.flapMap(MaybeNumber::unit) == mapper.apply(10)   // O c�digo do else do flapMap
mapper == MaybeNumber::unit  //  MaybeNumber::unit � o argumento da fun��o flatMap
mapper.apply(10) == MaybeNumber.unit(10)

Logo, provamos a identidade:


m.flatMap(MaybeNumber::unit) == m
MaybeNumber.unit(10) == MaybeNumber.unit(10)

Isso vale para qualquer entrada (inclusive n�o n�meros), e com isso verificamos a validade da primeira lei. Para o caso de n�o-n�meros, temos:


m.flatMap(MaybeNumber::unit) == m   // onde m = MaybeNumber.unit("x")
MaybeNumber.unit("x") == EMPTY        
m.flatMap(MaybeNumber::unit) == EMPTY  // o c�digo do if da fun��o flatMap
// Logo
MaybeNumber.unit("x") == m.flatMap(MaybeNumber::unit)

Listagem 1. NOME

Lei da Unidade

Veremos agora a Lei da Unidade - unit(x) flatMap f = f(x) - como a descrita em Java na Listagem 6.


import java.util.function.Function;
 
public class TestMaybeNumber {
    
    public static MaybeNumber<Integer> dobrar(Integer value1) {
        return MaybeNumber.unit(value1 * 2);
    }    
      
    public static void main(String ...args) {        
        MaybeNumber<Integer> m = MaybeNumber.unit(10);
        final Function<Integer, MaybeNumber<Integer>> f = TestMaybeNumber::dobrar;
        // Segunda Lei
        m.flatMap(f) == f(x);  //onde x = 10
    }    
}

Listagem 6. Lei da Unidade em Java

Como a entrada � um integer com valor 10, o retorno do flatMap pode ser traduzido para:


m.flatMap(f) == mapper.apply(x)
mapper == f
mapper.apply(10) == f.apply(10) 
f.apply(10) == f(10)

Logo:


m.flatMap(f) == f(x)
TestMaybeNumber.dobrar(10) == f(x) , onde x = 10
TestMaybeNumber.dobrar(10) == TestMaybeNumber.dobrar(10), 
onde x = 10

Com isso verificamos a validade da segunda lei para n�meros. Para os n�o-n�meros temos o c�digo da Listagem 7 provando a lei.


import java.util.function.Function;
 
public class TestMaybeNumber {
    
    public static MaybeNumber<Object> dobrar(Object value1) {
        return MaybeNumber.unit(MaybeNumber.unit(value1).getValue() * 2);
    }    
    
    public static void main(String ...args) {        
        MaybeNumber m = MaybeNumber.unit("10");
        final Function<Object, MaybeNumber<Object>> f = TestMaybeNumber::dobrar;        
        MaybeNumber m1 = m.flatMap(f);   // retorna EMTPY
        MaybeNumber m2 = f.apply("10");  // retorna MaybeNumber(0)
        System.out.println("equals == " + m1.equals(m2));  // true
    }    
}

Listagem 7. Provando a lei da Unidade para n�o-n�meros

Vejam que, para m.flatMap(f), retornamos EMPTY e para f.apply("10"), retornamos MaybeNumber.unit(0), que n�o � EMPTY. Isso n�o viola a segunda Lei?

Tecnicamente n�o, pois o que define se dois objetos s�o "id�nticos" em Java s�o os m�todos equals e hashCode. Para MayberNumber(0) e EMPTY, o m�todo equals � true (hashCode tamb�m).

Portanto, a Segunda Lei se aplica tamb�m para n�o n�meros.

Observe que a classe MaybeNumber poderia ser modificada, tornando o campo value sempre do tipo Double (e n�o parametrizado), sendo 0.0 para n�o n�meros e n para qualquer Number n. Essa classe foi desenvolvida assim apenas para explorarmos os conceitos de M�nada (e tamb�m porque � semelhante a implementa��o da classe Optional do Java 8).

Lei Associativa

Para a terceira lei, temos:


(m flatMap f) flatMap g = m flatMap (x -> f(x) flatMap g) // onde m = unit(x)

Que � traduzida em Java para de acordo com a Listagem 8.


import java.util.function.Function;
 
public class TesteLei3 {
    
    public static MaybeNumber<Integer> dobrar(Integer value1) {
        return MaybeNumber.unit(value1 * 2);
    }    
    
    public static MaybeNumber<Integer> dividir(Integer value1) {
        return MaybeNumber.unit(value1 / 5);
    }    
    
    public static void main(String[] args) {      
        
        MaybeNumber<Integer> m = MaybeNumber.unit(10);        
        
        final Function<Integer, MaybeNumber<Integer>> f = TesteLei3::dobrar;
        final Function<Integer, MaybeNumber<Integer>> g = TesteLei3::dividir;
 
        // A terceira Lei:                
        m.flatMap(x -> f.apply(x)).flatMap(y -> g.apply(y));    // Isso deve ser igual a linha abaixo
        m.flatMap(x -> (f.apply(x).flatMap(y -> g.apply(y)))); // Isso deve ser igual a linha acima
    }    
}

Listagem 8. Lei Associativa em Java

Para provar que a m�nada MaybeNumber segue essa lei, aplicamos a Segunda Lei (Lei da Unidade), conforme a Listagem 9.


import java.util.function.Function;
 
public class Lei3 {
    
    public static MaybeNumber<Integer> dobrar(Integer value1) {
        return MaybeNumber.unit(value1 * 2);
    }    
    
    public static MaybeNumber<Integer> dividir(Integer value1) {
        return MaybeNumber.unit(value1 / 5);
    }    
    
    public static void main(String[] args) {      
        
        MaybeNumber<Integer> m = MaybeNumber.unit(10);        
        
        final Function<Integer, MaybeNumber<Integer>> f = TesteLei3::dobrar;
        final Function<Integer, MaybeNumber<Integer>> g = TesteLei3::dividir;
        
        // Primeiro lado da comparacao
        m.flatMap(x -> f.apply(x)).flatMap(y -> g.apply(y));  
        // Aplicando a Segunda Lei        
        m.flatMap(x -> f.apply(x))  == f.apply(x) 
        // Temos(Lado 1):     
        f.apply(x).flatMap(y -> g.apply(y));  // x = 10
                        
        // Segundo lado da comparacao
        m.flatMap(x -> (f.apply(x).flatMap(y -> g.apply(y))));
        m.flatMap(x -> f''(x)), onde f''(x) == f.apply(x).flatMap(y -> g.apply(y))        
        // Aplicando a Segunda Lei   
        m.flatMap(x -> f''(x)) == f"(x)
        m.flatMap(x -> f''(x)) == f.apply(x).flatMap(y -> g.apply(y)) 
        // Temos(Lado 2):
        f.apply(x).flatMap(y -> g.apply(y));  // x = 10
    }    
}

Listagem 9. Provando a Lei Associativa

Logo, os dois lados chegaram a mesma equa��o:


f.apply(x).flatMap(y -> g.apply(y));  // x = 10

Para n�o-n�meros, basta pensar que a entrada � 0, visto que MaybeNumber.unit(0) e EMPTY s�o "iguais".

Essa lei nada mais � que: (x + y) + z = x + (y + z) -> Lei matem�tica da associa��o

Para testar a terceira lei, use o c�digo da Listagem 10, trocando o valor de b.


import java.util.function.Function;
 
/**
 *
 * @author marcelo
 */
public class TesteLei3 {
    
    public static MaybeNumber<Integer> dobrar(Integer value1) {
        return MaybeNumber.unit(value1 * 2);
    }    
    
    public static MaybeNumber<Integer> dividir(Integer value1) {
        return MaybeNumber.unit(value1 / 5);
    }    
    
    public static void main(String[] args) {      
        
        int b = -10;
        MaybeNumber<Integer> m = MaybeNumber.unit(b);        
        
        final Function<Integer, MaybeNumber<Integer>> f = TesteLei3::dobrar;
        final Function<Integer, MaybeNumber<Integer>> g = TesteLei3::dividir;
        
        // Primeiro lado da comparacao
        double value1 = m.flatMap(x -> f.apply(x)).flatMap(y -> g.apply(y)).getValue();
        // Segundo lado da comparacao
        double value2 = m.flatMap(x -> (f.apply(x).flatMap(y -> g.apply(y)))).getValue();
        
        System.out.println("value 1 = " + value1);
        System.out.println("value 2 = " + value2);
    }    
}

Listagem 10. Testando a Lei Associativa via c�digo

As leis mon�dicas tem maiores efeitos pr�ticos na linguagem Scala. Por exemplo, uma m�nada que satisfa�a essas leis pode ser usada com o "for-expression":


for {
  a <- List("a")
  b <- List("b")
  c <- List("c")
} yield (a, b, c)

Esse c�digo Scala seria equivalente a escrever:


List("a").flatMap(a => List("b").flatMap(b => List("c").map(c => (a, b, c))))

Notem que o c�digo com o "for-expression"tem um aspecto muito mais limpo que o encadeamento de flatMap's e map (repare que um List em Scala � uma m�nada).

A linguagem Scala possui diversas m�nadas relevantes: Option, Try, Future, List, Set, Either, etc.

Apesar da classe MaybeNumber ser �til para explorar alguns conceitos sobre M�nadas, veremos a seguir um exemplo mais pr�tico e que pode ser usado no dia a dia.

A amea�a do NullPointerException

Bem, se o pr�prio criador da refer�ncia nula, Tony Hoare, disse que esse conceito foi um erro, como ent�o nos protegermos desse flagelo?

Vejamos um exemplo t�pico na Listagem 11.


import java.util.Random;
 
public class Empresa {
    
    static class Endereco {
        private Cidade cidade;
        public void setCidade(Cidade cidade) { this.cidade = cidade; }
        public Cidade getCidade() { return this.cidade; }
    }
 
    static class Cidade {
        private String nome;
        public void setNome(String nome) { this.nome = nome; }
        public String getNome() { return this.nome; }        
    }
    
    private Endereco endereco;
    
    public void setEndereco(Endereco endereco) { this.endereco = endereco; }
    public Endereco getEndereco() { return this.endereco; }
    
    // Cria objeto ou nao, depende da sorte
    private static Object createRandom(Class clazz) throws InstantiationException, IllegalAccessException {
        if(new Random().nextInt(2) == 1) {
            return clazz.newInstance();
        } else {
            return null;
        }
    }
    
    public static void main(String ... args) throws InstantiationException, IllegalAccessException {
        Empresa empresa = (Empresa)createRandom(Empresa.class);
        Endereco endereco =  (Endereco)createRandom(Endereco.class);
        Cidade cidade =  (Cidade)createRandom(Cidade.class);
        
        // Atribuicoes        
        if(empresa != null) {
            empresa.setEndereco(endereco);
        }
        if(endereco != null) {
            endereco.setCidade(cidade);
        }        
        if(cidade != null) {
            cidade.setNome("Sao Paulo");
        }
        
        // Leituras
        if(empresa != null) {
            Endereco endereco1 = empresa.getEndereco();
            if(endereco1 != null) {
                Cidade cidade1 = endereco1.getCidade();
                if(cidade1 != null) {
                    System.out.println(cidade1.getNome());
                }
            }
        }        
    }
}

Listagem 11. C�digo "seguro"

Observem a quantidade de testes que temos que realizar para garantir a seguran�a em rela��o ao null. Sim, todo m�todo que n�o retorna uma primitiva, devolve sempre duas op��es: um objeto ou null (null pode ser considerado um n�o-objeto).

Esse conceito de Objeto e n�o-objeto nos lembra a quest�o do num�rico e n�o-num�rico, certo?

Um null deveria ser considerado como os n�o-num�ricos (valor 0) nos exemplos anteriores que vimos. Garantimos isso com os testes de if (igual aos testes de if com instanceof que fora feito na classe MaybeNumber).

Ent�o temos tr�s conceitos:

Objetos e n�o-objetos;
Testes para validar objetos e n�o-objetos;
null deveria ser como o elemento nulo, assim como no conceito matem�tico, que n�o tem efeitos colaterais.

Podemos encapsular esse conceito numa m�nada, assim como os projetistas da linguagem Java fizeram na vers�o 8, criando assim a classe Optional, como vemos na Listagem 12.


package java.util;
 
import java.util.function.Consumer;
import java.util.function.Function;
import java.util.function.Predicate;
import java.util.function.Supplier;
 
public final class Optional<T> {
 
    private static final Optional<?> EMPTY = new Optional<>();
 
    private final T value;
 
    private Optional() {
        this.value = null;
    }
 
    public static<T> Optional<T> empty() {
        @SuppressWarnings("unchecked")
        Optional<T> t = (Optional<T>) EMPTY;
        return t;
    }
 
    private Optional(T value) {
        this.value = Objects.requireNonNull(value);
    }
 
    public static <T> Optional<T> of(T value) {
        return new Optional<>(value);
    }
 
    public static <T> Optional<T> ofNullable(T value) {
        return value == null ? empty() : of(value);
    }
 
    public T get() {
        if (value == null) {
            throw new NoSuchElementException("No value present");
        }
        return value;
    }
 
    public boolean isPresent() {
        return value != null;
    }
 
    public void ifPresent(Consumer<? super T> consumer) {
        if (value != null)
            consumer.accept(value);
    }
 
    public Optional<T> filter(Predicate<? super T> predicate) {
        Objects.requireNonNull(predicate);
        if (!isPresent())
            return this;
        else
            return predicate.test(value) ? this : empty();
    }
 
    public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Optional.ofNullable(mapper.apply(value));
        }
    }
 
    public<U> Optional<U> flatMap(Function<? super T, Optional
    <U>> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Objects.requireNonNull(mapper.apply(value));
        }
    }
 
    public T orElse(T other) {
        return value != null ? value : other;
    }
 
    public T orElseGet(Supplier<? extends T> other) {
        return value != null ? value : other.get();
    }
 
    public <X extends Throwable> T orElseThrow(Supplier<? extends X> 
    exceptionSupplier) throws X {
        if (value != null) {
            return value;
        } else {
            throw exceptionSupplier.get();
        }
    }
 
    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
 
        if (!(obj instanceof Optional)) {
            return false;
        }
 
        Optional<?> other = (Optional<?>) obj;
        return Objects.equals(value, other.value);
    }
 
    @Override
    public int hashCode() {
        return Objects.hashCode(value);
    }
 
    @Override
    public String toString() {
        return value != null
            ? String.format("Optional[%s]", value)
            : "Optional.empty";
    }
}

Listagem 12. C�digo fonte da classe Optional(API do Java 8)

O m�todo unit na classe Optional est� representado em dois m�todos: m�todo of e m�todo ofNullable.

E flatMap est� l� e para provar vamos refatorar o c�digo da Listagem 9, aplicando essa m�nada.


import java.util.Optional;
import java.util.Random;
 
public class Empresa {
 
    static class Endereco {
 
        private Optional<Cidade> cidade;
 
        public void setCidade(Optional<Cidade> cidade) {
            this.cidade = cidade;
        }
 
        public Optional<Cidade> getCidade() {
            return this.cidade;
        }
    }
 
    static class Cidade {
 
        private String nome;
 
        public void setNome(String nome) {
            this.nome = nome;
        }
 
        public String getNome() {
            return this.nome;
        }
    }
 
    private Optional<Endereco> endereco;
 
    public void setEndereco(Optional<Endereco> endereco) {
        this.endereco = endereco;
    }
 
    public Optional<Endereco> getEndereco() {
        return this.endereco;
    }
 
    private static Object createRandom(Class clazz) throws InstantiationException, 
    IllegalAccessException {
        if (new Random().nextInt(2) == 1) {
            return clazz.newInstance();
        } else {
            return null;
        }
    }
 
    public static void main(String... args) throws InstantiationException, 
    IllegalAccessException {
        Optional<Empresa> empresa = Optional.ofNullable((Empresa) 
        createRandom(Empresa.class));
        Optional<Endereco> endereco = Optional.ofNullable((Endereco) 
        createRandom(Endereco.class));
        Optional<Cidade> cidade = Optional.ofNullable((Cidade) 
        createRandom(Cidade.class));
 
        // Atribuicoes        
        if (empresa.isPresent()) {
            empresa.get().setEndereco(endereco);
        }
        if (endereco.isPresent()) {
            endereco.get().setCidade(cidade);
        }
        if (cidade.isPresent()) {
            cidade.get().setNome("Sao Paulo");
        }
 
        // Leitura
        empresa.flatMap(empr -> empr.getEndereco())
               .flatMap(end -> end.getCidade())
               .ifPresent(cid -> System.out.println(cid.getNome()));
      }
}

Listagem 13. Usando a M�nada Optional

O c�digo da Listagem 13 � o mesmo da Listagem 11, mas aplicando a classe Optional.

Vamos comparar a primeira parte das atribui��es: perceba que n�o mudou muito em rela��o a quantidade de c�digo fonte escrito, certo? Observe a Listagem 14.


Empresa empresa = (Empresa)createRandom(Empresa.class);
Endereco endereco =  (Endereco)createRandom(Endereco.class);
Cidade cidade =  (Cidade)createRandom(Cidade.class);

// Atribuicoes        
if(empresa != null) {
    empresa.setEndereco(endereco);
}
if(endereco != null) {
    endereco.setCidade(cidade);
}        
if(cidade != null) {
    cidade.setNome("Sao Paulo");
}

.....................

Optional<Empresa> empresa = Optional.ofNullable((Empresa) createRandom(Empresa.class));
Optional<Endereco> endereco = Optional.ofNullable((Endereco) createRandom(Endereco.class));
Optional<Cidade> cidade = Optional.ofNullable((Cidade) createRandom(Cidade.class));

// Atribuicoes        
if (empresa.isPresent()) {
    empresa.get().setEndereco(endereco);
}
if (endereco.isPresent()) {
    endereco.get().setCidade(cidade);
}
if (cidade.isPresent()) {
    cidade.get().setNome("Sao Paulo");
}

Listagem 14. Comparando a se��o atribui��o

Veja que estamos comparando as se��es de atribui��o dos c�digos da Listagens 11 e 13. E sim, a priori, nada mudou. Por�m, h� algo muito importante: no c�digo que usa Optional, para acessar a entidade (empresa, cidade, endere�o) de verdade, n�s precisamos "tir�-la" do cont�iner, e para isso usamos o m�todo get.

Por�m, o get s� funciona se houver um valor n�o-nulo dentro do cont�iner. Caso contr�rio, ele lan�a uma exce��o. No artigo "Programa��o Restritiva"explorou-se o fato de se fazer o compilador trabalhar a favor do programador. E � isso que acontece aqui. Se o programador quer extrair o dado real do cont�iner, ele precisa testar antes (usando isPresent()).

No c�digo sem Optional, o programador pode lembrar ou n�o fazer o teste, dependendo da vontade dele (e sem a ajuda do compilador). Se ele esquecer, NullPointerException...


// Leituras
if(empresa != null) {
Endereco endereco1 = empresa.getEndereco();
if(endereco1 != null) {
    Cidade cidade1 = endereco1.getCidade();
    if(cidade1 != null) {
        System.out.println(cidade1.getNome());
    }
}
}        

.......

// Leituras
empresa.flatMap(empr -> empr.getEndereco())
   .flatMap(end -> end.getCidade())
   .ifPresent(cid -> System.out.println(cid.getNome()));

Listagem 15. Comparando a se��o leitura (imperativo x declarativo)

Na Listagem 15 temos um dos motivos de se usar a m�nada Optional: encadeamento seguro de m�todos (sem NullPointerException).

O c�digo com ifs � imperativo:

"Se empresa for diferente de null, fa�a isso:

Se endereco1 for diferente de null fa�a aquilo..."

Na programa��o imperativa definimos, passo a passo, tudo o que o programa deve fazer. Na programa��o funcional adotamos um estilo mais declarativo, baseado em transforma��es (aplicadas por fun��es) e composi��o de m�todos (principalmente com map, flatMap, filter, reduce, etc).

M�nada � um padr�o de projeto em linguagens funcionais e seus maiores benef�cios s�o:

Ocultar complexidade;
Reduzir duplica��o de l�gica e c�digo;
Encapsular conceitos e computa��o;
Permitir encadeamento/composi��o.

Lembre-se que Optional n�o estende Serializable. Por isso, ao inv�s de sair convertendo os atributos da sua entidade para Optional, uma solu��o interessante seria fornecer um m�todo utilit�rio, como veremos na Listagem 16, retirado do livro Java 8 in Action.


public class Empresa {
    private Endereco endereco;
    // M�todo utilit�rio
    public Optional<Endereco> getEnderecoOptional() {
      return Optional.ofNullable(endereco);
    }
}

Listagem 16. M�todo utilit�rio

Em Java 8, temos outras m�nadas: Stream e CompletableFuture.

Por esse conceito ter sido introduzido no Java 8 (gra�as ao suporte aos Lambdas), � claro que a API do Java, por exemplo, n�o usa Optional em larga escala para minimizar o risco de NullPointerException. E a linguagem Java ainda n�o t�m suporte para algo parecido com o "for expression" ou o poderoso mecanismo de pattern matching do Scala, que favorece uma escrita ainda mais compacta e declarativa do c�digo ao se trabalhar com m�nadas.

Por�m, � o primeiro passo do Java, com a vers�o 8, para apresentar aos programadores OO alguns dos conceitos e pr�ticas das linguagens funcionais. Os novos recursos do Java 8 s�o uma novidade interessante para os programadores acostumados apenas ao paradigma corrente, e que agora podem adotar um estilo mais declarativo e/ou usando lambdas para reduzir a verbosidade da linguagem (comparada com linguagens funcionais como Scala e Haskell).

M�nada � um conceito poderoso de abstra��o em linguagens funcionais, e muito ainda poderia ser falado sobre isso. O intuito desse artigo foi apenas dar uma luz inicial sobre o tema.

Refer�ncias:

Teoria M�nada, por I/O Haskell
Monadic Java
Livro � Java 8 in Action
Whats Wrong in Java 8
Prova das 3 Leis Mon�dicas para Optional

Tecnologias:

Confira outros conte�dos:

Introdu��o ao JDBC

Novidades do Java

Teste unit�rio com JUnit

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Marcelo Em 2015

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso

Conhe�a o conceito M�nada no Java

Veremos nesse artigo o conceito de M�nada e como aplic�-lo no Java 8.