Duvida - Tabelas auxiliares

Programação Arquitetura
#1

Imagine que voce tem um sistema de contas a pagar/receber ou qualquer outra coisa onde se tenha

1)uma tabela com uma coluna “Modo de Pagamento” com um código para o meio usado para realizar o pagamento
2) uma tabela “Modos de Pagamento” com as colunas Id, Sigla e Descrição como abaixo:

Id      | Sigla  |  Descricao
  1     |   CC   |  Cartão de Credito
  2     |   DN   |  Dinheiro
  3     |   CH   |  Cheque
  4     |   BO   |  Barras de Ouro

Imaginemos que num determinado ponto do sistema, é preciso tomar uma decisão baseada no módo de pagamento. Essa decisão teria o if() abaixo:

if(cliente.getModoPgto() == 1) // decisão A else if(cliente.getModoPgto() == 2) // decisao B else if(cliente.getModoPgto() == 3) // decisao C

Agora vem minha dúvida:

Os ‘puristas’ dizem que não se deve chumbar ids no código, porque se um dia o id mudar, será necessário uma manutenção no código. Outros ‘puristas’ me disseram que código não se muda, se houver necessidade, que se mude a descrição ou crie outro registro na base.

Bom buscar por sigla não acho uma boa, pq a sigla tb pode mudar. Alias considero mais fácil alterar-se uma sigla que um código.

Buscar por descrição, nem pensar. Um engano, trocando-se ‘C’ por ‘Ç’ já ferra tudo, sem contar que operações de String são as coisas mais lentas que existem em qualquer linguagem.

O que se fazer? Chumba-se o codigo e assume-se o risco de uma futura manutenção? Adivinhação?

Penso que isso está muito relacionado à politica de desenvolvimento/manutenção de uma empresa ou mesmo relacionado coma maluquice do chefe do setor de desenvolvimento.

E ai, como é na empresa que voces trabalham?

#2

prefiro usar um enum, ai faço no if mesmo

#3

[quote=zoren]prefiro usar um enum, ai faço no if mesmo

[/quote]

Entendo, mas no meu caso, o sistema precisa dessa tabela. Replicá-la num enum não seria uma boa solução.

#4

[quote=Manitou][quote=zoren]prefiro usar um enum, ai faço no if mesmo

[/quote]

Entendo, mas no meu caso, o sistema precisa dessa tabela. Replicá-la num enum não seria uma boa solução.[/quote]

E porquê não? Você pode ter um enum para dar mais significado para o seu código, é melhor do que espalhar 1, 2, 3 e 4. Caso você crie um novo registro no tabela, altere o enum.

Agora outra idéia seria a criação de cinco classes: ModosPagamento, Dinheiro estende ModosPagamento, Cheque estende ModosPagamento, etc. E instanciar a classe correta, dependedo do tipo. Coloque as decisões de cada tipo em cada classe. Mas, veja que se você criar um novo registro na tabela, vai ter que criar uma nova classe.

Bom, o que eu quero dizer é que, na minha opinião, não existe uma forma de criar uma lógica baseada em configurações de uma tabela (que pode mudar), sem alterar o código ou deixa-lo tão complexo que seja dificil de manter. Eu prefiro a primeira opção.

#5

Não acho uma boa prática. Ja peguei um sistema assim pra dar manutenção. Eu incluia dados novos na tabela e o comportamento do sistema não se alterava. Foi assim até que, depois de vários debugs, descobri que havia um enum com as mesmas coisas que havia na tabela.

Na minha opinião, deve haver um local centralizado para esse tipo de informação.

Sim, concordo com vc. Eu sou da opiniçao que id nao se muda e se houver alguma alteração, deve-se arcar com os custos da manutenção.

#6