Neste post vou analisar alguns pontos relacionados a encapsulamento e o uso do Linq.

Vamos começar a analisar um modelo de objetos simples:

Como podemos perceber uma empresa tem muitos funcionários e estas classes poderiam ser escritas desta forma:

class Funcionario
{
    public string Nome { get; set; }
    public string Cargo { get; set; }
    public double Salario { get; set; }
    public bool Ativo { get; set; }
}
 
class Empresa
{
    public List Funcionarios {get; set;}
    public Empresa()
    {
      Funcionarios = new List();
    }
}

Aqui um exemplo de como utilizar as classes deste modelo:

 Funcionario luiz = new Funcionario() { Ativo = true, Nome = "Luiz", Salario = 1000,
    Cargo = "Desenvolvedor" };
 Funcionario sergio = new Funcionario() { Ativo = true, Nome = "Sergim", Salario = 1000,
    Cargo = "Desenvolvedor" };
 Funcionario iuri = new Funcionario() { Ativo = true, Nome = "Iuri", Salario = 1100,
    Cargo = "Desenvolvedor" };
 Funcionario luciano = new Funcionario() { Ativo = false, Nome = "Luciano", Salario = 2000,
    Cargo = "Arquiteto" };
 Funcionario eduardo = new Funcionario() { Ativo = true, Nome = "Eduardo", Salario = 3000,
    Cargo = "Gerente" };
 
  // adicionando funcionários na empresa.
 Empresa google = new Empresa();
 google.Funcionarios.Add(luiz);
 google.Funcionarios.Add(iuri);
 google.Funcionarios.Add(luciano);
 google.Funcionarios.Add(sergio);

Identificando falhas no design

Mesmo com  um design simples como este um problema básico de design aparece. A classe empresa expõe o atributo Funcionário através de uma property e assim viola o encapsulamento. Mas uma property não encapsula o atributo, através de gets e sets? A resposta é que neste caso, o atributo está escondido, mas eu tenho acesso a referência diretamente e o resultado disso é que qualquer “cliente” que usar o objeto do tipo empresa, pode manipular a lista de funcionários diretamente, ignorando quaisquer regras que por ventura existam. Por exemplo imagine a situação onde quisessemos que nunca um Funcionario fosse removido. Do jeito que está qualquer um poderia fazer google.Funcionarios.Remove(sergio).

Um outro problema que aparece nesse código é que temos um conceito de negócio sendo manipulado, mas não explícito. Quando fazemos google.Funcionarios.add(luiz), isso  representa uma ação no nosso domínio. Na verdade o que queremos fazer é contratar o Luiz. Técnicas como Domain Driven Design, pregam que nosso código deve falar a lingua do negócio. De acordo com DDD, precisamos tornar este conceito explícito em nosso código. Vamos alterar a classe empresa para suportar isso:

 class Empresa
 {
    public List Funcionarios {get; set;}
    public Empresa()
    {
      Funcionarios = new List();
    }
 
    public void Contrata(Funcionario funcionario)
    {
       this.Funcionarios.Add(funcionario);
    }
 }

Repare que agora, existe um método na classe empresa que representa o conceito que estava implícito. Sempre devemos tornar os conceitos implícitos explícitos. Agora nosso código fica muito mais OO, se é que se pode usar esta expressão:

  google.Contrata(eduardo);
  google.Contrata(luiz);
  google.Contrata(iuri);
  google.Contrata(luciano);
  google.Contrata(sergio);

Agora o conceito “contratação” está explícito, mas ainda existe um problema, a classe empresa, ainda tem uma property que te permite acessar a lista de funcionários. Apesar de ter criado o método contrata, isso não garante que a lista não será manipulada diretamente.

google.Funcionarios.Remove(luiz);

Este trecho de código mostra novamente o problema de expor a lista, neste caso ao invés de contratar um funcionário estamos demitindo. Agora imagine que existe uma regra que especifica que todo funcinário demitido tem que ser inativado, como vamos garantir que isto vai ser feito? Podemos inativar o funcionário antes de removê-lo da lista:

  luiz.Inativar();
  google.Funcionarios.Remove(luiz);

