DEV Community: Carolina Dias Fonseca

Boas práticas ao usar Lambda e classe anônima em Java

Carolina Dias Fonseca — Thu, 24 Feb 2022 18:58:54 +0000

Já faz algum tempo que venho falando sobre classes locais, classes anônimas e expressões lambdas. O que são, como usar e quando usar. No atual post vou escrever sobre boas práticas ao usar lambda em Java.

Devo usar tudo o que a linguagem tem?

Acho relevante colocar aqui que apesar do Java ter muitos recursos que podem e realmente ajudam no dia a dia de uma pessoa desenvolvedora, não quer dizer exatamente que esses recursos ajudem a manter um controle e facilidade de leitura/alteração no momento da manutenção do código.

Portanto, quando falamos em “boas práticas” é focado no momento em que a aplicação foi para produção e, dali pra frente, teremos as manutenções, revisões, novas releases e etc. Do meu ponto de vista, sempre temos que pensar que a manutenção não necessariamente será realizada por outra pessoa, mas sim que pode ser qualquer pessoa, incluindo quem criou a aplicação, portanto, é importante pensarmos:

Qual a melhor forma de deixar esse código simples não só para alterações, mas de leitura e entendimento futuro?

Claro que não podemos da performance, segurança, arquitetura e etc, mas sempre mantendo em mente a questão de carga cognitiva de compreensão do código. Afinal, ninguém quer passar uma semana só para tentar entender o que se passa diante dos seus olhos ali na IDE ou então ficar debugando linha a linha para tentar entender o que aquele trecho de código faz ou deixa de fazer.

Vai por mim, já tive que fazer isso porque dei de cara com uma aplicação sem o mínimo de documentação e muito menos com código legível e compreensível. Só para dar uma noção, conseguimos achar um dos responsáveis pela a aplicação e nem ele sabia explicar o que ele e/ou o time tinham feito, então... acho que deu para entender, né?

E como faz?

Pensando nisso, tenho lido muito sobre design pattern (ou, em português, padrões de projeto) tanto da Gang of Four - GoF (ou, em português, Gangue dos Quatro), como o SOLID e, o mais recente nas minhas leituras, o Effective Java (Java Efetivo) do Joshua Bloch.

Esse último, até onde encontrei, está em sua 3ª edição e fala das melhores práticas em Java, usando o Java 9. Questionei no Twitter sobre a relação versão atual do Java (estamos na 18) versus a edição desse livro e a galera mais sênior em relação a mim, super recomendaram a leitura e adicionaram que, para o universo Java, é um dos livros que mais ajudam a entender como otimizar o código, simplificá-lo, além de dar uma visão mais ampla do próprio Java.

Dessa forma, o que Bloch fala sobre Lambdas é, basicamente o seguinte:

Use expressão lambda ao inveś de classe anônima

Agora vamos ao porquê: Classe anônima é mais verbosa, ao passo que a expressão lambda é semelhante a função dentro da classe anônima, porém bem mais concisa.

Veja abaixo:

//Exemplo usando classe anônima
1 Collections.sort(palavras, new Comparator<String>() {
2    public int compare(String palavra1, String palavra2) {
3        return Integer.compare(palavra1.length(), palavra2.length());
4    }
5 });

//Exemplo usando expressão lambda
6 Collections.sort(palavras,
7 (palavra1, palavra2) -> Integer.compare(palavra1.length(), palavra2.length()));

Na expressão lambda e em grande maioria das vezes, o compilador será capaz de deduzir os tipos especificados na linha 2 da classe anônima por um processo chamado por inteferência de tipo, portanto, podemos reduzir ainda mais o exemplo de expressão lambda:

//Exemplo usando classe anônima
1 Collections.sort(palavras, new Comparator<String>() {
2    public int compare(String palavra1, String palavra2) {
3        return Integer.compare(palavra1.length(), palavra2.length());
4    }
5 });

//Exemplo 1 usando expressão lambda
6 Collections.sort(palavras,
7 (palavra1, palavra2) -> Integer.compare(palavra1.length(), palavra2.length()));

//Exemplo 2 usando expressão lambda em sua versão mais concisa
8 palavras.sort(comparingInt(String::length));

Outra dica muito importante que o Bloch passa ainda sobre essa questão de lambdas é de sempre que possível priorizar o uso de métodos genéricos, pois assim diminuirá as chances do compilador dar erro por inferência de tipo.

Por exemplo, as enums facilitam muito o uso interfaces funcionais e lambdas exatamente pelo conceito de métodos mais genéricos.

//Exemplo de uso com Enum sem interface funcional
1 public enum Operacao {
2   SOMA("+") {
3       public double apply(double x, double y) { return x + y; }
4   },
5   SUBTRACAO("-") {
6       public double apply(double x, double y) { return x - y; }
7   },
8   MULTIPLICACAO("*") {
9       public double apply(double x, double y) { return x * y; }
10  },
11  DIVISAO("/") {
12      public double apply(double x, double y) { return x / y; }
13  };

14  private final String simbolo;

//Construtor da enum
15 Operacao(String simbolo) { 
16  this.simbolo = simbolo; 
17 }

//Pelas boas práticas de Bloch, sempre dar o override no toString
18 @Override public String toString() { 
19  return simbolo; 
20 }

//método abstrato para cada implementação
21 public abstract double apply(double x, double y);

22 }

Do jeito que o código está acima, para cada constante será dado um override no método apply afinal, cada operação precisa de uma ação diferente para o mesmo método.

Agora veja como isso fica mais conciso, ou seja, reduzido e simples ao usarmos lambda:

1 public enum Operacao {
2   SOMA("+", (x, y) -> x + y),
3   SUBTRACAO("-", (x, y) -> x - y),
4   MULTIPLICACAO("*", (x, y) -> x * y),
5   DIVISAO("/", (x, y) -> x / y);

6 private final String simbolo;

7 private final DoubleBinaryOperator operacao;

//construtor da enum
8 Operation(String simbolo, DoubleBinaryOperator operacao) {
9       this.simbolo = simbolo;
10      this.operacao = operacao;
11 }

12 @Override public String toString() { 
13  return simbolo; 
14 }

/**o que antes era um método abstrato se torna um método concreto e 
* passamos a utilizar a interface funcional DoubleBinaryOperator cuja a ação é
* receber dois dados e receber um.
*/
15  public double apply(double x, double y) {
16      return operacao.applyAsDouble(x, y);
17  }
18 }

Então vamos esquecer as classes abstrastas e classes anônimas?

Admito que o uso de classe abstrata ainda é algo um pouco confuso para mim se você for pensando em SOLID, por exemplo e até mesmo no próprio Java Efetivo, porém, gosto do ponto que o Bloch trás em seu livro quando diz o seguinte:

“[...] Lambdas are limited to functional interfaces. If you want to create an instance of an abstract class, you can do it with an anonymous class, but not a lambda. Similarly, you can use anonymous classes to create instances of interfaces with multiple abstract methods.”

Que, em tradução livre, nas mais é do que o uso de lambdas se restrigem ao uso de interfaces funcionais (algo que a própria documentação do Java reforça) e diz que a classe abstrata você utiliza numa classe anônima e NÃO em um lambda. Da mesma forma que você utiliza a classe anônima para criar instâncias de interfaces com múltiplos métodos.

