Algum humor e C++ Design Patterns (parte 2)

Continuamos a discussão a respeito de Singletons, iniciada na primeira parte desse artigo até chegarmos à Injeção de Dependência. As coisas agora se tornam profundamente C++. Transformamos os Singletons em contêineres, para torná-los efetivamente reutilizáveis e discutimos a teoria que existe por trás dos Templates do C++ e de como a metaprogramação é feita nessa linguagem.

[ Hits: 29.890 ]

Por: Paulo Silva Filho em 25/10/2010 | Blog: http://psfdeveloper.blogspot.com


Erros na Implementação de Typleton?



Apresentei a vocês uma implementação de Singleton que eu chamei de Typleton. Eu também lhes falei que Typleton possui um erro muito sutil que impede que essa classe seja um verdadeiro Singleton. Uma vez que precisamos de um verdadeiro Singleton para implementar a Injeção de Dependência, precisamos entender tal erro e resolvê-lo.

Programadores C++ experientes podem perceber o erro em Typleton logo à primeira vista (veja o código no post anterior). Mas nem todo mundo consegue. Então precisamos ver o erro em tempo de execução. Veja o código abaixo:

Figura 2
Vamos usar o código apresentado na figura 2 para examinar melhor Typleton. Como você pode ver, na primeira linha, incluímos o arquivo de cabeçalho iostream. Sem ele, não podemos apresentar uma saída de dados para o programa. E um programa de testes sem saída de dados é como um carro sem rodas: inútil. Na segunda linha nós incluímos o Typleton.h, que nós definimos na página anterior desse artigo. Na quarta linha, importamos o namespace padrão do Standard C++, std, para evitar nomes qualificados completos de variáveis, então, começamos a função principal. A função principal é tão simples quanto um jogo-da-velha. Simplesmente instanciamos o template Typleton várias vezes chamando pela sua função access e mostrando o endereço de memória do ponteiro retornado.

Quando compilamos e rodamos o programa podemos ver uma saída similar à mostrada na Figura 3, abaixo:

Figura 3
Na figura 3, acima, eu fui cuidadoso o suficiente para mascarar algumas informações pessoais que aparecem no prompt do shell do meu computador. De outra forma, algumas pessoas mal intencionadas poderiam me encontrar e me matar - para dizer que estou apenas tentando não ser paranóico.

Como pode ser visto na Figura 3, as primeiras linhas, antes da chamada a $ ./Typleton, mostram informações de compilação do programa. Typleton pertence a um projeto maior, que eu compilo usando CMake. Meu objetivo é explicar esse projeto inteiro nestes tutoriais de padrões de programação C++ - então você pode esperar por um monte de artigos, ainda.

Depois da chamada ao programa Typleton, nós vemos a sua saída de dados. Então, finalmente, podemos ver o bug: Quando instanciamos o template Typleton com um tipo específico, no caso acima int, ele se comporta como um Singleton, obtemos dele apenas um ponteiro para o objeto armazenado no endereço 1048944.

Mas se instanciamos Typleton novamente, com outro tipo (double, como mostrado na Figura 2), nós obtemos outra instância de Typleton, o objeto armazenado no endereço 1048912! Se você se lembra do que discutimos sobre templates C++ no post anterior, então sabemos que cada instância de um template é uma classe completamente nova para o compilador. Então, no caso de Typleton, essa classe template é, de fato, um Singleton para cada tipo que ela é instanciada.

Mas sendo um template ou não, um Singleton precisa ser instanciado uma vez, e apenas uma única vez, no programa inteiro. Portanto, Typleton não é um Singleton de verdade. Ele se comporta como um Singleton, para cada tipo com o qual o instanciamos, mas a classe, como um todo, não é um Singleton, no final das contas. Uma vez que eu achei o comportamente dessa classe bastante interessante e, de certa forma, útil, mantive-a na minha biblioteca, mas me lembrando de que ela não é um verdadeiro Singleton.

