Visual Studio Code versão Preview “integrando comunidades”

Do que trata o artigo

Este artigo tem o objetivo de apresentar o Visual Studio Code, cujo a missão é grandiosa, pois integra as diversas “comunidades“, ou seja, mostra que a IDE está com um conceito diferente, mas com o ar de interoperabilidade, rodando em ambientes Windows, OS X e Linux.

Continuar lendo

Anúncios

Programação orientada a objetos: Herança e polimorfismo – Parte 1

Quando cursei a disciplina de orientação a objetos na universidade já havia estudado alguma coisa em livros de C++ e Java. Tanto os livros quanto o professor da disciplina escolheram a abordagem clássica de ensino de programação orientada a objetos: a do reino animal. Esta abordagem é limitada, do meu ponto de vista, pelo fato de que não confronta o aluno com os problemas do mundo real, os quais este paradigma se predispõe a resolver. Ao aprender POO desta forma, o aluno não aprende a discernir as fronteiras de um sistema e não entende o propósito real de conceitos como a abstração e o encapsulamento. Existe o argumento de que a intenção é ser didático, e que para o iniciante é muito mais fácil aprender utilizando esta analogia. Porém, acredito que este argumento não seja válido uma vez que a disciplina de programação é pré-requisito para se aprender POO, e um aluno com este conhecimento tem capacidade de abstração suficiente para pensar em problemas na forma de entidades lógicas (variáveis, estruturas de dados e etc), sem precisar de exemplos lúdicos para entender os conceitos do paradigma.

Continuar lendo

Expressão Lambda no Java 8

Em março de 2014 a Oracle Corporation lançou, de maneira oficial, o Java 8. Uma das principais novidades da nova versão foi, sem dúvida nenhuma, o suporte a expressão lambda, característica marcante nas linguagens de programação dinâmicas como Java Script, Groovy, Ruby, etc.

A expressão lambda é natural da programação funcional, porém outras linguagens de programação, de  paradigma não funcional, introduziram o recurso para possibilitar um código mais conciso, compacto e fácil de entender.

Continuar lendo

Criando abstrações com repositórios

Ainda hoje vejo muita gente utilizando o padrão DAO em novos projetos, mesmo usando novas tecnologias de persistência como Hibernate e JPA. Não vou entrar em discussões sobre o padrão DAO estar morto ou não. O fato é que em projetos legados, principalmente os que usam JDBC, o DAO está bem vivo. Mas e em projetos que usam ORM? É necessário usar DAOs e os famosos DAOs Genéricos?

Usar DAOs, hoje, pode ser algo extremamente redundante. Pois as ferramentas de ORM já implementam o padrão DAO. Por que você implementaria novamente? Mas, claro, mesmo em projetos novos, pode ser que apareça o cenário para se utilizar o DAO. É uma decisão de design que não deve se basear em senso comum. Projetar software não é uma tarefa trivial, porém, muitos ainda se baseiam em receitas de bolo e não param para trabalhar no design da aplicação. Mas nós aprendemos a criar DAOs na camada de persistência. Como fazer de outra maneira?

Lembre-se que o DAO existe para abstrair a camada de persistência e criar uma interface para o acesso aos dados. Hoje isso já está pronto e quem o faz é a ferramenta de ORM. Em determinados cenários não vejo problema em injetar o EntityManager do JPA direto no Controller. Algumas vezes não existe motivo para se criar uma camada desnecessária. No entanto, é mais usual que tenhamos que fazer consultas usando HQL ou JPA QL, ou que seja necessário o controle manual de  transações. Esse tipo de coisa jamais deve ficar na camada de aplicação. Existe uma forma mais elegante de abstrair a camada de persistência. Criando repositórios.

Repository é um conceito do Domain Drive Design. A camada de domínio de uma aplicação é onde se encontram as regras de negócio, logo, o que ocorre nessa camada está na ‘boca do povo’, ou seja, está nos brainstorms, reuniões de levantamento de requisitos, e nas conversas entre desenvolvedores e pessoal de negócios. A camada de domínio precisa ser escrita no que chamamos de linguagem ubíquoa, a linguagem comum entre devs e negócios.

