Archive for the 'C#' Category


Delegates em C# (Ponteiros de Função) 4

Recentemente recordei uma das dificuldades que tive quando entrei no mundo .NET, aliás minha experiência era extremamente limitada se comparada a hoje, apesar de ter muita coisa para estudar.

Pretendo neste post abordar um tópico muito importante do .NET framework que poucas pessoas usam ou desconhecem.

Quem já programou em linguagens como C/C++ isso não deve ser um problema, a menos que tenha feito somente algoritmos básicos de estrutura de dados (pilhas, filas, listas e etc).

Delegates é nada mais nada menos que um ponteiro para função. Ponteiro para muitos é um pesadelo, eu ainda tenho dificuldade quando começo a escrever um programa em C, sempre me esqueço das notações, pois em linguagens de alto nível como Java e C# elas ficam escondidas.

Bom, entenda da seguinte maneira, digamos que você possua uma subrotina/função, se você souber onde ela se encontra em memória é possível invocá-la. Um ponteiro é um endereço para uma região da memória, no caso do delegate é ponteiro para uma subrotina/função.

A questão é que em C# as coisas são tipadas, quando você define um delegate você define um contrato com quem quer “disponibilizar” um rotina ou função.

A sintaxe é a seguinte:

delegate <return_type> MyDelegate(<params>);

Por exemplo:

delegate int Calcula(int a, int b);

Podemos referenciar um função qualquer que aceite dois inteiros e retorne um inteiro como resultado, poderiamos utilizar:

public int Soma(int num1, int num2)
{
    return num1 + num2;
}

Agora definimos que um ponteiro para essa rotina da seguinte forma:

Calcula calc = Soma;

Simples, nâo?

Antigamente para eventos usava-se a seguinte nomenclatura:

Calcula calc = new Calcula(Soma);

Com o C# 2.0 podemos fazer assim:

Calcula calc = delegate(int a, int b)
{
    return a * b;
};

Ou podemos fazer, neste caso estranho:

Calcula calc = delegate
{
    return 2; // magic number detected!
}

O exemplo acima é meramente ilustrativo.

