.NET, Boas Práticas, Técnicas

String VS StringBuilder – O Coiote não pega o Papa Léguas!

O título desse post remete a dois personagens bem conhecidos de todos (principalmente das crianças) em que um deles sempre tenta capturar o outro, porém esse último é muito mais veloz e raramente se dá mal. A ideia por trás dessa analogia é que algumas vezes tentamos utilizar tipos de dados com limitações de desempenho em nossos códigos e então saímos fazendo mil coisas (“gambiarras”) para tentar se aproximar do melhor desempenho possível, nem preciso comentar o resultado final. Esse fato no leva ao problema de atualização de conhecimento, pesquisas, estudos sobre as novidades de uma linguagem e/ou uma ferramenta. Aquela famosa frase “Para quem só conhece o martelo como ferramenta, parafuso é prego” cabe perfeitamente aqui.
Quando precisamos trabalhar com strings, o primeiro tipo que vem a mente é o tipo String ou string (essa última é apenas um apelido). Legal, esse é o tipo mais conhecido, e naturalmente, mais usado. Acontece que um objeto do tipo String é imutável, o que isso significa? Significa que uma vez atribuído um valor a um objeto desse tipo, esse valor jamais mudará, isso mesmo, jamais mudará. Mas então como eu consigo fazer concatenações e o novo valor é atribuído ao objeto? O que ocorre por baixo dos panos é algo que talvez você nunca imaginasse, a cada nova atribuição de valor a um objeto String, é criado um novo objeto semelhante que agora contém o valor antigo mais o valor atual. Isso mesmo, um novo objeto é criado e isso é transparente aos desenvolvedores. Você simplesmente solicita o valor do objeto e lá está ele.
No momento em que um novo objeto é criado, o objeto antigo continua na memória heap a disposição do garbage collector. A figura 1 mostra esse cenário, podemos ver que ao final das concatenações sucessivas temos um único objeto que iremos trabalhar e mais quatro objetos aguardando para serem eliminados da memória.

StringVSStringBuilderFigura 1

A cada nova iteração criamos um novo objeto e descartamos o antigo, isso causa um overhead imenso nas aplicações e um péssimo aproveitamento da memória do computador. Ma então o que devemos fazer quando precisarmos utilizar strings em iterações? A solução presente no .NET chama-se StringBuilder. Essa classe foi especialmente desenhada para trabalhar com strings dinâmicas, strings em que o valor muda constantemente e garante uma performance excelente quando recebe grande quantidade de dados. Os métodos disponíveis para trabalhar com StringBuilder fazem uma referência a mesma instância e não a uma nova como no caso da String. Vamos ver na prática como isso funciona. A figura 2 mostra dois métodos, o primeiro faz um loop de 20000 iterações utilizando um objeto StringBuilder e ao final exibe em milissegundos o tempo gasto. O segundo método faz a mesma coisa porém utilizando um objeto String.

ExemploCodigo

Figura 2

ExemploStringBuilder_2

Figura 3

Ao compararmos os resultados da figura 3, podemos concluir a enorme diferença no tempo de execução. Quando chamamos o método que utiliza String, gastamos um tempo de 2637 milissegundos e o mesmo loop utilizando StringBuilder consumiu apenas 10 milissegundos.
Então o tipo de dados String é um tipo ruim de trabalhar? A resposta é que String não é um tipo de dados ruim para trabalhar, porém ela atende exatamente aquilo que ela se propôs a atender, trabalhar com strings estáticas ou com poucas mudanças.

Abraços!

Padrão
.NET, Banco de Dados, Boas Práticas

LocalDb – Uma alternativa simples e rápida

Performance é um item crucial no dia a dia dos programadores. Queremos agilidade em todas as tarefas do dia a dia. Mas muitas vezes precisamos usar ferramentas que não seriam necessárias se tivéssemos alguma alternativa melhor. Na grande maioria dos casos podemos dizer que “matamos mosquito com bazuca”, ou seja temos uma ferramenta cheia de recursos e acabamnos por utilizar uma funcionalidade bem específica (e usamos sempre a mesma funcionalidade) da ferramenta.

O SQL Server é um banco de dados poderoso que vem acompanhado de uma enorme variedade de recursos para um bom gerenciamento dos dados. Na grande maioria das vezes instalamos o SQL Server apenas para ler e gravar dados, ou seja um simples repositório de dados. Só que isso tem um preço, estamos desperdiçando ciclos de CPU e memória com ferramentas que jamais usaremos.

Como uma alternativa a esse cenário a Microsoft disponibilizou uma feature do SQL Server Chamada LocalDb.

Mas o que é o LocalDb?

O Local Db é uma versão simplificada (nem por isso desprovida dos recursos principais) do Sql Server Express, voltada para os desenvolvedores afim de evitar a instalação desnecessária  de uma edição completa do SQL Server.

Vantagens:

  • Instalação rápida e simples. Versão 32 bits tem 28 MB e a versão 64 bits 33 MB;
  • Não necessita configuração e administração;
  • Suporta procedures, triggers, tipos geométricos e geográficos, e o memso suporte a T-SQL Language;
  • Reduz o consumo de memória e CPU, pois só é iniciado quando necessário e também é desligado automaticamente se deixar de ser utilizado por um tempo;
  • Não precisa de instância adicional (como o Express);
  • Instalação única para todos os usuários do computador;
  • Suporta XML,BLOB, LINQ;
  • Sem limite de conexões.