Fontes: Documentação Java

Effective Java - Joshua Bloch

Quando usar Classes aninhadas, classes locais, classes anônimas e expressões lambdas

Carolina Dias Fonseca — Wed, 09 Feb 2022 22:35:46 +0000

Classe aninhada

O Java te permite definir uma classe dentro de outra. Exemplo:

class ClasseExterna {
    ...
    class ClasseAninhada {
        ...
    }
}

Classes aninhadas te permitem ter lógica de grupo de classes que vocês está utilizando em um único lugar, o ponto positivo é que esse tipo de recurso aumento o encapsulamento, cria um código mais legível e melhora a manutenção do código.

Já as classes locais, classes anônimas e expressões lambdas também dão os mesmo benefícios, porém são recomendadas para usos mais específicos.

Classe local

Classes locais são aquelas que você define dentro do bloco. Você normalmente encontra classes locais definidas dentro de corpo de métodos.

public class ExemploClasseLocal {

    static String regularExpression = "[^0-9]";

        //Método que precisamos
    public static void validarTelefone(
        String telefone1, String telefone2) {

        final int tamanhoTelefone = 10;

                //Criamos uma classe para poder implementar a lógica de validação do telefone
        class NumeroTelefone {

            String numeroTelefoneFormatado = null;

            PhoneNumber(String numeroTelefone){

                String numeroAtual = numeroTelefone.replaceAll(
                  regularExpression, "");
                if (numeroAtual.length() == tamanhoTelefone)
                    numeroTelefoneFormatado = numeroAtual;
                else
                    numeroTelefoneFormatado = null;
            }

            public String getNumero() {
                return numeroTelefoneFormatado;
            }


        NumeroTelefone numero1 = new NumeroTelefone(telefone1);
        NumeroTelefone numero2 = new NumeroTelefone(telefone2);

        if (numero1.getNumero() == null) 
            System.out.println("Primeiro número é inválido");
        else
            System.out.println("Primeiro número é " + numero1.getNumero());
        if (numero2.getNumber() == null)
            System.out.println("Segundo número é inválido");
        else
            System.out.println("Segundo número é  " + numero2.getNumero());

    }

        //Chamando o nosso método de validação de telefone
    public static void main(String... args) {
        validarTelefone("123-456-7890", "456-7890");
    }
}

Use caso você precise criar mais de uma instância da classe, acessar seu construtor ou criar um novo.

Classe Anônima

Use caso você precise declarar campos ou adicionar métodos.

Expressão Lambda

Use caso você esteja encapsulando um único comportamento que você quer passar para outro trecho de código. Por exemplo, você pode usar expressão lambda se você quer que determinada ação performe em cada elemento de uma collection quando o processo está completo ou quando o processo encontra algum erro.

Você também pode usar caso precise de uma única instância de uma interface funcional e você não precisa de nada muito completo (exemplo: você não precisa de construtor, um nome tipado, campos ou métodos adicionais).

Fonte traduzida livremente: https://docs.oracle.com/javase/tutorial/java/javaOO/whentouse.html

O que eu já fiz sendo Developer Advocate... até o momento

Carolina Dias Fonseca — Thu, 02 Dec 2021 14:50:55 +0000

Hoje 02 de dezembro de 2021, completo 60 dias como developer advocate.

E uma pergunta que recebo muito, tanto dentro como fora da empresa é: "Mas o que você faz exatamente?"

E esse foi o meu primeiro aprendizado, falar que você é developer advocate é um tanto complicado, pois você não pertence exatamente a um time e muito menos é um cargo.

Arrisco dizer que ser developer advocate é quase um modo de pensar, trabalhar e atuar no meio de tecnologia, porque você precisa saber tecnologia (não precisa ser necessariamente uma pessoa desenvolvedora, pode ser QA, SRE, tech writer, etc) o importante é que tu tenha conhecimento de algum universo da tecnologia e saiba aquilo bem.

Por outro lado, temos contato com a comunidade, com a galera de marketing, com o time de engenharia (pois é, não somos nós que criamos/sustentamos a tecnologia que advogamos) e investimos umas boas horas de conversa com o pessoal de produto também, isso sem esquecer de conversar com a comunidade.

Números 2 e 3

Certo, mas ainda não respondi o que eu faço exatamente, né?

Explicar o que eu faço e como faço, foi meu aprendizado número dois e, na mesma hora, veio o aprendizado de número três, porque cada empresa enxerga esse pokémon de uma forma um pouco diferente :)

Então... vou falar o que eu fiz e como fiz até o momento na empresa em que trabalho (Zup)

O que e como

Nesses 60 dias, pensado nos times de engenharia e produto, eu me aprofundei no projeto do qual faço parte, mexi, revirei, testei, fiz algumas poc's, levei alguns feedbacks para o time de engenharia, pedi para a comunidade me dar a visão dela sobre aquele projeto, fui atrás de entender como a comunidade vê e entende o projeto.

Já do lado de marketing, diria que foi mais uma troca levando feedbacks de como a comunidade recebe as informações, com o que ela curte interagir e receber novos projetos e/ou materiais.

Além disso, ainda no que tange o marketing, ajudei a organizar um hackathon para a galera conhecer mais os projetos, aprender como eles funcionam e nos dar feedbacks também. Isso sem contar uma jornada colaborativa e minha primeira live coding para a galera começar a conhecer mais sobre o universo open source e, o mais recente, o TDC com palestras muito massas de galera especialista tanto da empresa como de mercado.

Tudo isso em time e sempre trocando figurinha com a galera de marketing, de produto e engenharia. Algumas vezes, eu mesma fui lá e fiz alguma coisa, exemplo: Alterar uma documentação e subir para produção, corrigir um bug no projeto que advogo, sugerir algumas métricas de acompanhamento para o lado de growth do projeto, mapeamento de comunidade das quais me ajudaria a ter maior visão do projeto e que acredito que possam se beneficiar do mesmo.

Quais são os planos para os próximos passo?

No momento estou estudando muito o universo que está relacionado ao produto que advogo, no caso, estamos falando de DevOps, automação, Python, IaC, etc. Para poder falar com mais propriedade sobre tudo isso e também fazer artigos, live coding, palestras para compartilhar com a comunidade.

Por esse motivo, como gosto de usar essa plataforma para "documentar" meus estudos e usá-lo para consultas futuras, vou compartilhar aqui conforme for aprendendo desse universo também :)

Padrões DAO e Repository

Carolina Dias Fonseca — Thu, 18 Nov 2021 23:26:19 +0000

O padrão DAO (Data Access Object ou, em pt-BR, Objeto de Acesso a Dados), é uma abstração de persistência de dados e é considerado próximo da camada de armazenamento de dados que, normalmente, é centrado em tabelas.

Entretanto, em muitos casos, o DAO possui muitas tabelas permitindo, de uma forma mais direta, enviar/receber dados do banco, escondendo as queries mais feias.

Exemplo de implementação:


//Primeiramente, criamos a classe de domínio
public class Usuario{
    private Long id;
    private String nome;
    private String email;

