Para analizar um código, assim como qualquer outra coisa, nós precisamos de parâmetros. Precisamos nos basear em algo que saibamos que seja bom, para assim podermos determinar se outra coisa é tão boa quanto, melhor, ou até pior.

Com código não é diferente. Então antes de respondermos a pergunta feita no inicio deste texto, precisamos definir o que é um código bom, ou melhor, que caracteristicas deve ter um codigo para ser considerado bom. Vamos agora recorrer a alguns principios OO para nos municiar de paramêtros para assim julgarmos o codigo em questão

Robert Martin, o uncle Bob, escreveu a muito tempo sobre os principios OO num documento chamado: PrinciplesOfOod. Dos principios OO descritos neste artigo, pelo menos 5 ficaram bastante famosos, e são conhecidos pela sigla SOLID, são eles:

Single Responsibility Principle (SRP) - A classe deve ter uma única responsabilidade, uma única razão de existir.

Open Closed Principle (OCP) - A classe deve ser aberta para extensão (sublcasses e sobrescrita de metodos) e fechada para modifiação *

Liskov Substitution Principle (LSP) - Resumidamente ele serve para nos aletar para heranças sem sentido.

Interface Segregation Principle (ISP) - Defende que uma classe deve depender apenas dos métodos que usa de uma outra classe. Interfaces são um mecanismo para isso.

Dependency Inversion Principle (ISP) - Defende que componentes maiores devem depender não de componentes menores, mas sim de uma abstração deles.

*Pode ser discutido, principalmente se você estiver trabalhando em um modelo de dominio incremental, ou seja, você vai descobrindo as necessidades de suas classes durante o desenvolvimento de software. Neste cenário o principio OCP pode ser radical demais. Lembre-se é preciso ter bom senso.

Dos principios descritos por Robert Martin, ficaremos apenas com o SRP. Sabendo agora que uma classe deve possuir apenas uma úncia responsabilidade. Quantas responsabilidades podemos identificar na classe Principal do post anterior?

Podemos identificar facilmente 3 responsabilidades. São elas:

1 - Controla a execução da aplicação.

2 - Cadastra um novo DVD

3 - Lista todos os DVD's cadastrados

Agora ficou facil ver que a classe Principal está ferindo o SRP. A resposabilidade desta classe deveria ser apenas: Controlar a execução da aplicação. Precisamos retirar da classe Principal as demais responsabilidades. Como faremos isso?

A melhor solução é remover todo o código "extra" da classe Principal. Mas o grande problema, é que sem esse codigo nossa aplicação vai parar de funcionar! Este código não pode simplesmente desaparecer. O que nós precisamos fazer e leva-lo para outro lugar. E como estamos programando segundo o paradigma de Orientação a Objetos, vamos precisar de novas classes para cada uma das responsabilidades descritas acima.

Teriamos as seguintes classes com as seguintes responsabilidades:

Classe: Principal

Responsabilidade: Controlar a execucao da aplicação

Classe: CadastrarDvd

Responsabilidade: Cuidar da lógica de inclusao de um dvd

Classe: ListarTodosDvds

Responsabilidade: Cuidar da lógica de exibicao dos dvd's

Após estas alterações vamos perceber que a classe Principal ficou bem melhor.

Mas será que isso foi suficiente? Apenas esta alteração terá salvado a vida de nossa pequena aplicação?

Tente aplicar você mesmo o SRP em nossas novas classes e comente a respeito. No proximo post continuamos nossa saga.

Abraços.

Sergio Azevedo Junior

Confira abaixo como ficaram nossas classes:

Principal

public class Principal {
  public static void main(String[] args) throws IOException {
    Scanner scan = new Scanner(System.in);
    int opcao = 0;
    do {
      System.out.println("--------------- Controle de Dvds e Cds ---------------");
      System.out.println("   1 - Cadastrar Novo Dvd ");
      System.out.println("   2 - Listar Dvd's ");
      System.out.println("   3 - Terminar ");
      System.out.println("------------------------------------------------------");
      System.out.println(" Escolha uma opção:--> ");
 
      opcao = scan.nextInt();
      switch (opcao) {
      case 1: {
        new CadastraDvd().executa();
        break;
      }
      case 2: {
        new ListaTodosDvds().executa();
        break;
      }
      }
    } while (opcao < 3);
  }
}