Ok, agora que conhecemos as sintaxes vamos conhecer alguns delegates muito úteis já existentes no C#:

  • Action (C#2)
  • Predicate (C#2)
  • Func (C#3)

Action

Action corresponde a uma ação a ser executada sobre um valor, onde T define o tipo de valor. Se você nâo conhece generics, sugiro que estude um pouco, não é nada complicado, só não entrarei em detalhes por que não é o escopo deste texto.

O action recebe um parametro do tipo T, por exemplo:

Action<string> printText = delegate(string s)
{
    Console.WriteLine(s);
};

Invocando:

printText("Hello World");

Simples não? No caso, podemos alterar o valor de ‘s’, pois ‘s’ é um reference type, ou seja, poderiamos tratar o texto, retirando por exemplo, todas as vírgulas do texto:

Action<string> removeVirgula = delegate(string s)
{
    s.Replace(",", string.Empty);
};

removeVirgula(“Hello, World”); // produz Hello World

Predicate

A predicate is the portion of a clause, excluding the subject, that expresses something about the subject.

Predicate ou predicado corresponde a uma clausula a qual expressa alguma coisa.

Digamos que desejamos saber se um número é par (even):

Predicate<int> even = delegate(int number)
{
    return number % 2 == 0;
};

even(2); // true
even(3); // false

Veja que retornamos um booleano para predicates, pois desejamos saber se o ‘number’ que foi passado a rotina expressa o que meu predicado quer, no caso saber se o número é par.

Func (C#3)

E por último, existente apenas no C# 3.0 o Func. Diferente do Action e Predicate, o Fund possui 5 variações:

Func<TResult>
Func<T, TResult>
Func<T1, T2, TResult>
Func<T1, T2, T3, TResult>
Func<T1, T2, T3, T4, TResult>

Bom, as assinaturas são muito claras e são lidas da seguinte forma: o tipo de retorno e nenhum parâmetro ou o tipo de retorno com 1 a 4 parâmetros.

Acredito que o número de parâmetros são mais que suficientes, se a rotina começar a ter mais que esse número de parâmetros é possível que ela esteja fazendo mais coisas do que precisaria e podendo ser sub-divida em menores rotinas, facilitando tanto a leitura como reuso. Se você ainda assim achar que precisa de mais, bastaria criar uma outra assinatura com N parâmetros.

Ok, você poderia pensar em fazer uma Func que tratasse a string e não retornasse nada por exemplo. Entretanto, esse tipo de retorno não é possível. Se você pretende usar Func<> você deve fato deseja retornar um valor.

Quando lembro de function e subroutine me recordo de um trecho do texto do livro Code Complete 2nd Edition onde diferenciava o uso das duas palavras.

Function: é como definido na matemática, y = f(x), onde f é uma função. Ou seja, a função recebe um parâmetro e retorna um valor por definição.

Subrountine: já sub-rotina corresponde a uma tarefa a ser realizada, e não retorna valor. Se você já programou em Visual Basic deve ter notado a distinção delas.

Bom, voltando. O correto se deseja usar um delegate com retorno void seria Action, porém ele só possui 1 parâmetro. Mas segundo este link me parece que futuramente será extendido para mais parâmetros como o Func.

O uso é praticamente o mesmo como mostrado para predicate e action, sendo um mix de ambos.

Func<int, int, int> sum = (a, b) => a + b;

sum(1, 2) // return 3

Se não tivermos parâmetro algum, podemos usar:

Func<object> CreateObject = () => { return new object(); }

object o = CreateObject();

Observe que as delegates predefinidas como Action, Predicate e Func não precisam ser obrigatóriamente usadas, você pode criar suas próprias assinaturas como foi feito no início deste post, mas se for possível usar as já existentes use, pois é uma linguagem comum para todos os programadores em C#, poderíamos ter um delegate Process<T> igual a Action<T>, se usasse Action, seria muito claro o que pretende-se fazer. Não é uma regra, mas sempre que possível use as já predefinidas.

Bom, o post ficou bem grande, tentei ser o mais detalhado e claro possível. Até um próximo post.

Proxy Pattern: Exemplo e Aplicação 2

Desde meu último post acabei não cumprindo com o que esperava. Como já devo ter mencionado, estou cursando Engenharia da Computação Cooperativo, onde o curso intercala módulo acadêmico e estágio, permitindo tempo integral (desde que não tenha DPs para pagar). Comento sobre isso em outro post, vamos voltar ao assunto.

Depois de realizar meu primeiro laboratório de engenharia de software, não adotar um framework na minha camada de persistência tornou muito trabalhoso sua modelagem e manutenção. Cada operação exigia escrita em código ou stored procedure o que tornava “uma tarefa simples” em trabalhosa, não que demorasse muito, mas depois de muitas linhas de coisas para coisas tão banais o processo ficava um tanto… chato.

Desde então, tenho como objetivo aprender um framework para essa finalidade. Claro, não podia ficar de lado o Hibernate, mas no momento estou curtindo C# e no caso temos o NHibernate. Conversei com um colega do trabalho e ele aparentemente não gostou muito do NHibernate. Não entrei muito em detalhes do por que ele era ruim, mas a comparação era bem direta se comparado com o Hibernate do Java. Portanto, ele costuma usar o ActiveRecord que usa como base o NHibernate.

Mas nas últimas semanas saiu o NHibernate 2.0, apesar de a página não estar atualizada. E concerteza deve ter melhorado em muitos aspectos. Por isso escolhi o NHibernate como estudo. Pretendo falar mais sobre ele em outro post (quando der).

Resumo

O uso do (N)Hibernate é bem direto, use POJO (plain old java object) ou POCO (plain old c# object), onde os objetos contém basicamente get/set. Talvez minha definição esteja um tanto incompleta, então me corrijam se falei absurdos.

No Java todos os métodos por default podem ser overrided, bastando reescrevê-lo em sua classe estendida. Já no C# a coisa fica mais explicita. Por default nenhum método/property pode ser overrided, para tal é necessário acrescentar a keyword “virtual”, e quando realizamos um override a keyword “override”, já veremos um código.

O que quero dizer com isso? Bem, como no Java isso já é default para todos os objetos então só é necessário definir os getters e setters da classe, já para o NHibernate todos os properties devem vir com a keyword virtual, caso contrário a coisa não funciona.

Então me perguntei: por que tenho que colocar todas as properties como ‘virtual’?

Bom, inicialmente achei que o NHibernate deveria simplesmente instanciar um objeto da entidade mapeada e então preencher todos os properties um a um. Mas o (N)Hibernate existe uma funcionalidade chamada de Lazy Load.

O que é Lazy Load?

Serei bem breve, digamos que você tenha um objeto e este possui uma referência para um outro objeto, seria um desperdício recurarmos o estado do objeto referenciado se nem usassémos ele. O que o lazy load faz é carregar este objeto (realizar a query no banco de dados) realmente quando precisamos. Mas como diabos isso ocorre?

A resposta é usando Proxy Pattern.

O que ele faz é atuar como um proxy entre a chamada de um property/método. Uau, entendi nada, o que é proxy?

Eu sempre me perguntava isso. Um proxy é digamos um “passo” intermediário de um fluxo. O exemplo mais comum é em redes de computadores. Digamos que sua máquina acesse a internet diretamente, ou seja, o seu computador e a “nuvem”. Se quisessemos realizar um filtro no neste tráfego, poderíamos utilizar um serviço de proxy que atua entre a nuvem e seu computador, de modo que todas as requisições passem sempre pelo proxy, tratando os dados trafegados e aplicando filtros adequadamente.

Como implementamos um proxy pattern? Veja um exemplo bem simples abaixo:

   1: public class MyClass
   2: {
   3:     public virtual string Message { get; set; }
   4:  
   5:     public virtual void DoSomething()
   6:     {
   7:         Console.WriteLine("Doing something really important.");
   8:     }
   9: }
  10:  
  11: public class MyClassProxed : MyClass
  12: {
  13:     public override string Message
  14:     {
  15:         get
  16:         {
  17:             Console.WriteLine("Proxying on reading...");
  18:             return base.Message;
  19:         }
  20:         set
  21:         {
  22:             Console.WriteLine("Proxying on saving...");
  23:             base.Message = value;
  24:         }
  25:     }
  26:  
  27:     public override void DoSomething()
  28:     {
  29:         Console.WriteLine("Proxying DoSomething() before");
  30:         base.DoSomething();
  31:         Console.WriteLine("Proxying DoSomething() after");
  32:     }
  33: }

O que basicamente fazemos é extender a classe MyClass criando uma MyClassProxed dando override nos métodos e properties. Para testarmos, seria muito simples:

   1: MyClass myClass = new MyClass() {Message = "Hello World!"};
   2:  
   3: Console.WriteLine("Normal behavior");
   4: Console.WriteLine("MyClass.Message = {0}", myClass.Message);
   5: Console.Write("MyClass.DoSomething()");
   6: myClass.DoSomething();
   7:  
   8: Console.WriteLine();
   9:  
  10: Console.WriteLine("Normal behavior plus proxying");
  11: myClass = new MyClassProxed() {Message = "HelloWorld!"};
  12: Console.WriteLine("MyClass.Message = {0}", myClass.Message);
  13: Console.Write("MyClass.DoSomething()");
  14: myClass.DoSomething();

Como a classe MyClassProxed extende a class MyClass basicamente a interface não muda, logo do nosso ponto de vista qual implementação usamos não importa, seja MyClass ou MyClassProxed, para nós o que importa é a interface da property Message e o método DoSomething(). O resultado esperado é algo como:

proxy

Conclusão

Utilizando este pattern é possível realizar o lazy load de forma transparente para o desenvolvedor.

Esse pattern é bem conhecido e pode ser encontrado no livro Design Patterns, Elements of Reusable Object-Oriented Software do GoF (Gang Of Four), que por sinal é uma leitura básica para qualquer desenvolver.

Infelizmente, o conteúdo do livro não é de fácil digestão quando sua experiência como desenvolvedor é pequena, muitos patterns não fazem sentido pois você não consegue comporrender os problemas de implementação que existem.

Espero poder dar continuidade neste tipo de post, até uma próxima vez.

Programando para Office 2007 com C#… que nada, VB.NET! 0

Não você não leu errado, escrevi VB.NET (Visual Basic dot Net), isso mesmo.

Eu nunca pensei que algum dia programaria em VB, já programei com VBScript na primeira versão do ASP (há muitos anos atrás), nem conhecia PHP. Nesta época, eu procurava por uma forma de fazer páginas dinâmicas, que para mim naquela época pensava: “Essas páginas HTML não fazem p@&*# nenhuma?”, então tinha que ver um jeito de resolver isso. Depois migrei para PHP onde gostei mais, por haver servidores públicos abertos (open source a bla-bla-bla), mas essas histórias ficam para outro post.

Bom, já tive de programar com VBA para Excel, cheguei a escrever um post sobre isso, minha experiência não foi boa, apesar de ter concluído tarefa que tinha de fazer.

Mas VBA é coisa do “passado”, a partir do Office 2003 foi incorporado o VSTO (Visual Studio Tools for Office) que permite fazer coisas mais “bacanas”, assim dizendo, através de addins para o Excel (posso estar completamente errado, talvez isso já exista a nos e para mim é coisa nova).

Como a plataforma é .NET, fica a escolha do programador escolher entre C# ou VB. Entretanto para esses tipos de desenvolvimento em particular, acredito que para o pessoal do VB a tarefa seja um tanto mais, prática.

Eu nunca gostei da sintaxe do VB, acho muito poluído, odeio o esquema de declaração de váriaveis:

   1: // VB
   2: Dim texto As String = "texto"
   3: Dim conn As SqlConnection = New SqlConnection(cs)
   4:  
   5: // C#
   6: string texto = "texto";
   7: SqlConnection conn = new SqlConnection(cs);

Argh, coisa feia! Em termos de tamanho não varia muito, mas em clareza e facilidade de leitura prefiro o C#.

Mas vou dizer aqui algum dos motivos do por que VB é melhor que C# para desenvolvimento Office:

  • VBA para VB é parecido (senão igual);
  • Todos as macros de VBA são facilmente portáveis para VB ;
  • Passagem de parâmetros para rotinas “dinâmico”;
  • Properties ou métodos diretos, como: Value e Offset

Até onde eu estou estudando essas foram os grandes motivos de se trabalhar com VB.

   1: // VB
   2: Dim wb As Excel.Workbook = Me.Application.Workbook
   3: Dim ws As Excel.Worksheet = wb.Sheets(1)
   4:  
   5: Dim range As Excel.Range = ws.Range("A1") // posso passar apenas row ou (row, col)
   6:  
   7: // C#
   8: Excel.Workbook wb = this.Application.Workbook;
   9: Excel.Worksheet ws = wb.Sheets[1];
  10:  
  11: Excel.Range range = ws.get_Range("A1", missing); // tenho que preencher todos

Em C#, eu preciso passar todos os campos, ou seja, quando não desejado é preciso passar “missing”. Também não temos um método direto como Range(cell, cell). Temos que usar os métodos, set_Range, get_Offset entre muitos outros.

Outro ponto que é irritante também é em rotinas:

   1: // VB
   2: Dim ws As Excel.Worksheet = ...
   3: ws.Protect("password") // simples e direto
   4: // quero content como false
   5: ws.Protect("password", Content := False) // indolor
   6:  
   7: // C#
   8: Excel.Worksheet ws = ...;
   9: // preciso passar todos os parametros
  10: ws.Protect("password", missing, missing, missing, ..., missing);
  11: // quero content como false
  12: ws.Protect("password", missing, false, missing, missing, ...); // meu deus...

Infelizmente para o pessoal do C# trabalhar com Office fica um tanto irritante.

Por este motivo acho que trabalhar com VB agiliza e facilita as coisas, embora tenha que aprender como é a sintaxe do VB, mas aposto que o ganho será muito maior do que ter que programar em C#.

Extension methods is like a magic! 1

Estou voltando depois de muito tempo sem escrever. Não é difícil notar a dificuldade de se manter um blog. Pensar no que escrever as vezes é fácil, o problema é colocar no papel, ou melhor, na tela.

Ultimamente tenho estudado C#3, que tem o LINQ como o grande ‘boom’ do novo framework. Contudo, uma das coisas que mais me intrigou até o momento é Extension methods.

Acredito que muitos já devem ter usando e/ou criado static classes como classes utilitárias (util) ou auxliares (helpers) por que uma classe não possuia um método de que precisassemos no momento, ou até teria uma outra classe que executa a operação mas acaba gerando um overhead grande por que teria de instanciar um objeto que teria inúmeras operações que talvez não teria utilidade.

Um exemplo em Java é que os tipos Integer, Long e etc, não possui um conversor para bytes proprio da classe como getBytes() da String. Existe duas opções para realizar essa operação, uma delas é usar o BitInteger e a outra seria o DataOutputStream. Mas seria tão mais simples se tivessemos um getBytes() da classe String. Então recorre-se a uma classe auxliar para realizar essa conversão. Algo do tipo:

public class NumberHelper {
public static byte[] intToBytes(int num);
public static byte[] longToBytes(long num);
}

Um pouco feio mas resolve. Agora seria muito melhor ter algo do tipo:

Integer.toBytes(); ou Long.toBytes()

não seria? Então é ai que entra o Extension methods.

No C#3 é possível criarmos uma classe estática que estenda os métodos de uma classe. É muito simples veja:

class Person {
string Name { get; set; }
}

static class PersonUtil {
public static void ChangeName(this Person p, string name) {
p.Name = name;
}
}


var fabio = new Person(“Fabio”);
fabio.ChangeName(“Fábio”);

Viram como é simples? Ok, o exemplo não é muito útil uma vez que o property set do Name é publico, mas estou sem idéia no momento. A idéia esta fresca na cabeça então estou escrevendo um post rápido.

Entretanto existem algumas restrições para isso:

  • A classe que contêm os Extension Methods não podem ser genêricos e internos, e os métodos precisam ser static.
  • O método precisa ter pelo menos um paramêtro onde este (o primeiro) deve ser prefixado com this e não pode ser ref, out ou ponteiro. Ou seja, os demais parâmetros (segundo, terceiro e etc) pode ser genêricos, ref/out/ponteiro

Espero que tenham gostado do post, devo colocar outras coisas a mais sobre C#3 pois estou muito interessado nessas novidades.

Até um próximo post.

Keywords for properties and methods on C# 1

Em linguagens orientadas a objeto temos meios de definir o acesso e uso dos elementos. Segue uma lista de algumas dessas palavras e sua funcionalidade.

  • public: declara que uma propriedade/método possa ser acessado externamente, ou seja, é visível fora do objeto.
  • private: oposto do public, toda propriedade/método só pode ser acessada internamente da classe.
  • protected: semelhante ao private, ou seja, não é visível fora do objeto, mas é compartilhado entre seus derivados transmida hierarquicamente.
  • static: um método/propriedade estática são elementos da classe em si, ou seja, não independem de sua implementação, são compartilhadas por todas e não podem ser alteradas. Em geral são constantes ou métodos que não dependem de parâmetros da classe.

Algumas outras keywords frequentemente usadas:

  • virtual: um método virtual é um método que pode ser sobreposto (override); ou seja, um método non-override não poderá ser sobreposto. Uma forma de lidar com isso seria usar a keyword new method, escondendo o método base na derivada. Por default, no Java todos os métodos são virtuais e, portanto, podem ser sobrepostos. Obs: não aplicável a métodos abstratos e estáticos.
  • override: declara que um método esta sobrepondo um método base – aspecto do polimorfismo – “one interface, multiple methods” (uma interface, múltiplos métodos).
  • abstract: declara uma classe semi-implementada, ou seja, possui método que não puderam ser implementadas genericamente, e portanto, devem ser implementadas por seus derivados.
  • interface: define uma assinatura para um tipo de dado (data type). É uma forma de dizer que todo tipo que implementa uma dada interface terá certos elementos, sempre! É muito semelhante a abstract, a diferença é que num algumas implementações já estão feitas. Outro detalhe relevante é que na herança uma classe pode apenas derivar de uma única classe base mas pode implementar quantas interfaces desejar. Todos os métodos de uma interface são públicos, um tanto óbvio.
  • sealed: impede que uma classe seja herdada. Semelhante ao final no Java.