O problema desta abordagem é óbvio, não tem como garantir que esta regra será executada toda vez que precisarmos demitir um funcionário. Para resolver isso, novamente vamos tornar explícito o conceito de demissão.

 class Empresa
 {
    private List Funcionarios;
    public Empresa()
    {
      Funcionarios = new List();
    }
 
    public void Contrata(Funcionario funcionario)
    {
       this.Funcionarios.Add(funcionario);
    }
 
    public void Demite(Funcionario funcionario)
    {
      funcionario.Inativar();
      this.Funcionarios.Remove(funcionario);
     }
  }

Agora a classe Empresa  tem um método Demite, o que torna explícito o conceito demissão. Note que antes de executar a remoção do usuário, fazemos a sua inativação. Além disso, não existe mais a property na classe empresa que expõe o atributo funcionários, este atributo é privado e somente a classe empresa sabe como manipulá-lo de forma correta.

Não fizemos nada além de seguir princípios básicos de OO aplicando o encapsulamento, e neste pequeno exemplo mostramos como é possível tornar o código mais fácil de se manter utilizando esta técnica.

Encapsulamento e linq no C#

Nas últimas versões do C# várias coisas interessantes foram incluídas, tornando a linguagem muito poderosa. Mas por outro lado, tenho visto uso destas técnicas de forma não muito organizada, principalmente em relação as boas práticas de programação em uma linguagem Orientada a Objetos.

Um dos recursos mais interessantes e que utiliza muitas das novas características da linguagem é o Linq. Vamos dar uma olhada no que é possível fazer com o Linq:

  var nomes = new string[] {"luiz","sergio", "iuri", "eduardo", "jose maria"};
  var nomesQueComecamComS = nomes.Where(nome => nome.StartsWith("S"));
  var nomesQueContemMaria = nomes.Where(nome => nome.Contains("maria"));
  string[] cities = new string[] { "Auckland", "Oslo", "Sydney","Seattle", "Paris", "Los Angeles" };
  IEnumerable places = from city in cities
                             where city.Length >
                             orderby city descending
                             select city;

Isso é muito poderoso, podemos fazer operações sobre lista de forma muito mais declarativa. O problema é que todo esse poder pode esconder algumas surpresas se não tomarmos os devidos cuidados com sua utilização.
No nosso primeiro exemplo, vimos como encapsulamento na sua forma mais simples, torna nosso código mais simples, expressivo e de mais fácil manutenção.
Vamos voltar a analisar o primeiro exemplo, só que pela perspectiva do uso do linq. Para isso vamos precisar colocar criar novamente a property  funcionários na classe empresa.

 class Empresa
 {
    public List Funcionarios {get;set;}
  }

Considere os seguintes trechos de códigos, e veja como é possível trabalhar de forma declarativa utilizando os recursos do linq:

  var funcionarios = google.Funcionarios;
  var salarioMedido = funcionarios.Average(f => f.Salario);
  Console.WriteLine(salarioMedido);
  var funcionariosAtivos = funcionarios.Where(f => f.Ativo == true);
  var desenvolvedores = funcionarios.Where(f => f.Cargo.Equals("desenvolvedor"));
  var GerenteComSalarioMaior2000 = funcionarios.Where(f => f.Cargo.Equals("Gerente") &
                                                                            f.Salario > 2000);

Veja que fizemos várias operações sobre a lista de funcionários da empresa. A primeira vista isso é muito prático, mas podemos ter problemas com essa abordagem.  Na minha opinião o maior problema disso é que perdemos o conhecimento fundamental do negócio. Se eu quero saber o salário médio dos funcionários de uma empresa, então esta operaçao deve estar explícita no objeto empresa.

Mas se eu fizer isso vou deixar  de tirar proveito das facilidaes do Linq? Não, basta promover o encapsulamento e mover este código para a classe empresa. A partir de agora o usuário da classe vai passar a invocar o método disponível no objeto empresa:

  salarioMedido = google.ObterSalarioMedio();

