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.
Parte 3: Uma reimplementação muito mais sofisticada do Singleton
Agora que nós conhecemos o suficiente a respeito de Templates C++, podemos reescrever a classe Singleton de forma a habilitá-la a receber qualquer tipo de valor. Nós iremos transformar o nosso Singleton em um contêiner.
Minha primeira proposta de reimplementação está apresentada na figura 1:
Figura 1
O código acima é uma figura porque, a partir de agora, os programas de exemplo se tornarão mais e mais complexos e precisarei de indentação, highlighting e numeração de linha adequados. No fim dos posts, eu apresentarei versões em texto dos exemplos, adequados para copiar e colar.
A implementação de singleton, acima, é quase igual à apresentada na parte anterior desse artigo; mas, agora, ela pode ser parametrizada com um tipo, de forma que não precisamos mais de herança, nem de reimplementação da função access(), para usarmos esse singleton em trabalhos reais.
No entanto, essa implementação tem um erro muito, muito sutil. Eu dei a essa classe o nome de Typleton devido a esse erro, e nós vamos ver por quê. Essa classe, no final das contas, não é realmente um Singleton.
Antes de falarmos a respeito do erro no fragmento de código acima, leia a definição dessa classe cuidadosamente. Algumas pessoas acham a sintaxe de Templates do C++ apavorante. E ela pode se tornar ainda pior, mas eu evitarei códigos ilegíveis. O erro acima é um erro lógico, localizado na definição da função access, na linha 4 da figura acima. Estude esse código um pouco mais. Na próxima página nós trabalharemos em cima do erro apresentado nesse programa.
Minha primeira proposta de reimplementação está apresentada na figura 1:
Figura 1
A implementação de singleton, acima, é quase igual à apresentada na parte anterior desse artigo; mas, agora, ela pode ser parametrizada com um tipo, de forma que não precisamos mais de herança, nem de reimplementação da função access(), para usarmos esse singleton em trabalhos reais.
No entanto, essa implementação tem um erro muito, muito sutil. Eu dei a essa classe o nome de Typleton devido a esse erro, e nós vamos ver por quê. Essa classe, no final das contas, não é realmente um Singleton.
Antes de falarmos a respeito do erro no fragmento de código acima, leia a definição dessa classe cuidadosamente. Algumas pessoas acham a sintaxe de Templates do C++ apavorante. E ela pode se tornar ainda pior, mas eu evitarei códigos ilegíveis. O erro acima é um erro lógico, localizado na definição da função access, na linha 4 da figura acima. Estude esse código um pouco mais. Na próxima página nós trabalharemos em cima do erro apresentado nesse programa.
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. :-)