CadastraDvds

public class CadastraDvd {
 
  public void executa() throws IOException {
    PrintStream ps = null;
    File file = new File("Dvds.txt");
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    try {
      ps = new PrintStream(file);
 
      Dvd dvd = new Dvd();
      System.out.println("Titulo.: ");
      dvd.setTitulo(br.readLine());
      System.out.println("Sinopse: ");
      dvd.setSinopse(br.readLine());
      System.out.println("Genero.: ");
      dvd.setGenero(br.readLine());
      System.out.println("Ano....: ");
      dvd.setAno(br.readLine());
      System.out.println("Duracao: ");
      dvd.setDuracao(br.readLine());
 
      ps.println(dvd.getTitulo());
      ps.println(dvd.getSinopse());
      ps.println(dvd.getGenero());
      ps.println(dvd.getAno());
      ps.println(dvd.getDuracao());
    } finally {
      br.close();
      if (ps != null)
        ps.close();
    }
  }
}

ListaTodosDvds

public class ListaTodosDvds {
  public void executa() throws FileNotFoundException {
    System.out.println("------------- Lista de Dvd's -------------");
    Scanner reader = new Scanner(new File("Dvds.txt"));
    while (reader.hasNext()) {
      System.out.println(reader.nextLine());
    }
    reader.close();
  }
}

Depois de ler livros, ou fazer cursos, essas "dificuldades operacionais" desaparecem, afinal aprendemos a usar melhor a linguagem e passamos a conhecer melhor suas apis. Nesse ponto já somos capazes de por exemplo converter um String em um numero, criar e organizar listas de elementos, usar arquivos para realizar operações de leitura e escrita.

Uma vez que já sabemos criar aplicações em Java, precisamos nos perguntar outras coisas:

• "As aplicações que criamos foram constuidas da melhor maneira possível?"
• "Meu código está orientado a objetos, ou é apenas procedural Java?"
• "Como eu identifico o que deve e o que nao deve ser uma classe no meu sistema?"

A boa noticia é que estas perguntas possuem respostas. A má noticia é que eu não vou dar todas as respostas de bandeja a vocês. Ao invés disso vamos aprender a ter "senso critico" sobre o código que escrevemos. Para isso vamos começar simplesmente criando uma pequena e simples aplicação Java para cadastro e consulta de Dvd's.

Em geral, nos preocupamos primeiramente em escrever uma aplicação que funcione, e talvez esta atitude nos leve a não ter uma aplicação bem construida. Existem várias "desculpas" que podemos utilizar para justificar esse tipo de construção, mas dentre elas destacam-se as classicas: "nao tenho tempo" e "o cronograma está apertado". =)

Nesta primeira etapa estamos interessados em escrever uma aplicação que funcione. ( Talvez porque estejamos sem tempo =p )

Bem, para isso nos vamos precisar da classe Dvd, entao:

public class Dvd {
	private String titulo;
	private String sinopse;
	private String genero;
	private String ano;
	private String duracao;
	private boolean emprestado;
        //Gets e Sets
}

Agora vamos a nossa classe "principal":