Após fazer a mudança, o código fica mais simples, intuitivo e expressivo. O leitor do código, entende rapidamente o que esta linha de código faz e não precisa saber detalhes de implementação.
Outro exemplo de código é a linha :

  var funcionariosAtivos = funcionarios.Where(f => f.Ativo == true);

Neste trecho temos 2 problemas. Novamente a falta de encapsulamento. De quem é a responsabilidade de dizer quem são os funcionários ativos? Deveria ser da classe empresa, então precisamos criar um novo método na classe para obter os funcionários ativos.
Então na classe empresa temos:

  public IEnumerablel ObterFuncionariosAtivos()
  {
     return this.Funcionarios.Where(f => f.Ativo == true);
  }

O segundo problema desta expressão novamente é falta de encapsulamento, estamos violando o princípio Tell don’t Ask quando fazemos  f.ativo == true. Quem sabe dizer se o funcionário é ativo ou não é o objeto funcionário, então é necessário criar o método na classe funcionário para tornar o explícito o conceito:

  class Funcionario
  {
     public string Nome { get; set; }
     public string Cargo { get; set; }
     public double Salario { get; set; }
     public bool Ativo { get; set; }
 
     public bool EstahAtivo()
     {
       return this.ativo == true;
     }
  }

E na classe empresa  podemos alterar a expressão Linq para utilizar o método da classe funcionário.

  public IEnumerable ObterFuncionariosAtivos()
  {
    return this.Funcionarios.Where(f => f.EstahAtivo());
  }

Aqui a classe empresa completa:

class Empresa
 {
    private List Funcionarios;
    public Empresa()
    {
      Funcionarios = new List();
    }
 
    public void Contrata(Funcionario funcionario)
    {
       this.Funcionarios.Add(funcionario);
    }
 
    public void Demite(Funcionario funcionario)
    {
      funcionario.Inativar();
      this.Funcionarios.Remove(funcionario);
     }     
 
     public IEnumerablel ObterFuncionariosAtivos()
     {
       return this.Funcionarios.Where(f => f.Ativo == true);
     }  
 
     public double ObterSalarioMedio()
     {
         return this.Funcionarios.Average(f => f.Salario);
     }
  }

Estes são apenas alguns exemplos de código simples onde a falta de encapsulamento pode trazer problemas no futuro. Com certeza um dos mais evidentes é a replicação de código e consequentemente os problemas de manutenção causados por ele, além é claro do fato do conhecimento do domínio ficar espalhado entre várias expressões Linq.

Então os problemas são das novas features do C#?

Não, com certeza isso não é problema das novas features do c#. A questão evidente é que muitos desenvolvedores estão esquecendo princípios básicos ao utilizarem estes recursos.

Existem alguns artigos na web falando sobre a tendência de se misturar os paradigmas funcional e OO. Nós como desenvolvedores só temos a ganhar com isso, pois podemos tirar proveito do  melhor dos dois paradigmas. O que não pode acontecer é voltarmos aos problemas que tínhamos no passado, geralmente por  descuido ou  simplesmente por um “relaxamento”  com princípios básicos de Orientação Objetos.

até a próxima,
Luiz Costa

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.

Acho que isso a maioria das pessoas já sabia, mas o que tenho visto por aí em projetos que trabalhei é exatamente o contrário: um modelo de objetos exatamente igual ao modelo de dados.

Por que ainda utilizamos uma abordagem assim?
Em minha opinião, o principal problema é que muitos desenvolvedores ainda não entenderam corretamente Orientação a Objetos. A prova disso são os sistemas escritos de forma totalmente procedural.

Tentarei exemplificar algumas destas diferenças. Este exemplo é uma adaptação de um problema real que eu presenciei. Vamos imaginar um sistema de cursos onde nós temos as tabelas:

Curso
id
nome
data Inicio
data Fim
idInstrutor

Instrutor
id
nome

Esta é uma simplificação, mas vai ajudar a explorar o problema.
A abordagem comum que eu tenho visto é ter um modelo de objetos que represente as tabelas do banco de dados, pois é necessário persistir as informações destes objetos. Para persistência, em java podemos utilizar o Hibernate/JPA, em Rails podemos utilizar o framework Active Record (que aliás, te induz a fazer exatamente o que eu descrevi acima) e em C# podemos utilizar o NHibernate.

