Abstraindo Constantes e Tipos

No universo de Orientação a Objetos, costuma-se abtrair objetos do mundo real em classes (como exemplos: Pessoa, Jogador, Cliente, Fornecedor, Pedido de Compra, Casa, Tabuleiro, Peça, etc) . Estas são representadas em O.O. pelas características (atributos) de sua abstração interessantes para a aplicação e pelas ações (métodos) passíveis de serem realizadas na mesma (exemplos referentes as classes citadas: Andar, Pular, PagarConta, EntregarProduto, FinalizarPedido, AlterarTelhado, VirarTabuleiro, IrParaCasa ).

Quão bem cada classe irá representar objetos do mundo real depende da granularidade desejada no processo de modelagem. Quanto maior a granularidade, mais detalhes a sua classe irá exprimir sobre o objeto real. Esta decisão impacta fortemente uma série de fatores relacionados a qualidade de software:

• Efetividade da aplicação (o programa pode ficar muito sujo caso o nível de detalhamento seja inferior ao exigido pela aplicação.);
• Manutenibilidade do Código (detalhes excessivos e desnecessários surgem com uma granularidade muito alta);
• Flexibilidade da Aplicação (novas requisitos podem requerer um nível maior de detalhamento, a granularidade utilizada suportaria facilmente que tipo de mudanças no seu código?);
• Custo (quanto mais “reais” forem as classes, mais código, mais tempo, mais $$$ gasto… porém quanto maior granularidade, maiores as chances de reusabilidade do código e assim, menos código, menos tempo, menos $$$ gasto).

Percebe-se que esta não é uma decisão fácil e este é na minha visão um dos motivos da abominação do modelo em cascata para o processo de desenvolvimento de software.

Imagine agora que muitas aplicações requeram uma abstração de objetos não tão (ou nada) reais. Quais atributos e métodos você imagina que uma classe “GerenciadorDeOrdens” ou “AutomatizadosDePedidos” deve possuir? Padrões de Projeto geralmente trabalham com classes que não representam coisas tão palpáveis.

Por falar em padrões, um dos mais antigos e difundidos consiste no uso de constantes ao invés de literais (o famoso “hard code”) no código. Inegável que esta simples prática  melhora a leitura e manuteção de um programa.

Indo nessa linha, como abstrair constantes em O.O.? Deixá-las privadas nas classes que as utilizarão? E se a granularidade mudar? E se mais de uma classe necessitar o uso da mesma constante?

Eureca!!! Melhor deixar as constantes isoladas publicamente em uma classe (ou até uma interface)! Que tal acessá-la estaticamente? As classes que necessitarem constantes bastam acessar esse ponto único de acesso. Essa dica vale também para abtrair declaração de tipos. Vejam só um simples exemplo:

Z_TYPES_CONSTANTS_IF.TXT

Este report  possui uma calculadora que realiza as operações básicas sobre dois números. Caso não seja fornecida a operação a ser realizada, todas as possíveis operações são executadas. Em todos os métodos de operações matemáticas, os números e o operador utilizados são guardados em atributos da classe 'lcl_calculator' para que se guarde a última ação executada. No final, os resultados impressos na forma de comandos 'write'.  Os comentários estão propositalmente na língua do tio San.
Notem que no exemplo foram utilizadas interfaces para a abstração de tipos e constantes ao invés de classes. Na sua opinião, quais os prós e contras dessas duas abordagens? Quais as suas semelhanças?
Essa discussão começou em uma thread criada por mim na SDN (clique aqui para acessá-la). A discussão se tornou  super interessante e lá é possível saber as opiniões de muita gente boa sobre este assunto.
Espero que esta dica lhes seja útil para seus trabalhos e estudos.