public class Principal {
	public static void main(String[] args) throws FileNotFoundException {
		Scanner scan = new Scanner(System.in);
		int opcao = 0;
		do {
			System.out
					.println("--------------- Controle de Dvds e Cds ---------------");
			System.out.println("   1 - Cadastrar Novo Dvd ");
			System.out.println("   2 - Listar Dvd's ");
			System.out.println("   3 - Terminar ");
			System.out
					.println("------------------------------------------------------");
			System.out.println(" Escolha uma opção:--> ");
 
			opcao = scan.nextInt();
 
			switch (opcao) {
			case 1: {
				BufferedReader br = new BufferedReader(new InputStreamReader(
						System.in));
				PrintStream ps = new PrintStream(new File("Dvds.txt"));
				try {
					Dvd dvd = new Dvd();
					System.out.println("Titulo.: ");
					dvd.setTitulo(br.readLine());
					System.out.println("Sinopse: ");
					dvd.setSinopse(br.readLine());
					System.out.println("Genero.: ");
					dvd.setGenero(br.readLine());
					System.out.println("Ano....: ");
					dvd.setAno(br.readLine());
					System.out.println("Duracao: ");
					dvd.setDuracao(br.readLine());
 
					ps.println(dvd.getTitulo());
					ps.println(dvd.getSinopse());
					ps.println(dvd.getGenero());
					ps.println(dvd.getAno());
					ps.println(dvd.getDuracao());
					ps.close();
					br.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
				break;
			}
			case 2: {
				System.out
						.println("------------- Lista de Dvd's -------------");
				Scanner reader = new Scanner(new File("Dvds.txt"));
				while (reader.hasNext()) {
					System.out.println(reader.nextLine());
				}
				reader.close();
			}
			}
		} while (opcao < 3);
	}
}

É isso ai gente! Nossa aplicação está pronta e funcionando. Porém eu faço a vocês duas perguntas:
Este codigo está bom? Porque?

No proximo post, vamos analisar este codigo responder a estas perguntas. Porém você que leu este post nao precisa esperar, pode escrever seu comentario aqui respondendo esta pergunta.

Abraços,
Sergio Junior

Confira a sequencia deste post aqui.

Durante muito tempo trabalhei com Delphi, e nesta comunidade de desenvolvedores quando se fala em "código expressivo" e "modelo de domínio" esse tipo de reação pode até ser considerado comum. Uma vez que a grande maioria destes desenvolvedores está infectada pela filosofia RAD. Eu pensava que quando começasse a trabalhar com Java esse tipo de reação fosse diminuir. Mas não é o que estou notando. Pelo menos no ambiente em que estou inserido, as caretas e narizes torcidos estão presentes. Nesta semana mesmo, sugeri a um colega uma alteração em um nome de método para algo mais expressivo, e ouvi o seguinte:

"Ih cara ta bom assim mesmo. Deixa que, qualquer coisa depois a gente mexe."

Já há alguns meses atrás, entrei numa discussão sobre modelos anêmicos X modelos ricos, onde outro colega tentou de todo jeito, me dizer que modelo rico é muito bonito no meio acadêmico, mas que na prática isso fica inviável. Ainda tive que ouvir que:

"É desse jeito que o pessoal de Java costuma desenvolver. Todo mundo faz assim".

Fiquei pensando, porque todos nós não passamos a comer carne de cachorro? Afinal a China é o país mais populoso do mundo, e se lá comer carne de cachorro é normal, porque pra gente não é?

A discussão ficou mais quente quando eu disse que aquilo não passava de "procedural Java", e que ele tirava o direito do objeto fazer o básico, que é controlar seu próprio estado. Só depois disso ele considerou pensar sobre modelos ricos, mas depois desse dia ele nunca mais tocou nesse assunto.

Uma coisa que eu tenho visto muito são as pessoas dizerem assim:

"Estou num projeto sinistro agora, a gente ta usando de tudo JPA, EJB3, JMS, Lucene, Drools ..."

Mas não vejo estas pessoas preocupadas em construir um código bem escrito e expressivo, em pensar num modelo de domínio, em fazer um refactoring constante e em aplicarem as boas práticas de OO. Às vezes me sinto como se aquelas pessoas que trabalhavam com Delphi ao meu redor, todas estivessem trabalhando com Java agora. Às vezes cansa ser o diferente, eu sempre penso em deixar pra lá, ficar quieto e evitar discussões, mas eu não consigo. Não consigo porque eu acredito nisso tudo, e sinto a necessidade de transmitir essa mensagem.

Por isso eu peço a vocês dêem uma chance as boas práticas. Não peço por mim, mas acredito que Martin Fowler, Eric Evans e muitos outros "famosos" merecem crédito.


Serginho.

Cedendo ao convite do Luiz, vou escrever a minha retrospectiva também. Trabalhamos na mesma equipe e isso pode tornar o que vou escrever uma cópia do post dele, já que isso pode acontecer, vou colar alguns trechos aqui na cara de pau mesmo hehehehe!

Post do Luiz

O ano de 2008 foi um ano muito bom profissionalmente, neste ano consegui mudar de tecnologia no meu trabalho, consegui aplicar algumas das principais técnicas que estudo há alguns anos.