    //getters e setters
}

//Na sequência, criamos uma interface que provê um CRUD simples para a classe de Domínio do Usuário
public interface UsuarioDao{
    void criar(Usuario usuario);
    Usuario buscar(Long id);
    void atualizar(Usuario usuario);
    void deletar(Long id);
}

//Por fim, fazemos a implementação
public class UsuarioDaoImpl implements UsuarioDao{
    private final EntityManager em;

    @Override
    public void criar(Usuario usuario){
        em.persist(usuario);
    }

    @Override
    public Usuario buscar(Long id){
        return em.find(Usuario.class,id);
    }
    //...
}

Padrão Repository

De acordo com Eric Evans em seu livro Domain-Driven Design, o "repository é um mecanismo para encapsular o banco, recuperar e buscar comportamento que simulam uma coleção de objetos."

Ainda nessa mesma linha, o livro Padrão de Arquitetura de aplicações Enterprise, do mesmo autor, diz que "entre as camadas de domínio e de mapeamento de dados, utiliza-se uma interface de coleção para acessar os objetos de domínio."

Em outras palavras, o repository também lida com dados e esconde queries de forma semelhante ao padrão DAO. Porém, o repository se trata de uma padrão de alto nível, ou seja, muito mais próximo da lógica de negócio de uma aplicação.

Consequentemente, um repository pode usar um DAO para pegar dados do banco e popular um objeto de domínio, da mesma forma que pode usar um DAO para pegar informações do objeto de domínio e mandar para o armazenamento no banco.

Exemplo de implementação:

public interface UsuarioRepository{
    Usuario get(Long id);
    void adicionar(Usuario usuario);
    void atualizar(Usuario usuario);
    void remover(Usuario usuario);
}

public class UsuarioRepositoryImpl implements UsuarioRepository{

    //Aqui vamos utilizar o DAO
    private UsuarioDaoImpl usuarioDaoImpl;

    @Override
    public Usuario get(Long id){
        return usuarioDaoImpl.buscar(id);
    }

    @Override
    public void adicionar(Usuario usuario){
        usuarioDaoImpl.criar(usuario);
    }

//...
}

Olhando da forma como fizemos até o momento, ambas implementações parecem muito semelhantes, porque a classe Usuario é uma classe de domínio anêmica. E, o repository, é somente outra camada sobre o DAO.

Entretanto, o DAO se torna um candidato perfeito para acesso aos dados enquanto que o Repository é uma forma ideal de se implementar um UseCase.

Um exemplo mais rico sobre o uso do Repository como UseCase:

public class UsuarioRedeSocial extends Usuario{
    private List<Tweet> tweets;
}

public class UsuarioRepositoryImpl implements UsuarioRepository{

    //Aqui vamos utilizar o DAO
    private UsuarioDaoImpl usuarioDaoImpl;
    //Pulamos a etapa de criar o Tweet e TweetDao, mas só para acelerar a compreensão de uma classe de Domínio mais rica
    private TweetDaoImpl

    @Override
    public Usuario get(Long id){
        //não queremos mais apenas salvar o usuário, mas queremos o usuário e seus tweets
        UsuarioRedeSocial usuario = (UsuarioRedeSocial) usuarioDaoImpl.buscar(id);  
        List<Tweet> tweets = tweetDaoImpl.fetchTweets(usuario.getEmail());
        usuario.setTweets(tweets);

        return usuario;
    }

    @Override
    public void adicionar(Usuario usuario){
        usuarioDaoImpl.criar(usuario);
    }

//...
}

Nesse novo exemplo, temos agregação de informação que provê um objeto de domínio que é útil para o nosso UseCase. O poderíamos fazer o mesmo para as demais redes sociais, no mesmo Repository.

Fonte: DAO vs Repository Pattern

Expressão Lambda - Parte III (Sintaxe)

Carolina Dias Fonseca — Thu, 11 Nov 2021 23:35:23 +0000

Para finalizar a série sobre Lambdas do Java, vamos seguir com a tradução do trecho sobre a sintaxe de uma expressão lambda.

Uma expressão lambda em Java, consiste do seguinte:

Uma lista separada por vírgula de parâmetros formais envolvidos por parênteses. No caso, é p

(p) -> p.getGenero() == Pessoa.Genero.MASCULINO 
    && p.getIdade() >= 18
    && p.getIdade() <= 25

Entretanto, você também pode omitir o parênteses caso se tenha somente um parâmetro ou usar apenas o parênteses sem o parâmetro. Exemplos:

//Somente o parênteses
() -> p.getGenero() == Pessoa.Genero.MASCULINO 
    && p.getIdade() >= 18
    && p.getIdade() <= 25

//Somente o parâmentro
p -> p.getGenero() == Pessoa.Genero.MASCULINO 
    && p.getIdade() >= 18
    && p.getIdade() <= 25

A seta, →
Um corpo que consiste de uma expressão única ou um bloco de declaração.

//body
p.getGenero() == Pessoa.Genero.MASCULINO 
    && p.getIdade() >= 18
    && p.getIdade() <= 25

Se você declara uma expressão única, o JRE avalia a expressão e retorna o valor dela, em contra partida, você também pode utilizar uma declaração de retorno:

p -> {
return p.getGenero() == Pessoa.Genero.MASCULINO 
    && p.getIdade() >= 18
    && p.getIdade() <= 25;
}

Uma declaração de retorno não é uma expressão, numa expressão lambda você deve envolver a declaração com {}.

Note que a expressão lambda parece muito com a declaração de um método, inclusive, você pode considerar a expressão lambda como um método anônimo - método sem nome.

Exemplo:

public class Calculadora {

    interface IntegerMath {
        int operacao(int a, int b);   
    }

    public int operadorBinario(int a, int b, IntegerMath op) {
        return op.operacao(a, b);
    }

    public static void main(String... args) {

        Calculadora meuApp = new Calculadora();

//Uso da expressão lambda como função anônima
        IntegerMath adicao = (a, b) -> a + b;
        IntegerMath subtracao = (a, b) -> a - b;
        System.out.println("40 + 2 = " +
            meuApp.operadorBinario(40, 2, adicao));
        System.out.println("20 - 10 = " +
            meuApp.operadorBinario(20, 10, subtracao));    
    }
}

Com isso, fechamos o assunto de expressão Lambda em Java :) no próximo post, veremos a tradução sobre Interface Funcional que foi mencionada na parte 2

Fonte: Documentação Oracle

Expressão Lambda - Parte II (Quando e como usar)

Carolina Dias Fonseca — Thu, 04 Nov 2021 23:16:29 +0000

Parte 02 de 03 da documentação Oracle sobre Expressão Lambda :)

Um problema com classes anônimas é que, se sua implementação for muito simples (sendo uma interface que contém um único método, por exemplo), a sua sintaxe pode parecer incerta e não muito clara.

Nesses casos, normalmente você está tentando passar funcionalidade como argumento para outro método, semelhante a iniciar uma ação quando alguém clica num botão.

As expressões lambdas te permitem fazer isso, trabalhar uma funcionalidade como argumento ou código como dado de informação.