Vamos ver algum código:

public class Curso{
    private int id;
    private String nome;
    private Date dataInicio;
    private Date dataFim;
    private Instrutor instrutor;
 
     ..gets e sets
}
 
public class Instrutor{
    private int id;
    private String nome;
 
    .. gets e sets
}

Em um primeiro momento, não há nada de errado com esta abordagem, certo? Apesar de nosso modelo de objetos refletir exatamente nossas tabelas no banco de dados, ele parece razoável.

Neste sistema, ao cadastrar um curso, temos que assegurar que não existe sobreposição de datas entre cursos com o mesmo instrutor. Exemplo:

Curso: Orientação a Objetos
Instrutor: Zé Bedeu
período: 18/07/2009 até 10/08/2009

Curso: Java
Instrutor: Zé Bedeu
período: 25/07/2009 até 20/08/2009

Reparem que estes dois cursos vão se sobrepor em algum momento. Até o dia 24/07/2009 o Zé Bedeu está ministrando o curso de OO e a partir de 25/07 ele também estará ministrando o curso de Java. Isso pode até fazer sentido, mas no nosso sistema de cursos isso não pode acontecer.

Então o que podemos fazer para evitar isso?
Podemos criar uma verificação para não deixar o mesmo instrutor ser alocado para outro curso se ele já tem aulas previstas dentro daquele período.

Para validar esta regra de negócio, poderíamos escrever um teste:

@Test
public void naoDeveSerPossivelTerDoisCursosParaUmInstrutorEmPeriodosSobrePostos(){
    // para simplicar, vamos utilizar strings para as datas
    // utilizando um buider.
    Curso oo = Curso.de("Orientacao a Objetos")
                               .comInstrutor("Ze Bedeu")
                               .comecandoEm("18/07/2009")
                               .ate("25/07/2009")
                               .Build();    
 
    Curso java = Curso.de("Java")
                               .comInstrutor("Ze Bedeu")
                               .comecandoEm("25/07/2009")
                               .ate("20/08/2009")
                               .Build();
 
     boolean existeSobrePosição =
                           DataUtils.existeSobrePosicaoDeDatas(
                                          oo.getDataInicio,
                                          oo.getDataFim,java.getDataInicio,
                                          java.getDataFim);
    assertFalse(existeSobrePosicao,
                   "não deve haver dois cursos com períodos sobrepostos");
}

Nosso teste faz a validação da regra de negócio, mas tem um problema nesta abordagem. Quem faz a verificação de datas é um objeto totalmente separado do nosso domínio. Reparem que o objeto DataUtils tem um método estatico que recebe 4 parâmetros. Podemos melhorar este exemplo atribuindo a responsabilidade de validar sobreposição para a classe curso, já que é ele quem tem as informações do período.

public class Curso{
    private int id;
    private String nome;
    private Date dataInicio;
    private Date dataFim;
    private Instrutor instrutor;
 
     ..gets e sets
 
    public boolean estahNoMesmoPeriodo(Curso outroCurso){
      return  DataUtils.existeSobrePosicaoDeDatas(
                                           this.getDataInicio(),
                                           this.getDataFim(),
                                           outroCurso.getDataInicio(),
                                           outroCurso.getDataFim());
 
    }
}

Vamos refatorar nosso teste:

@Test
public void naoDeveSerPossivelTerDoisCursosParaUmInstrutorEmPeriodosSobrePostos(){
    // para simplicar, vamos utilizar strings para as datas
    // utilizando um buider.
    Curso oo = Curso.de("Orientacao a Objetos")
                               .comInstrutor("Ze Bedeu")
                               .comecandoEm("18/07/2009")
                               .ate("25/07/2009")
                               .Build();
 
    Curso java = Curso.de("Java")
                               .comInstrutor("Ze Bedeu")
                               .comecandoEm("25/07/2009")
                               .ate("20/08/2009")
                               .Build();
 
    boolean existeSobrePosição = oo.estahNoMesmoPeriodo(java);
    assertFalse(existeSobrePosição,
                    "não deve haver dois cursos com períodos sobrepostos");
}

Começou a melhorar, repare que agora o próprio curso sabe validar se está no mesmo período de outro. Isso é começar delegar responsabilidades para os objetos de domínio, e evitar de se ter objetos fantoches. Nosso modelo de objetos deve ser rico e não anêmico.

Mas ainda temos algo pra melhorar. Existe um conceito que sempre falamos aqui até agora e ainda não foi explorado. Este conceito é o “Período”. Mas o que é o Período?
O período nada mais é que uma representação do tempo transcorrido entre duas datas.

Um curso ocorre em um Período. Se vocês observarem a classe curso, temos data inicial e data final. O que temos na verdade é um período, e este conceito está implícito nesta classe. Em uma boa modelagem de objetos, nós temos que tornar os conceitos explícitos. Para isso podemos refatorar a classe curso e criar a classe período. Podemos também refatorar o método existeSobrePosicaoDeDatas da classe DataUtils para utilizar um período.

class Periodo{
    private Date dataInicio;
    private Date dataFim;
}
 
public class Curso{
    private int id;
    private String nome;
    private Periodo periodo;
    private Instrutor instrutor;
 
     ..gets e sets
 
    public boolean estahNoMesmoPeriodo(Curso outroCurso){
     return  DataUtils.existeSobrePosicaoDeDatas(
                                this.getPeriodo(),
                                outroCurso.getPeriodo());
 
    }
}

Agora a classe Curso na verdade tem um Período. Mas qual a vantagem de se ter o Período ao invés da data Inicio e data Fim? A vantagem é que período agora é uma classe, pode ter responsabilidades, pode tirar vantagens dos conceitos de OO. Além disso este período é altamente reutilizável por várias classes, qualquer uma que precisar do conceito de período pode utilizá-lo.

Mas ainda podemos melhorar mais. Na verdade quem tem a reponsabilidade de verificar se um período sobrepoe outro é o próprio período. A classe período é que sabe quem são as datas de início e de fim. Logo podemos fazer mais um refactoring atribuir a responsabilidade a classe período.

class Periodo{
    private Date dataInicio;
    private Date dataFim;
 
   public Periodo(Date dataInicio, Date DataFim){
      this.dataInicio = dataInicio;
      this.dataFim = dataFim;
   }
 
    public boolean estahNoMesmoPeriodo(Periodo outroPeriodo){
      /// código de validação
    }
 
    public int quantidadeDeDias(){
      // código
    }
    .. gets
}
 
public class Curso{
    private int id;
    private String nome;
    private Periodo periodo;
    private Instrutor instrutor;
 
     ..gets e sets
 
    public boolean estahNoMesmoPeriodo(Curso outroCurso){
     return  this.getPeriodo().estahNoMesmoPeriodo(
                outroCurso.getPeriodo());
    }
}

Após este refactoring, podemos observar algumas coisas:

• A classe período tem um construtor que recebe 2 datas e não tem sets. Não faz sentido você instanciar um objeto período sem data de inicio e data de fim, pois ele (o objeto período)ficararia em um estado inválido.
• A classe período agora é quem sabe validar sobreposição de datas.
• A classe período agora também sabe dizer quantos dias tem no período, já que ela conhece o início e o fim.
• A classe curso agora somente delega a responsabilidade para a classe período validar as datas.
• E o mais importante, eliminamos a necessidade da classe DataUtils. Uma classe como essa é sintoma de um código procedural. A classe dataUtils tem somente procedimentos que lidam com dados separados. A grande sacada de Orientação a Objetos é colocar junto Dados + Operações sobre estes dados.

Agora voltando ao assunto do início do tópico. A classe período não tem necessidade de ser persistida, ela é apenas um Value Object. Os dados da classe período podem ser persistidos junto com a tabela curso. Mas isso não nos limita a ter uma classe que representa um conceito do domínio.
Com JPA vc pode fazer isso facilmente utilizando anotações @Embeddable.

A utilização de uma Fluent Interface nos testes foi de propósito, pois pretendo voltar ao assunto logo logo aqui no blog.

Valeu pessoal,

Luiz Costa