Alguém faz idéia de que existe boas práticas para trabalhar com a estrutura DateTime?

Quando utilizamos algum codificador que não consegue codificar ou decodificar algum caracter, ele coloca um ponto de interrogação “?” para indicar que o codificador corrente não é capaz de “traduzí-lo”.

A classe Encoding fornece dois métodos chamados GetEncoder e GetDecoder, que retornam os objetos responsáveis por codificar e decodificar as strings, respectivamente. Ambas as classes possuem uma propriedade chamada FallBack. Essa propriedade recebe um objeto do tipo EncoderFallback ou DecoderFallback que representam uma ação que será executada quando um caracter ou um byte não puder ser convertido.

As classes EncoderFallback e DecoderFallback são utilizadas na codificação e decodificação, respectivamente. A primeira delas é a classe base para todos os fallbacks de codificação e, a segunda, a classe base para todos os fallbacks de decodificação. Basicamente, para ambos os casos, temos dois tipos de fallbacks: 

• Fallbacks de Substituição: Quando um caracter ou byte não consegue ser “traduzido”, ele substitui o mesmo por um caracter que podemos determinar. Por padrão, o ponto de interrogação “?” é utilizado.
  • EncoderReplacementFallback: Fallback que é invocado quando um caracter que puder ser convertido em uma seqüencia de bytes, convertendo o caracter para um valor pré-definido.
  • DecoderReplacementFallback: Fallback que é invocado quando uma seqüencia de bytes não puder ser convertida em um caracter, convertendo o byte para um valor pré-definido.
• Fallbacks de Excessões: Quando um caracter ou byte não consegue ser “traduzido”, ele atira uma excessão do tipo EncoderFallbackException ou DecoderFallbackException, dependendo da operação que estamos tentando realizar.
  • EncoderExceptionFallback: Fallback que é invocado quando um caracter que puder ser convertido em uma seqüencia de bytes, atirando uma excessão do tipo EncoderFallbackException.
  • DecoderExceptionFallback: Fallback que é invocado quando uma seqüencia de bytes não puder ser convertida em um caracter, atirando uma excessão do tipo DecoderFallbackException.

O código abaixo exemplifica a utilização de um dos fallbacks acima:

using System.Text;
//….
Encoder encoder = Encoding.ASCII.GetEncoder();
encoder.Fallback = new EncoderReplacementFallback(“*”);
char[] chars = “ãBC”.ToCharArray();
Byte[] buffer = new byte[chars.Length];
encoder.GetBytes(chars, 0, chars.Length, buffer, 0, true);
Console.WriteLine(Encoding.ASCII.GetString(buffer));

O resultado ao executar esse código é: *BC. O “ã” é substituído pelo “*” porque esse caracter não está contemplado no padrão ASCII e, conseqüentemente, não consegue ser “traduzido”. A utilização dos fallbacks são muito úteis quando voce quer customizar a leitura ou gravação de streams. A utilização de fallbacks de excessões são as vezes mais utilizadas quando a leitura dos caracteres devem ser precisa.

Na empresa onde trabalho, desenvolvemos alguns objetos que são muito custosos durante a sua criação. São checagens, a nível de segurança e também a dados dentro de um determinado banco de dados. Quando inciamos a fase de testes, notamos que o construtor e alguns trabalhos que fazemos durante os métodos e propriedades estava levando muito tempo para serem executados e, na maioria das vezes, eles fazem sempre as mesmas validações.

Para contornar a situação, optamos por implementar uma espécie de pool de objetos. Depois de muito ler e efetuarmos testes, chegamos a uma forma que, até então, parece-me trabalhar bem. Essa técnica trata-se da criação de um membro privado estático, do tipo Stack<T> que será o responsável por armazenar os objetos dentro do pool. Logo depois da criação, via construtor, o objeto é automaticamente adicionado a Stack. Como não poderia deixar de ser, mais dois métodos estáticos forem criados: um para extrair o objeto do pool e outro para finalizar o pool, caso não precisar mais dele na aplicação. Além disso, optamos também por criar uma propriedade que irá determinar se aquele objeto deve ou não ser armazenado no pool ou se deve ser descartado diretamente.

public class Order
{
    private static Stack<Order> _orderPool = new Stack<Order>();

    public Order()
    {
        _orderPool.Push(this);
    }

    public static Order GetOrderFromPool()
    {
        return _orderPool.Pop();
    }

    public static void ClosePool()
    {
        _orderPool = null;
    }

    protected virtual bool CanBePooled
    {
        get
        {
            return true;
        }
    }

    ~Order()
    {
        if (_orderPool != null && this.CanBePooled)
        {
            GC.ReRegisterForFinalize(this);
            _orderPool.Push(this);
        }
    }
}

O único código que merece um comentário adicional é com relação ao destrutor da classe Order. Dentro dele verificamos se o pool não está nulo (isso quer dizer que a aplicação não precisa mais dele) e, além disso, a propriedade CanBePooled deve estar definida como True, o que indica que o objeto pode ser adicionado ao pool. Se essas condições forem atendidas, chamamos o método ReRegisterForFinalize da classe GC, passando a instancia corrente da classe para que o mesma seja ressucitada e, como podemos notar, a instancia é devolvida para o pool via método Push. Thanks JeffreyR 😉