No artigo anterior sobre Classe Anônima, mostramos como implementar uma classe sem a necessidade de se criar uma classe com um único método e implementar/estender outra classe para seguir com a construção da sua aplicação.

A expressão Lambda te permite fazer a mesma coisa, porém de uma forma mais conscisa ainda.

Caso de Uso Ideal para Expressão Lambda

Vamos supor que você está criando uma aplicação de rede social. Você quer criar uma feature que permite o administrador a realizar determinada ação, como, por exemplo, enviar uma mensagem para membros que satisfaçam determinada condição.

Cada pessoa nessa rede social é representada pela classe Pessoa:

public class Pessoa {
    public enum GENERO{
        MASCULINO, FEMININO
    }
    String nome;
    LocalDate nascimento;
    GENERO genero;
    String email;
    public int getIdade(){//...}    
    public void printPessoa(){//...}

}

Suponha que os membros dessa rede social estão armazenado numa List<Pessoa>

Passo 01: Criar métodos que encontrem membros que atendem a uma certa característica

Uma forma muito simples de fazer essa filtragem é criar um método para cada tipo de filtro que se precisa fazer, como para gênero ou idade.

Exemplo:

public static void printPessoasMaioresQue(List<Pessoa> relacao, int idade){
    for(Pessoa p : relacao){
        if(p.getIdade() >= age){
            p.printPessoa();
        }
    }
}

Esse método é muito frágil por conta da quantidade de atualizações que a aplicação ainda passará por conta de inclusão de novos membros.

Outro ponto, suponha que você atualizou a sua aplicação e alterou a estrutura da classe Pessoa que passa a conter mais variáveis, talvez isso impacte em todos os lugares em que você instanciou a classe de forma que o algoritmo que usa essa informação agora haja de forma diferente.

E, por fim, é um método restritivo, e se você precisar mostrar em tela usuários mais novo?

Passo 02: Criar métodos de busca mais generalizados

O método abaixo é mais generalizado do que o anterior:

public static void printPessoasComIdadeEntre(List<Pessoa> relacao, int menor, int maior){
    for(Pessoa p : relacao){
        if(menor <= p.getIdade() && p.getIdade() >= maior){
            p.printPessoa();
        }
    }
}

Mas e se você quiser mostrar em tela membros de determinado gênero ou a combinação de idade e gênero?

Ou se você quiser incluir atributos como status de relacionamento ou localização?

Apesar do método acima ser mais genérico do que o anterior, ter que criar um método para cada possibilidade de busca ainda deixa o código frágil.

Ao invés disso você pode separar as especificações de critério de busca do que você quer busca em classes separadas.

Passo 03: Especificar o código de critério de busca em uma classe local

O método abaixo mostra em tela membros que atendem determinado critério de busca que você especificar:

public static void printPessoas(List<Perssoa> relacao, VerificaPessoa criterio){
    for(Pessoa p: relacao){
        if(criterio.buscaPessoa(p)){
            p.printPessoa();
        }
    }
}

Esse método verifica cada Pessoa que consta na List relacao, se a pessoa atender o critério passado em criterio.buscaPessoa(p) então o método mostra em tela a pessoa.

Para especificar o critério de busca, você implementa uma interface chamada VerificaPessoa

interface VerificaPessoa{
    boolean buscaPessoa(Pessoa p);
}

A classe que fará uso desse método, faz a implementação da interface, exemplo:

class VerificaPessoaElegivelParaExercito implements VerificaPessoa{
    public boolean buscaPessoa(Pessoa p){
        return p.genero == Pessoa.Genero.MASCULINO && p.getIdade() >= 18 && p.get() <= 25;
    }
}

Para usar esse classe, você criar uma instância e invoca o printPessoa:

printPessoa(relacao, new VerificaPessoaElegivelParaExercito())

Apesar dessa estrutura ser menos frágil, você não precisa reescrever métodos se você alterar a classe Pessoa, você ainda tem código adicional: uma interface nova e uma classe local para cada busca que você pretende fazer na sua aplicação.

Passo 04: Especificar o critério de busca numa classe anônima

printPessoa(relacao, new VerificaPessoa(){
    public boolean buscaPessoa(Pessoa p){
        return p.genero == Pessoa.Genero.MASCULINO && p.getIdade() >= 18 && p.get() <= 25;
    }
})

Essa forma reduz a quantidade de linhas de código porque você não precisa criar uma nova classe cada busca que você precisa realizar.

Entretanto, a sintaxe de uma classe anônima é volumoso considerando que a interface VerificaPessoa só contém um método. Nesse caso, você pode usar uma expressão lambda ao invés da classe anônima.

Passo 05: Especificar o critério de busca numa expressão lambda

A interface VerificaPessoa é uma interface funcional. Uma classe funcional é aquela que contém apenas um método abstrato.

Exatamente por ela ser uma classe funcional que contém um único método abstrato, você pode omitir o nome do método quando você a implementa. Ao fazer isso, você estará implementando uma expressão lambda ao invés de uma classe anônima.

printPessoa(relacao,(Pessoa p)-> p.genero == Pessoa.Genero.MASCULINO && p.getIdade() >= 18 && p.get() <= 25);

Você ainda pode usar uma interface funcional padrão no lugar de criar uma interface, o que ajuda a reduzir a criação de código.


interface Predicate<Pessoa>{
    boolean buscaPessoa(Pessoa p);  
}

public static void printPessoaComPredicate(List<Pessoa> relacao, Predicate<Pessoa> criterio){
    for(Pessoa p : relacao){
        if(criterio.buscaPessoa(p){
            p.printPessoa();
        }
    }
}

printPessoaComPredicate(relacao, p -> p.getGenero == Pessoa.Genero.MASCULINO && p.getIdade() >= 18 && p.getIdade() <= 25);

Fonte: Documentação Oracle
Colaboração: Silvair Soares

Expressão Lambda - Parte I (Classes anônimas)

Carolina Dias Fonseca — Thu, 28 Oct 2021 23:16:57 +0000

Estudando um pouco sobre Expressão Lambda em Java, acabei caindo na documentação e, consequentemente, li sobre Classe Anônima.

Achei legal e resolvi traduzir e tentar resumir:

Classes anônimas te permitem criar um código mais conciso. Elas te permitem declarar e instanciar uma classe ao mesmo tempo.

Elas são como classes locais exceto pelo fato de que elas não possuem nome.

Recomenda-se que você as utilize caso precise de uma classe local uma única vez.

Declarando uma classe anônima

Enquanto classes locais são classes declaradas, as classes anônimas são expressões o que significa que você define a classe em outra expressão.

Exemplo:

public class HelloWorldAnonymousClasses {

    interface HelloWorld {
        public void greet();
        public void greetSomeone(String someone);
    }

    public void sayHello() {

        class EnglishGreeting implements HelloWorld {
            String name = "world";
            public void greet() {
                greetSomeone("world");
            }
            public void greetSomeone(String someone) {
                name = someone;
                System.out.println("Hello " + name);
            }
        }
      //classe declarada na inicialização
        HelloWorld englishGreeting = new EnglishGreeting();

//classe anônima na inicialização da variável frenchGreeting
        HelloWorld frenchGreeting = new HelloWorld() {
            String name = "tout le monde";
            public void greet() {
                greetSomeone("tout le monde");
            }
            public void greetSomeone(String someone) {
                name = someone;
                System.out.println("Salut " + name);
            }
        };

        //classe anônima na inicialização da variável frenchGreeting
        HelloWorld spanishGreeting = new HelloWorld() {
            String name = "mundo";
            public void greet() {
                greetSomeone("mundo");
            }
            public void greetSomeone(String someone) {
                name = someone;
                System.out.println("Hola, " + name);
            }
        };
//Mesmo efeito no final das constas
        englishGreeting.greet();
        frenchGreeting.greetSomeone("Fred");
        spanishGreeting.greet();
    }

    public static void main(String... args) {
        HelloWorldAnonymousClasses myApp =
            new HelloWorldAnonymousClasses();
        myApp.sayHello();
    }            
}

Sintaxe da classe anônima

Como já mencionado anteriormente, uma classe anônima é uma expressão.

A sintaxe de uma classe anônima é igual a invocação de um construtor, exceto pela definição contida no bloco de código.

Considere a instância do objeto frenchGreeting:

HelloWorld frenchGreeting = new HelloWorld() {
            String name = "tout le monde";
            public void greet() {
                greetSomeone("tout le monde");
            }
            public void greetSomeone(String someone) {
                name = someone;
                System.out.println("Salut " + name);
            }
        };

A classe anônima consiste no seguinte:

O operador new
O nome de uma interface para implementar ou para estender. No exemplo anterior, a classe anônima está implementando a interface HelloWorld.
Parênteses que contém os argumentos para um construtor, exatamente igual a instância de uma classe normal. Nota: Quando você implementa uma interface, não tem construtor, então você só usa um par de parênteses igual ao exemplo.
Um corpo onde se faz a declaração do corpo da classe. Mais especificamente, no corpo, declaração de método são permitidos porém declarações não.

Considerando que a definição de uma classe anônima é ser uma expressão, ela tem que ser parte de uma variável.

Fonte: Documentação Java

Java Shell Tool

Carolina Dias Fonseca — Thu, 21 Oct 2021 16:22:27 +0000

Estava fazendo a trilha Java Explorer da Oracle e lá, pela primeira vez, ouvi falar sobre o Jshell e resolvi escrever sobre ele, porque achei bem legal o que ele faz.

O Java Shell Tool (Jshell) é uma ferramenta interativa para aprender a programar em Java e prototipar código. Jshell é é um Read-Evaluate-Print Loop (REPL). Isso significa que ele vai ler (Read) e avaliar (Evaluate) os comandos e mostrar (Print) o resultado e então voltar ao início para o próximo input. O REPL faz o seu tempo de execução mais tangível e te permite testar hipóteses sobre isso.

O JShell é utilizado via linha de comando, assim você pode fazer o input de dados no programa um por um e ver o resultado imediatamente, além da possibilidade de fazer os ajustes que forem necessários.

O desenvolvimento de um programa Java, normalmente envolve o processo a seguir:

Escrever o programa;
Compilar e corrigir potenciais erros
Rodar o programa
Descobrir o que deu errado
Editar
Repetir o processo

JShell auxiliar no processo de experimentação do código de forma muito mais simples. Te permite testar argumentos, testar variações de métodos e experimentar API's que você ainda não sabe usar no dia a dia.

JShell é melhor do que uma IDE?

Não, o Jshell não substitui o uso de uma IDE, ele apenas facilita e agilia o processo de aprendizado tanto sobre o Java como validação de hipóteses, conforme já mencionado anteriormente.

Conforme você vai escrevendo o seu código, você pode colar trecho do código no JShell e testar ou então copiar o código que está testando no JShell e colar na sua IDE.

Usando o JShell

O JShell faz parte do JDK9 e superiores, portanto, é necessário que tenha, ao menos, o JDK9 instalado em seu computador.

A partir disso, basta ir ao terminar e digitar jshell

Exemplo prático:

Trechos traduzidos de:

Documentação Oracle

FreeCodeCamp: This is why your read-eval-print-loop is so amazing

Tipos de deploy e como isso impacta a vida de uma aplicação

Carolina Dias Fonseca — Thu, 14 Oct 2021 23:09:59 +0000

Na squad onde estava alocada, por ser a minha primeira aplicação em produção, resolvi acompanhar e aprender mais sobre esse universo chamado devops, infra, enfim... toda a parte que não está envolvida com o código em si, mas com a estrutura de como isso vai rodar para o usuário.

Nesse meio tempo de trabalho e estudos, conheci o CharlesCD que trabalha com o conceito de deploy em círculos, bom... aqui começa a minha jornada de aprendizado sobre deploy, começa que existem tipos de deploy e eu sequer sabia disso, a seguir um compilado de artigo que encontrei sobre o tema.

Primeiramente, o que é um tipo deploy ou estratégia de deploy?

Em algumas literaturas e empresas, chamamos de tipo de deploy ou estratégia de deploy a forma na qual a aplicação será colocada a disposição do usuário final.

Uma estratégia de deploy é uma forma de alterar ou atualização uma aplicação. O objetivo é fazer a mudança sem afetar a aplicação de forma que o usuário mal note as mudanças

Fonte: OpenShift - RedHat, tradução livre

Alguns tipos de deploys utilizados

Canary

O deploy do tipo Canary visa reduzir o risco de disponibilizar uma atualização de uma única vez para todos os usuários, dessa forma, a atualização é disponibiliza para apenas um grupo seleto de usuários antes de ir para o público geral.

Em Canary, o ambiente antigo segue ativo simultaneamente ao novo ambiente. Por isso, pode-se liberar uma parcela dos usuários para acessar o novo ambiente e ver como ele se comporta com usuários reais. Assim é possível identificar se vão existir problemas no dia a dia.

Fonte: Locaweb

Entretanto, essa estratégia não propõe nenhuma estratégia de escolha de usuários para a expansão. Por esse motivo, torna-se mais difícil gerenciar as versões existentes do sistema, o que contribui para que não haja tanto versionamento.

Blue-Green

O tipo blue-green trabalha com o conceito de espelhamento, ou seja, a instância da versão antiga e a instância da versão mais recente rodam em paralelo em produção e o SRE utiliza um load balancer para ir direcionando o tráfego da versão antiga para a versão mais recente.

O principal benefício desta técnica é que o downtime é zero, trazendo mais segurança para a transição. Apesar disso, o custo para o blue-green deployment é bastante elevado, já que demanda o dobro de infraestrutura para ser executado.

Círculos

A ideia consiste que se crie círculos de implementação, e disponibilize para cada circulo a versão de software que melhor convém para o usuário e para a regra de negócio.

Círculos são grupos de usuários criados a partir de características específicas dentro de um mesmo ambiente. Dessa forma, o desenvolvedor pode segmentar os usuários de acordo com as regras que mais fizerem sentido para testar aquela release.

Fonte: CharlesCD - ZupInnovation

Por exemplo, é possível criar um círculo de engenheiros da região Norte do Brasil, outro de engenheiros do sudeste e um terceiro contendo todos os engenheiros brasileiros. Baseado nessa segmentação de clientes, pode-se elaborar diversas lógicas de deploy.

Conclusão de uma desenvolvedora

Claramente que não há a melhor estratégia aqui, tudo vai depender da necessidade da empresa/instituição que vai implementar a aplicação e nível de conhecimento do SRE, por exemplo, para escolher qual será utilizada.

Na minha concepção, tendo a vivência de atuar na área comercial e de negócios e agora atuando como desenvolvedora, faz muito sentido utilizar o deploy em círculo para testar hipóteses desde de alterações na UX para o cliente (será que ele prefere um botão aqui ou ali? Isso aqui está mais legível para ele ou não? Esse pop-up é mais inclusivo para a terceira idade ou não?) até implementação de novas regras de negócio (precisamos aumentar a conversão de clientes nessa área do e-commerce, será que se expormos a oferta dessa forma funcionará? temos esse bug na rotina, mas será que é bug mesmo? Nosso público-alvo são os estudantes do sudeste, será que eles são os maiores usuários da nossa ferramenta?).

Por experiência minha, eu sofria demais com as demandas que clientes me passavam de mudanças que eles gostariam, mas nunca acontecia ou então demorava meses para "subir", com a ideia de deploy em círculos esse cenário muda drasticamente.

E você, o que acha desses conceitos? Algum faz mais sentido para você, assim como o deploy em círculos faz mais sentido para mim?

Compartilha aqui comigo!

Programação Orientada a Aspectos

Carolina Dias Fonseca — Thu, 07 Oct 2021 23:12:09 +0000

Dando sequência aos meus estudos sobre Micronaut, dei de cara com mais um conceito que não conhecia muito e resolvi pesquisar mais sobre.

Dessa vez, me refiro à Programação Orientada a Aspectos que, para a surpresa de ninguém, o Spring também trabalha com ela (se você quiser).

A Programação Orientada a Aspectos (ou Aspects Oriented Programming - AOP) foi um estudo desenvolvido por: Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes,Jean-Marc Loingtier, John Irwin em 1997.

Esse estudo teve por objetivo melhorar alguns pontos complexos no desenvolvimento de código que nem o paradigma procedural e nem a orientação a objetos conseguiam resolver. Os autores apontam que exatamente esses pontos complexos são os aspectos do design de código que, novamente, a OOP não consegue resolver por mais que ela busque representar o mundo real.

Por conta disso, os autores apresentam uma nova técnica de programação chamada orientada a aspectos, onde é possível usar isolamento de forma apropriada, reutilizar código e composição tudo baseado no aspecto do código. O que eu acredito ser bem relevante sobre o artigo dessa galera é que, em momento algum, eles não falam que OOP, Programação Procedural ou até mesmo a Programação Funcional são ruins, mas sim que a AOP é uma forma de complementar essas programações em pontos que geralmente deixam o desenvolvimento com um código complexo de ser desenvolvido e, posteriormente, dar manutenção.

Ok, mas o que exatamente é um aspecto na programação?

Enquanto um componente tende a ser uma unidade do sistema como, por exemplo, uma imagem, conta bancária, etc. Aspectos são propriedades que afetam a performance e a semântica dos componentes de forma sistemática, por exemplo, padrão de acesso e sincronização de objetos concorrentes, conforme imagem abaixo:

Fonte: Aspect-Oriented Programming traduzido por: Carolina Fonseca

Para facilitar mais na explicação, os autores usam erros e falhas como base, pois sabemos que são os pontos mais comuns no dia a dia como desenvolvedores, afinal, sempre teremos que customizar/adicionar algum handle quer seja para captar qualquer tipo de erro que dê na aplicação ou lidar com erros/falhas específicas.

"Many performance-related issues are aspects, because performance optimizations often exploit information about the execution context that spans components."

Muitos problemas relacionados a performance, são aspectos. Porque a otimização de performance sempre explora a informação sobre o contexto de execução onde os componentes estão.

Mão no código

Vamos ver um exemplo prático usando Java como base, no caso, vamos utilizar a Biblioteca Digital sugerida na imagem anterior:



public class Livro {
    String título, autor;
    int isbn;  

    public String getTitulo(){
        return título;  
    }
    public String getAutor(){
        return autor;  
    }
    public int getIsbn() {
        return isbn;  
    }
}

public class Repository {
    private Livro livros[];
    private int nlivros = 0;

    public Repository (int dbsize)  {    
        livros = new Livro[dbsize];  
    }

    public void registrar (Livro liv)  {    
        livros [nlivros++] = liv;  
    }

    public void retirar (Livro liv)  {    
            ... 
    }

}

Os autores destacam que programas como o acima, onde precisam gerenciar todas as instâncias criadas de suas classes e as chamadas de métodos, não são capazes de fazer esse gerenciamento todo sozinho, afinal, estamos falando de uma estrutura cujo foco é a abstração que queremos fazer do sistema real e não como ele vai gerenciar todas as sua chamadas.

O mais indicado seria o uso de reflection para acessar essa comunicação de forma distribuída, porém, criar reflection no nível de detalhe que a OOP precisa, acaba se tornando algo muito complexo.

É aqui onde temos uma oportunidade real de se utilizar a AOP:



remote Repository { 
        void registrar (Livro); 
        void retirar (Livro: copy isbn); 
        Livro: copy isbn busca(String);}

Acima temos um trecho de código com foco no aspecto da comunicação. Basicamente, ele comunica ao Repository que quando novos livros são registrados, ele deve criar uma cópia daquele objeto e quando o livro é retirado ele deve copiar somente o número de isbn, o restante do livro não é copiado a menos que seja preciso mais tarde.

O Join e as reflections

Em AOP, temos um conceito chamado Join que nada mais é do que o momento em que unimos o nosso componente ao seu aspecto, uma vez que, em inglês, join significar unir, esse conceito faz total sentido.

E ela faz mais sentido ainda quando falamos de reflection e metaobjetos, porque um sistema reflexivo disponibiliza a base da semântica e implementação da linguagem que estamos utilizando. Falando da metalinguagem, temos acesso à todas as chamadas de funções e stack de execução que, a nível humano, nunca conseguimos ver. Vendo por esse ângulo, é no baixo nível onde é possível aplicarmos os joins da AOP de forma que a reflection faça todo o restante do trabalho, dessa forma, temos os nossos aspectos criados para fins de controle das instâncias e vinculados ao reflection que nem precisamos criar já que utilizamos da própria linguagem para tal.

Conclusão

Admito que enquanto lia o artigo que "criou" o AOP, não esperava encontrar o uso de reflections nele, mas passou a se fazer muito sentido de quando comparamos o uso delas no Spring e no Micronaut.

O Spring já faz as reflections todas de uma vez, ou seja, já vamos fazendo o mapeamento de aspectos no tempo de compilação, ao passo que o Micronaut também faz esse gerenciamento de aspectos, porém somente do que realmente está sendo utilizado na aplicação mas em tempo de pré-compilação, mas falarei mais sobre isso nos próximos artigos ;)

Espero que tenha gostado e se acha que faltou algo ou escrevi algo sem sentido, me chama para conversamos!

Fonte: https://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf

Como funciona a famosa injeção de dependência e porque ela é importante

Carolina Dias Fonseca — Thu, 30 Sep 2021 11:41:33 +0000

Um ponto interessante sobre o mundo Java é a enorme quantidade de atividades em construir alternativas para o J2EE.

Muito disso vem da complexidade do universo do J2EE, mas além disso, explorando alternativas é de onde vem as ideias criativas.

Um problema comum em lidar com diferentes elementos é, por exemplo: "Como conectar uma arquitetura web com a interface do banco dedados quando eles são construídos por diferentes times e com conhecimentos distintos?"

Foi desse tipo de problema que surgiram inúmeros frameworks com o objetivo de conectar os componentes do J2EE de diferentes camadas. No caso do Java, o mais conhecido é o Spring.

Inclusive, até o Spring já conta com alguns "variantes" digamos assim por conta de saber trabalhar muitos bem com essa componentização. Frameworks que se basearam/propõem a serem melhores que o Spring, por exemplo, são: Micronaut e Quarkus.

Por baixo desses frameworks temos um número interessantes de design principles, o que vai além dos containers do J2EE. Vamos ver alguns desses princípios!

Componentes e Serviços

Para fins de padronização de termos, aqui utilizaremos componentes no sentido de: arquivos .JAR, dll ou até mesmo a importação de uma biblioteca.

E serviços no sentido de: serviço web, mensageria, RPC ou até mesmo um socket.

Exemplo simples

Vamos utilizar o exemplo de um componente que lista filmes por diretor.

class ConsultorDeFilmes {

    public Filme[] filmeDirigidoBy(String diretor) {
        List todosFilmes = finder.findAll();
        for (Iterator it = todosFilmes.iterator(); it.hasNext(); ) {
            Filme filme = (Filme) it.next();
            if (!filme.getDiretor().equals(diretor)) it.remove();
        }
        return (Filme[]) todosFilmes.toArray(new Filme[todosFilmes.size()]);
    }
}

A implementação dessa função é totalmente simples, é pedido para encontrar um objeto retornar todos os filmes da lista. Depois é solicitado que ele retorne somente os filmes dirigidos pelo diretor que queremos.

O ponto que vamos focar nessa implantação é no finder.findAll();

mais especificamente em como nós conectamos o objeto que é solicitado (o diretor) com um objeto finder em particular. A razão disso ser interessante é que eu quero que o método filmeDirigidoBy seja completamente independente de como todos os são armazenados.

Basicamente o método que estamos estudando se resume ao finder e tudo o que o finder faz é saber como responder ao método findAll. Dessa forma, podemos definir uma interface para o finder.

public interface ProcuraFilmes{
    List findAll();
}

Com isso, nós desacoplamos o findAll(), mas ainda assim teremos que torná-lo em classe concreta em algum momento para retornar os filmes que queremos. Então faremos de forma que o código passe para o construtor do ConsultorDeFilmes:

class ConsultorDeFilmes {

        private ProcuraFilmes finder;
        public ConsultorDeFilmes(){
            finder = new ColunaDelimitadaProcuraFilmes("filmes1.txt");  
    }

}

O nome da classe de implementação vendo do fato de estamos usando um arquivo .txt delimitado por colunas.

Agora se eu usar essa classe somente nessa implementação, está ok, mas o que acontece se mais alguém quiser uma cópia dessa mesma aplicação? 🤔

Simples, caso a pessoa armazene os filmes em um arquivo .txt delimitado por colunas chamado "filmes1.txt", a aplicação vai rodar tranquilamente. Caso use um nome de arquivo diferente, por exemplo, ela só precisa alterar o nome na classe de implantação, até aqui, ok.

Porém e se ela utilizar uma forma totalmente diferente de armazenar os filmes, por exemplo, num banco de dados SQL, um arquivo XML, um serviço web, entre outros?🤔🤔

Nesse caso, precisaremos de um classe diferente para fazer a implantação e puxar os dados. E aqui está o ponto: Porque nós colocamos o ProcuraFilme como uma interface, isso não vai alterar o método filmesDirigidoBy , mas ainda assim precisamos de uma forma de instanciar o finder de forma correta na implementação.

MovieLister == ConsultorDeFilmes // MovieFinder == ProcuraFilmes // MovieFinderImpl == implementação concreta da interface. Fonte: https://martinfowler.com/articles/injection/naive.gif

A imagem acima mostra como a nossa classe ConsultorDeFilmes está dependendo tanto da interface ProcuraFilmes como de sua classe concreta, nós precisamos que a classe dependa apenas da interface.

Mas como fazer isso? 🤔🤔🤔

A classe de implementação não está linkada à aplicação em tempo de compilação e não sabemos como essa pessoa fará a implementação da interface. Ou seja, corremos o risco de ter o código alterado (implementação da interface que consta no ConsultorDeFilmes) e, consequentemente, a aplicação vai quebrar.

Por isso precisamos que a classe ConsultorDeFilmes dependa apenas da interface, ignore a forma como ela é implementada e seja capaz de rodar a instância dela.

Nós chamamos essa situação de plugin, numa situação real podemos ter milhares de serviços e componentes que precisamos implementar de diferentes formas. O plugin interage com esses serviços e componentes através de interfaces e, então, eles decidem as implementações sem alterar a nossa aplicação.

Voltando a nossa pergunta anterior: Mas como fazer isso? 🤔🤔🤔

A resposta: Inversão de Controle

Inversão de controle

Como mencionado anteriormente, a inversão de controle é uma característica muito comum de alguns frameworks, mas falar que eles são especiais por conta disso é o mesmo que falar que uma ferrari é especial porque ela tem pneus.

O que importa mesmo é: "Qual aspecto de controle esses frameworks invertem?"

Inversão de controle é o que diferencia um framework de uma biblioteca. Uma biblioteca é somente um conjunto de funções que você utiliza, já um framework é um design abstrato com comportamentos. No framework você precisa colocar comportamento em vários lugares em subclasses ou plugando em suas próprias classes f(o Spring faz isso utilizando Beans e Annotations, por exemplo).

Na nossa aplicação, instanciamos o finder diretamente, o que o impede de ser um plugin. Uma saída é garantir que qualquer usuário desse plugin siga as convenções que queremos e injete isso em suas implementações.

Pensando nisso, Inversão de Controle (Inversion of Control - IoC) é um termo muito genérico e, de acordo com vários especialistas, o termo, nesse caso, seria Injeção de Dependência (Dependecy Injection).

Formas de Injeção de Dependência

A ideia da injeção de dependência é ter um "montador" ou assembler que poupla o campo na classe ConsultorDeFilmes com a implementação apropriada da interface ProcuraFilmes, ficando da seguinte forma:

MovieLister == ConsultorDeFilmes // MovieFinder == ProcuraFilmes // MovieFinderImpl == implementação concreta da interface. Assembler == Montador Fonte: https://martinfowler.com/articles/injection/injector.gif

Em cima desse diagrama, temos 3 formas principais de fazer a injeção de dependência:

Inversão de Controle tipo 01 - Injeção por interface (Injection Interface)
Inversão de Controle tipo 02 - Injeção por setter(Setter Interface)
Inversão de Controle tipo 03 - Injeção por contrutor(Constructor Interface)

Para o nosso caso, vamos falar sobre o Spring.

Essa framework inclui camadas de abstração para transações, frameworks de persistência em banco de dados, aplicação web e JDBC. Ele suporta tanto a injeção por construtor como por setter, mas os desenvolvedores dele preferem a injeção por setter, vamos ver como fica nesse caso.

Para que o nosso ConsultorDeFilmes aceite a injeção, temos que definir o método set para o serviço.

class ConsultorDeFilmes {

    private ProcuraFilmes finder;
    public void setFinder(ProcuraFilmes finder){
        this.finder = finder;
    }

}

Também vamos definir um setter para o nome do arquivo:

class ArquivoConsultorDeFilmes {

    public void setNomeArquivo(String nomeArquivo){
        this.nomeArquivo = nomeArquivo;
    }

}

O último passo é fazer a configuração, o Spring suporta configurações por arquivos XML e no código também, mas por XML é o mais apropriado.

<beans>
    <bean id="ConsultorDeFilmes" class="spring.ConsultorDeFilmes">
        <property name="finder">
            <ref local="ProcuraFilmes"/>
        </property>
    </bean>
    <bean id="ProcuraFilmes" class="spring.ArquivoConsultorDeFilmes">
        <property name="nomeArquivo">
            <value>filmes1.txt</value>
        </property>
    </bean>
</beans>

Um exemplo de como testar:

public void testComSpring() throws Exception {
    ApplicationContext ctx = new

FileSystemXmlApplicationContext("spring.xml");
    ConsultorDeFilmes consultor = (ConsultorDeFilmes)

ctx.getBean("ConsultorDeFilmes");
    Filmes[] filmes = consultor.filmesDirigidosBy("James Cameron");

    assertEquals("Titanic", movies[0].getTitle());
}

Finalizando...

Primeiramente gostaria de agradecer a sua curiosidade e paciência em ler até aqui, boa parte do texto foi tradução minha dos textos do Martin Fowler, tentei ao máximo ser fiel às explicações dele, alguns pontos que achei muito complexo, tentei simplificar a explicação para que ficasse mais claro para mim e para ti 😉 e também acrescentei um pouco do meu ponto de vista.

Quero ressaltar aqui também, caso seja user do Spring e suas famosas annotations: as annotations nada mais são do que interfaces, logo, elas seguem o mesmo princípio da inversão de controle mencionado ao longo do texto. Lembre-se que criamos uma bean e no Spring temos o @bean, aqui a conclusão fica fácil, certo?

Fontes: https://martinfowler.com/articles/injection.html

https://martinfowler.com/bliki/InversionOfControl.html

O que uma boa API Rest deve ter e porquê?

Carolina Dias Fonseca — Fri, 24 Sep 2021 01:13:30 +0000

Mas antes, o que é REST?

REST é um tipo de arquitetura web desenvolvido por Roy Thomas Fielding, em seus estudos ele procurou entender os principais problemas da web e como poderia ajudar a melhorar a performance, escalabilidade e demais problemas que haviam relacionados ao tema, isso lá em 2000.

Nos seus estudos, ele consta que o principal problema da www era:

> Como compartilhar informações com todo mundo de forma estruturada sendo que em cada terminal de comunicação (tanto lado do cliente como do servidor) haviam informações de formas variadas (textos, imagens, vídeos, etc), tamanhos variados e sistemas operacionais diversos (linux, windows, etc)?

Isso era (e ainda é) um questionamento muito importante tendo em vista que a web é cada dia mais utilizada e deveria ter a possibilidade de transitar qualquer tipo de informação de forma rápida, eficiente e escalável.

Sendo assim, Roy Fielding, se embasando em arquiteturas já existentes, elaborou a arquitetura REST de comunicação web.

REST é o acrônomo de Representational State Transfer ou, do português, Transferência Representacional de Estado (tradução livre).

Características da arquitetura REST

Responsabilidades na relação cliente-servidor (client-server) são separadas, isso significa que a preocupação da parte visual fica com o cliente enquanto que o servidor fica com o lado de armazenamento/recuperação de dados, assim temos uma distribuição de tarefas muito melhor e nem dos lados fica sobrecarregado.
Isso é um ponto interessante, pois, automaticamente, auxilia na simplicidade do processo de comunicação (uma vez que o lado do servidor é independente do que ocorre do lado do cliente) e melhora a escalabilidade.
A comunicação é STATELESS, ou seja, ela não guarda em memória as requisições e respostas dessas requisições. Isso auxilia na simplicidade da comunicação, uma vez que, para que a requisição tenha a sua resposta, ela deve vir completa e, em caso de erro, fica fácil de visualizar onde está o erro.
Também é escalável, exatamente por conta dessa simplicidade da comunicação, ou seja, o servidor não precisa gerenciar arquivos em memória (o que atrapalharia muito performance, por exemplo) e é confiável, pois, caso não siga o protocolo, a comunicação dará erro
É CACHEABLE, ou seja, mantém um cache (uma memória de respostas de determinadas requisições já feitas anteriormente) para retorno mais rápido caso. Isso serve para corrigir um ponto de performance da questão do stateless, porque, sem o recurso de cache, a arquitetura sempre terá que recuperar a mesma resposta do zero, sendo que ela poderia ter uma performance melhor se já tivesse a resposta pronta.
Mas como o cache não entra em conflito com o stateless? Simples, o stateless significa que a aplicação não guarda nenhum estado de requisição, login, etc, entretanto, com o cache, já temos uma resposta pronta caso a requisição feita seja alguma já feita anteriormente.
A arquitetura REST tem uma interface uniforme, ou seja, qualquer aplicação que siga essa arquitetura, se comunicará sempre da mesma forma com as especificações que serão melhor faladas mais a frente.

Como o REST transita as informações?

Diferentemente do que muita gente acha, a arquitetura REST NÃO transita o objeto (imagem, arquivo, audio, etc) em si, mas sim uma representação dele (eis aí o nome de transferência representacional de estado). Ela segue a mesma ideia de encapsulamento da informação que se vê no mundo da programação orientada a objetos, onde temos os getters e setters.

fonte: Roy Fielding (https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)

Nessa arquitetura, quando queremos ter acesso à uma imagem, por exemplo, a chamamos de recurso, ou seja, qualquer item que se queira ter acesso (receber ou enviar) chamamos de recurso. Esse recurso terá um identificador (aqui é onde entra a idea do getter), o identificador será uma URI. Quando ser acessar o identificador, aí sim temos o acesso ao recurso, no nosso exemplo teremos acesso à imagem.

A representação é a forma como esse recurso será apresentado, no caso, no formato metadata (chave e valor), atualmente é muito comum ser representado no formato JSON.

E, por fim, o control data especifica o motivo da comunicação e como ela ocorre, ou seja, o que a requisição quer e como ela precisa.

Conclusão

Entendendo um pouco sobre os problemas da web e como queremos fazer a comunicação de forma prática, escalável e mais padronizada, faz muito sentido seguirmos o padrão REST no momento de construirmos uma API.