Classe customizada para quantia monetária (valor monetário) em vez de BigDecimal

5

No StackOverflow, encontrei vários avisos para ficar com BigDecimal em Java, em vez de reinventar a roda.

Apesar disso, decidi criar minha classe personalizada, e gostaria de perguntar se isso era uma boa idéia e os prós ou contras sobre meu design em comparação com BigDecimal. As razões para escolher a implementação personalizada e característica do meu design são:

  • não há construtores double / float como em BigDecimal (risco de engano) - long internamente com 8 casas decimais - essa restrição é de min / max a ~ 10 bilhões, mas o sistema é segmentado por criptografia os valores são pequenos.
  • nenhuma diferença em "0,0" e "0,00" como BigDecimal tem
  • compatibilidade simples com SQL pela coluna BIGINT
  • conexão difícil a objeto / código de moeda - não é possível criar quantia sem moeda e também não pode fazer artrimética / comparação de dois valores em moedas diferentes
  • Controle de criação de valores possíveis para não transbordar longos (-10 a 10 bilhões)
  • proteção contra estouro interno nos cálculos

Você acha que essas razões são tão boas para escolher implementação de custem em vez de BigDecimal?

Para minimizar os riscos, abordo muitas situações por teste de unidade e também uso BigDecimal para conversão inicial de string:

BigDecimal decimal = new BigDecimal(value);
... check MIN/MAX allowed values ...
BigDecimal multiplied = decimal.multiply(new BigDecimal(String.valueOf(DECIMAL_DIVIDER)));
long internalResult = multiplied.toBigInteger().longValue();
return new Amount(internalResult, cryptoCurrency.getInternalCode());
    
por Piotr Müller 09.02.2014 / 18:28
fonte

1 resposta

3

Seus motivos para criar uma classe personalizada são perfeitamente válidos. Se o seu sistema estava trabalhando apenas com uma única moeda, o argumento para criar uma classe personalizada seria muito mais fraco. Mas com várias moedas, acho que uma classe personalizada é quase uma obrigação.

Observe que sua classe personalizada poderia usar um BigDecimal internamente para manter o valor, se fosse uma boa correspondência para o que você realmente precisa fazer. Se um long corresponder melhor ao seu modelo, vá em frente com isso.

    
por 09.02.2014 / 20:39
fonte