Como transformar Typleton em um verdadeiro Singleton? A resposta é uma nova classe que eu chamei de Templeton. Mas isso é assunto apenas para a próxima página.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Qual é essa dos Templates, no final das contas?
   3. Uma reimplementação muito mais sofisticada do Singleton
   4. Erros na Implementação de Typleton?
   5. De Typleton para Templeton
   6. A implementação de Templeton
   7. Injeções de Dependência em Singletons
Outros artigos deste autor

Algum humor e C++ Design Patterns (parte 1)

Leitura recomendada

Desenvolvendo para microcontroladores em GNU/Linux

Tutorial OpenGL v3.0

Compilando o Mono 2.2 no Ubuntu 8.10

Android NDK: Desmistificando o acesso a códigos nativos em C

Compilando Templates C++

  
Comentários
[1] Comentário enviado por julio_hoffimann em 25/10/2010 - 23:36h

Oi Paulo,

Estou impressionado com a sua destreza no assunto! Há tempos que não aprendia coisas tão interessantes assim em POO. O artigo está incrível, conceitos de alto nível explicados de uma forma simples, sem deixar de ser filosófica.

O Templeton foi algo esplendoroso, quase cai da cadeira quando você o manifestou. Com esta série, começo a ver que metaprogramação vale muito a pena e que apesar de ser um investimento árduo, não hesitarei em aprendê-la.

Obrigado por compartilhar tanto conhecimento, desejo sucesso e boa sorte com a Featherns.

Abraço!

P.S.: Quando li no agregador de feeds: Design Patterns (parte 2), parei tudo que estava fazendo para prestigiar o artigo. :-)

[2] Comentário enviado por psfdeveloper em 26/10/2010 - 01:56h

Caro Julio,

eu fico muito feliz com tal manifestação de apreço... Eu vi que eu esqueci algumas partes do texto em inglês, mas o pessoal do Viva o Linux não tirou. Não sei se foi intencionalmente, mas não vou reclamar.

Metaprogramação é um dos tópicos mais importantes e interessantes da programação como um todo. Quase todas as linguagens possuem capacidades de metaprogramação. Algumas surpreendentemente poderosas, ao ponto de você poder quase que alterar a linguagem inteira (como o Lisp, com suas "macros" - vale a pena dar uma olhada, mesmo que seja como uma referência teórica - recomendo o Racket - http://racket-lang.org/ - que no Debian/Ubuntu pode ser obtido através do pacote plt-scheme), alterar comportamento de objetos e de seus derivados em tempo real (como em Javascript - na verdade uma capacidade de Javascript que só vi em Javascript - talvez na sua linguagem mãe, o Self), ou outras fortemente flexíveis por serem totalmente em tempo de execução - como o Python ou o Perl, em maior grau. O Java possui uma abordagem mista para a metaprogramação (com os Generics), que envolve a necessidade de Reflexion, com aspectos estáticos e dinâmicos.

Mas a linguagem que colocou a Metaprogramação na ordem do dia realmente foi C++, que foi duramente criticada por anos a fio justamente por causa do excesso de poder dado a essa capacidade, pelos templates e em momento de compilação. Quando ficou claro o poder da Metaprogramação por templates, diversas linguagens começaram a copiá-la.

Metaprogramação é um assunto árduo, cuja teoria é mais difícil que a codificação em si, mas dou toda força. Vai fundo.

E muitíssimo obrigado por prestigiar meu trabalho. Não tenho o que dizer.

Abraços.

[3] Comentário enviado por edgardiniz em 27/10/2010 - 18:36h

Ainda não li essa segunda parte, apressei o comentário para não esquecer mais tarde.

Com relação aos códigos, você pode utilizar algo como o pastebin.com, que permite fazer o embed dos códigos, e conta com tudo o que você precisa, sem a necessidade de usar imagens com o código e fornece-lo no final.

A não ser que o VOL não permita embedding nos artigos, não sei...

Mas cara, você está de parabéns, estou aprendendo muito com seus artigos.

Continue com o trabalho excelente.

[4] Comentário enviado por psfdeveloper em 27/10/2010 - 20:08h

Caro edgar,

o VOL não permite embedding de tags html no código, só com muitas restrições. E todo código fonte é posto disponível para download na última página do artigo.

Abraços.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts