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

O Restfulie teve sua versão original implementada em ruby e logo depois foi lançada a versão para Java, mas ainda não havia nenhuma versão para .Net. Foi então que eu e o Sergio Junior aqui do blog resolvemos escrever uma versão para C# da api.
Começamos a implementar a parte cliente do Restfulie e fizemos isto utilizando as características dinâmicas da versão 4.0 do C#.
A idéia é que podemos fazer o client em C# bem próximo da idéia inicial que foi escrita em Ruby.

Aqui vamos mostrar alguns exemplos de utilização desta versão em C#.
Um recurso Pedido pode ter sua representação em xml como a que segue:

<pedido>
        <data>26/12/2009 11:40</data>
        <total>300.00</total>
	<atom:link rel="refresh"
          href="http://www.caelum.com.br/pedidos/1"
          xmlns:atom="http://www.w3.org/2005/Atom"/>
        <atom:link rel="update"
          href="http://www.caelum.com.br/pedidos/1"
          xmlns:atom="..."/>
        <atom:link rel="pagar"
		  href="http://www.caelum.com.br/pedidos/1/pagar"
          xmlns:atom="..."/>
        <atom:link rel="excluir"
          href="http://www.caelum.com.br/pedidos/1
          xmlns:atom="..."/>
         <atom:link rel="GetCliente"
          href="http://www.caelum.com.br/pedidos/1/cliente
          xmlns:atom="..."/>
</pedido>

Respare que a representação deste recurso além de conter  os dados do recurso, possui também  todas as possíveis transições de estado do recurso.
Além  disso, ainda é possível seguir os links e obter outros recursos relacionados: este é o conceito de Hipermedia tanto utilizado na web humana.

Utilizando o Restfulie client C#

Primeiro começamos fazendo o download da DLL e então para obter a representação de um recurso em C#, podemos utilizar algo bem parecido com ruby, o acesso a um entry point:

dynamic  pedido = Restfulie.At(“www.caelum.com.br/pedidos/1.xml”).Get();

Uma vez com a representação do recurso em mãos, podemos obter as informações do mesmo e seguir seus links.

Console.WriteLine(
   string.format(“O valor total do pedido é:{0}”, pedido.Total ) );
Console.WriteLine(
   string.format(“A data do pedido é: {0}”, pedido.Data) );

É possível invocar métodos e alterar o estado do pedido, além de navegar em suas relações com outros recursos.

   pedido.Pagar();
   pedido.Cancelar();
   pedido.Excluir();

Estas chamadas de métodos são remotas, baseadas nos links fornecidos pelo xml e nos protocolos http e media types bem conhecidos.
Para recuperar um recurso relacionado através dos links:

  dynamic cliente = pedido.GetCliente();
  Console.WriteLine(
     string.format(“Nome do cliente {0}”, cliente.nome));

Ainda podemos obter as informações sobre sua resposta web, para analisar headers ou response codes:

  Console.WriteLine(pedido.WebResponse.StatusCode);

As vezes a representação xml do recurso pode conter tags com o caracter “-”.
Por exemplo:

<city>
    <name>Sao Paulo</name>
    <population>
         <size>18000000</size>
         <growth>10</growth>
    </population>
    <updated-at>10/01/2010</updated-at>
    <link rel="next_largest" href="http://localhost:3000/cities/18.xml" />
</city>

Obtendo o recurso:

dynamic city = Restfulie.At(“http://localhost:3000/cities/17.xml”).Get();

Acessando o atributo “update-at”:

  Console.WriteLine(
     string.format(“A data de atualização é {0}”,city.Update_At));
  Console.WriteLine(
     string.format(“População {0}”, city.Population.size));

Note que em na vesão C#, não acessamos o atributo update-at com caracter “-”, este é substituído por “_”. Então quando for necessário acessar um atributo ou método que utilize o “-”, substituída por “_”.
Com as novas capacidades dinâmicas do C# 4.0, conseguimos atingir um resultado bem próximo ao que é possível na versão ruby.
Aqui segue um comparativo básico:

Em Ruby:

  pedido = Restfulie.at(“http://restfulie-test.heroku.com/orders/14”).get
  puts pedido.customer-name
  pedido.cancel

Em C#

  pedido = Restfulie.At(“http://restfulie-test.heroku.com/orders/14.xml”).Get();
  Console.WriteLine(pedido.customer_name);
  pedido.Cancel();

Por enquanto só temos a versão do client em C#. Ainda falta uma série de features a serem implementadas. No site do projeto, tem uma lista de coisas que necessitam de ser feitas no cliente
para que ele fique tão maduro quanto as versões em ruby ou Java. Vamos continuar trabalhando no cliente para isso.

Se você está interessado em ajudar neste projeto, deixe um comentário ou mande um e-mail para nós.

Para saber mais:

http://github.com/caelum/restfulie-csharp
http://restfulie.caelumobjects.com/

Para saber mais sobre as idéias por trás do Restfulie, segue o link do artigo na infoq.
http://www.infoq.com/articles/webber-rest-workflow

Até a Próxima
Luiz Costa
Sérgio Júnior.