Requisitos:

  • Privilégios Administrativos para instalação;
  • 140 MB de espaço disponível;
  • .Net 4.0 (para atualizar para 4.02).

Limitações:

  • Não roda em Windows XP, Server 2003 e 2000;
  • Uma instalação de 32 bits não roda em Windows 64 bits;
  • Visual Studio 2010 RTM não suporta LocalDb;
  • Não roda em dispositivos móveis;
  • Limite do tamanho do banco em 10 GB;
  • Utiliza apenas uma CPU;

 

Bom, temos então uma opção ao desperdício de recursos quando usamos o SQL Server da maneira mais básica. Eu particularmente prefiro essa versão instalada no meu note, do que deixar diversos serviços rodando de maneira desenecessária e deixando mais tudo mais lento.

O LocalDb pode ser baixado nesse link.

Links e Referências:

http://msdn.microsoft.com/pt-br/library/hh510202.aspx

http://www.sqlcoffee.com/SQLServer2012_0004.htm

http://blogs.msdn.com/b/jerrynixon/archive/2012/02/26/sql-express-v-localdb-v-sql-compact-edition.aspx

http://blog.lambda3.com.br/2013/03/restore-com-localdb/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Lambda3Blog+%28Blog+Lambda3%29

Abraço!

Padrão
Boas Práticas, Fundamentos, Técnicas

Design Patterns – Singleton

Olá Pessoal,

No mundo da O.O. uma das  práticas que podemos aplicar em diversos cenários são os Design patterns (ou Padrões de Projeto), que por sinal são modos de resolver problemas recorrentes e que garantem boa reutilização e também expressam de uma forma elegante a resolução de um determinado problema.

Os Design Patterns são classificados em:

  • Padrões de Criação;
  • Padrões  de Estruturas e
  • Padrões de Comportamento.

Cada uma dessas classificações acima englobam diversos tipos de padrões. Nesse post abordaremos o Design Patterns chamado Singleton. Esse Pattern é caracterizado por permitir apenas uma instância de um objeto no sistema e fornecer um ponto de acesso a essa instância, sendo caracterizado como um padrão de criação.

Existem contextos em que poderá haver a necessidade de ter esse tipo de implementação. Por exemplo com classes que possuem dados sobre o sistema, sobre um determinado dispositivo. Imagine que você esta trabalhando em uma aplicação mobile e precisa capturar algum dado do aparelho, ou atualizar determinada informação. Outro exemplo seria configurações de um aplicativo que poderiam ser solicitadas em determinados momentos da execução. Diversos são os cenários que podemos aplicar essa técnica.

O padrão Singleton também é alvo de várias discussões, alguns acham que não há necessidade de utilizar dessa forma, outros preferem combinar padrão Factory, pois poderá limitar a herança e/ou polimorfismo. Enfim, essa é uma discussão para outro momento.

Para transformar uma classe em Singleton existem 3 modificações a serem feitas na classe.

1 – Criar uma instância privada e estática dessa classe;

2 – Criar um método que seja o ponto de acesso ao único objeto criado e

3 – Tornar o construtor padrão privado.

Abaixo temos uma classe chamada Dispositivo bem simples, vamos transformá-la num Singleton. A classe possui dois atributos (Marca e Modelo) e dois métodos chamados Ligar e Desligar além da sobrecarga do método ToString Conforme figura 1.

Singleton1Figura 1 – Classe Comum de Um Dispositivo

Com a nossa classe comum, vamos fazer as três alterações citadas acima para transformá-la num Singleton. As alterações podem ser acompanhadas na figura 2.

Singleton2

Figura 2 – Classe com as alterações necessárias para atender o padrão Singleton.

A partir desse momento, a forma de utilização dessa classe deixa de ser como já conhecemos, não podemos mais instanciar um objeto dessa classe usando o operador new, isso é feito internamente pelo método getInstance que passa a ser o nosso ponto de acesso ao objeto da classe Dispositivo. Na figura 3 podemos ver como deverá ser utilizada.

Singleton3Figura 3 – Exemplo de uso

Essa é a forma que deverá ser utilizada. O método getInstance, verifica se há alguma instância já criada, caso não haja, será criada uma nova instância senão, ele retornará a instância já existente. A Figura 4 mostra o exemplo em funcionamento.

Singleton4

Figura 4 – Exemplo em execução

Bom, essa é uma forma de tratar um tipo de situação num determinado contexto, porém isso exige cuidado na aplicação ou seja, quando aprendemos sobre Design Patterns, costumamos contrair uma doença chamada “Patternite” onde queremos aplicar sempre, seja qual for o pattern. Porém o ideal é deixar que a plicação “peça” o padrão mais adequado, o desenvolvedor perceberá que aquela situação será bem tratada se for aplicado o pattern X.

Quanto ao Singleton, existe um detalhe que será comentado num próximo post, ele não é thread safe, ou seja se mais de uma thread solicitar esse objeto, teremos problemas, e existem formas de contornar essa situação que serão vistas em breve!

Abraço!

Padrão