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:

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.

Fábio Pagoti

Formado em Sistemas de Informação pela Universidade de São Paulo. Comecei no mundo da programação com Java mas logo caí no mundo ABAP. Estagiei na Nestlé por 2 anos e foi lá onde conheci o Furlan. Depois de efetivado fui morar no Canadá por 1 ano onde pude aprender a área de testes em desenvolvimento de software. Hoje sou consultor e instrutor ABAP, amante de projetos Open Source, Wordpress, Data Mining e da esfera SAP. Siga-me no twitter: @fabiopagoti

1 Resultado

  1. julho 15, 2010

    […] This post was mentioned on Twitter by Flávio Furlan, Fábio Pagoti and Fábio Pagoti, Fábio Pagoti. Fábio Pagoti said: RT @furlan: Meu amigo @fabiopagoti escreveu um post lá no @abap101. Confiram! http://migre.me/Xj1u […]