O que normalmente encontramos dentro de controllers é algo assim:


BookDao dao = new BookDAO();
Book book = dao.findById(id);

Primeiro, se estivermos usando ORM, o DAO é desnecessário. Segundo, é feio de ler. Não tem nada a ver com uma liguagem de domínio. É muito comum as pessoas somente trocarem o nome DAO por Repository e modificar a interface método.

/**

*/
public class BookRepository {

  public final EntityManager entityManager;

  public BookRepository(EntityManager entityManager){
    this.entityManager = entityManager;
  }

  public void add(Book book){
    this.entityManager.merge(book);
  }

  public Book findBook(String id){
    return this.entityManager.find(Book.class, id);
  }

}

A chamada fica assim:

  BookRepository bookRepository = new BookRepository();
  Book book = bookRepository.findBook(id);

Bem melhor, mas ainda temos alguns problemas. Muitos desenvolvedores costumam usar o termo repository no nome das classes, assim como fazem com o dao. Devemos usar nomes significativos para nossas classes, métodos e variáveis, principalmente em se tratando de classes de domínio. Que tal se mudarmos o nome da nossa classe para Library?

  Library library = new Library();
  Book book = library.findBook(id);

Uma coleção de livros, geralmente é uma biblioteca, não é verdade? Mas ainda há um problema. O alto acoplamento com a implementação do repositório. Em se tratando de uma classe de repositório, ela poderá ser usada em vários locais, tanto em controllers, quanto em classes de serviços e até mesmo por classes de modelo. Mesmo usando injeção de dependência, ainda ficamos acoplados com a camada de persistência. Então podemos criar uma interface.


public interface Library{

  void add(Book book);

  List<Book> allBooks();

  Book findBook(String id);

}

E fazemos com que a classe repository implemente a interface Library.


public class BookRepository implements Library {

  public final EntityManager entityManager;

  public BookRepository(EntityManager entityManager){
    this.entityManager = entityManager;
  }

  public void add(Book book){
    this.entityManager.merge(book);
  }

  public List<Book> allBooks(){
    return this.entityManager.createQuery("select b from Book b", Book.class).getResultList();
  }

  public Book findBook(String id){
    return this.entityManager.find(Book.class, id);
  }

}

Agora através de injeção de dependência, as classes podem receber a interface Library como dependência, e não mais depender de sua implementação. Podemos criar uma camada de persistência e inserir as classes *Repository nela enquanto que as interfaces ficam na camada de domínio. Em Domain Drive Design, as classes que implementam a persistência localizam-se na camada de infraestrutura enquanto que as interfaces dos repositórios podem ficar no mesmo pacote dos modelos, na camada de domínio.

Baixe aqui, um exemplo de aplicação modelada com DDD.

Tá safo em ação com coding dojo na Faci

Aconteceu nesta quinta-feira o #tasafoemacao com coding dojo na Faci.

Inicialmente, Luiz Sanches apresentou como funciona a dinâmica de coding dojo para uma plateia de cerca de 50 alunos.

Luiz Sanches apresentando a dinâmica de coding dojoLuiz Sanches apresentando a dinâmica de coding dojo Integrantes do #tasafoemacaoIntegrantes do #tasafoemacao Integrantes do #tasafoemacaoIntegrantes do #tasafoemacao Ramon Rabelo apoiando a apresentação em meio ao auditório lotadoRamon Rabelo apoiando a apresentação em meio ao auditório lotado

Na sequência, os demais “senseis” apresentaram-se brevemente: Ramon Rabello, Paulo Moura, Geraldo Sequeira, Marcelo Andrade e Márcio Ferreira, se apresentaram e todos para suas salas, com as práticas de Android, Javascript, Ruby e Java.

A seguir, os relatos de cada um dos dojos: Java, Android, Ruby, Javascript.

Continuar lendo