BrazilUtils API

Assuntos Gerais
#421

As mudanças que conversamos para as classes do pacote org.brazilutils.br.uf.ie já foram passadas (commit) para o repositório. Verifiquem!

Modificações além das que já havia postado:
Tirei os System.out.println do código.
Tirei comentários com código antigo.
Mexi na formatação.
Transfomei todas as subclasses de InscricaoEstadual em final (favorecendo segurança e performance).

Dever de casa (Douglas):
Passar código-fonte do Java 5 para Java 1.4. :cry:
Vários TODO - Verificar máscara
Fazer um tutorialzinho sobre as nuances de InscricaoEstadualRO

Testes:
Incluí testes para a validação em cadeia na classe UFInscricaoEstadualTest.
Claro, testar a validação das demais subclasses de IncricaoEstadual (Possível somente no dia-a-dia dos usuários).

O que adorei:
O método genericValidation já era. Classes que usam validação genérica chamam isValid, definida na superclasse InscricaoEstadual.

Douglas, parabéns pelas classes de validação de Inscrição Estadual. Dá pra ver que deu trabalho fazer e, claro, funcionam!

#422

E me posicionem sobre a questão da validação de CPF/CNPJ. Se já tivessem decidido, elas já estariam prontas.

#423

Atualmente existe a classe CpfCnpj que concentra os códigos de validação de uma ou outra coisa. Ao instanciar um objeto dessa classe, este objeto pode ter comportamento de uma ou outra. Pode iniciar como um e transformar-se em outra. Isso, de fato, acontece. Mas se vc quiser, no seu sistema, usar tudo bem separado desde o início pode usar o código como você postou com as classes novas mesmo usando as que já estão lá.Basta usar as classes Cpf e Cnpj seperadamente. Por isso elas existem. Ao declarar e instanciar um Cpf ele sempre será Cpf, idem pro Cnpj. Mas no caso “mutante” deve-se declarar e talvez instanciar um CpfCnpj. Essa possibilidade não é possível na implementação nova. Os flags a mais dentro do algorítimo de validação são um custo baixo pra quem tem o problema da “mutação”. isCpf() e isCnpj() podem, obviamente, ser ignorados se você estiver usando as classes especializadas Cpf e Cnpj, mas no caso de indeterminação eles ajudam bastante.

Acho que pra primeira distribuição deve-se retirar o pacote validation que tá obriganto classes como CpfCnpj, Ie e etc implementar como num framework. Isso tá meio forçado (da minha parte na época) pro usuário da API.

#424

Esse dever de casa não é nada mole. Tem uns enuns pra substiruir. Isso significa que a forma como se usa essa classe muda pelo código. Já passei por isso este ano e não é nada agradável. Porém, atendendo a pedidos, eu refiz as classes UF e TelMask de forma que os pacotes UF (UF e inscrições estaduais) e Telefone estão já compatíveis com 1.4. O mesmo vale pro pacote cpfcnpj. Fica faltando o de endereço que acho que um erro de projeto. O Enum TipoLogradouro não deveria ser uma lista “chapada” em código e sim um arquivo xml acoplado. A lista que tá lá, tá caduca e a normalização tem que ser melhorada antes de ser liberada.

O pacote ID deve ser excluído já que era apenas uma idéia que ninguém comprou e implementou as classes. Assim, acho que pra primeira versão pode-se ignorar o pacote endereço (por enquanto) e deletar de vez o pacote id que não acredito vá fazer sentido.

O Enum UF pode ser um dia substituído por xml também, mas nesse caso como são só 27 e uma mudança nisso implica, de qualquer forma, em impacto em código acho que pode ficar assim.

Já dei commit no “dever de casa”, tinha inclusive coisa pra alterar na classe “Inscrição Estadual”, era uma List com Generics que eu tirei. Recomendo que os Generics que já estão no código sejam simplesmente comentados pra no futuro serem postos de volta.

Por incrível que pareça eu rodei o teste escrito há séculos e ele rodou!

Acho que pra primeira versão, o pacote “br” deve incluir só o seguinte:

pacote cpfcnpj - com classes de Cpf e Cnpj

pacote telefone - com as classes de telefone

pacote uf- com a classe de UF e as de Inscrição estadual.

Mas ainda acho que se pode retirar também o pacote “validation” e as referencias a interface Validable e GenericValidation. Essa amarração não é necessária.

Rafael, dê uma olhada na classe UF como ficou agora e veja se o padrão chain não pode ser aplicado lá também. Aliás, como uma UF tem internamente uma Inscriçao Estadual, talvez seja nela que esse padrão deva ser implementado, não sendo necesário que as IEs tenham referência umas pras outras, mas é só um palpite. Você pode dizer melhor o que fazer sobre isso.

#425

[quote=dsiviotti]
Porém, atendendo a pedidos…[/quote]
Espero que tenham sido muito pedidos!!!

[quote=dsiviotti]
Assim, acho que pra primeira versão pode-se ignorar o pacote endereço (por enquanto)…[/quote]
Justo o pacote de meu maior interesse! :shock: :cry:
Então vamos lançar logo a primeira versão para eu começar a colocar as minhas mãos no pacote de endereço. Douglas, você me dá uma força, não é?

[quote=dsiviotti]
Mas ainda acho que se pode retirar também o pacote “validation” e as referencias a interface Validable e GenericValidation. Essa amarração não é necessária.[/quote]
Vou deixar isso pra você porque não entendi exatamente o que deve ser feito.

[quote=dsiviotti]
Rafael, dê uma olhada na classe UF como ficou agora e veja se o padrão chain não pode ser aplicado lá também.[/quote]
Qual motivo pra isso? Não consegui enxergar nenhum.

[quote=dsiviotti]
Aliás, como uma UF tem internamente uma Inscriçao Estadual, talvez seja nela que esse padrão deva ser implementado[/quote]
Acho melhor deixar como está, nas subclasses de InscricaoEstadual. Aliás, ía até sugerir para você retirar as validações de CEP e placas de automóveis da UF (o que não faz mais sentido depois das suas mudanças).[/quote]

[quote=dsiviotti]
Mas se vc quiser, no seu sistema, usar tudo bem separado desde o início pode usar o código como você postou com as classes novas mesmo usando as que já estão lá.[/quote]
Não entendi o que fazer com as classes de CPF/CNPJ. Deixa como está?

T+!

#426

Como eu disse anteriormente, o enum TipoLogradouro deve ser substituído por uma classe e os dados por um arquivo XML. Não é só esse. O de municípios, países e UFs também. Tenho trabalhado diretamente com esses padrões de endereço desde janeiro do ano passado. O pacote de endereço está meio desatualizado. Depois que sair a primeira versão podemos reiniciar a implementar esse pacote. Posso adiantar que tem muitas funcionalidades que atualmente não são contempladas. Acabei trabalhando em um código em java que é baseado nesse só que com um ano de evolução e acesso a realidades práticas e problemas de sistemas que têm nos endereços uma informação chave. Acredito que a forma como esse pacote vai ficar vai contemplar do sistema mais simples ao mais complexo. Pra isso eu preciso liberar algum tempo, se tiver ajuda melhor ainda.

O código que você postou como sendo a nova proposta é totalmente possível com as classes como estão. Por isso acho que não é necessário trocar agora. Se numa segunda versão fizermos as alterações que você sugeriu este código não se altera em nada. A diferença é que neste código chama-se setCpf() e setCnpj(), poderia ser um mesmo para ambas as classes como setNumero().

Cnpj cnpj = new Cnpj();
cnpj.setCnpj("29520590000165");
cnpj.isValid();

Cpf cpf = new Cpf();
cpf.setCpf("123.456.178-15");
cpf.isValid();

Além disso, como já havia dito, a proposta de novas classes tem que contemplar as situações de Cpf e Cnpj que não são pré definidas. Acho que na primeira versão elas deveriam ficar como estão, ou talvez aquele método único de set para ambas as classes.

#427

Bem, estamos quase lá (versão 0.1).

Eu tenho escrito no meu blog anotações, inclusive sobre a API BrazilUtils, porque sempre que passa um tempo, eu acabo esquecendo muita coisa que fiz, ou aprendi, e depois demoro um tempão re-descobrindo tudo.

Daí, melhor do que escrever nos meus cadernos ou no Open Office é deixar num blog, porque, se serve pra mim, pode servir pra outros.

Escrevi sobre a validação de Inscrição Estadual e a validação em cadeia e sobre como passar valores monetários por extenso, entre outros assuntos.

Eu estou aprendendo a usar as classes do pacote org.brazilutils.br.telefone, então provavelmente esse será o próximo assunto.

Portanto, Iron, Douglas, feedback!

#428

[quote=dsiviotti]
Depois que sair a primeira versão podemos reiniciar a implementar esse pacote. Posso adiantar que tem muitas funcionalidades que atualmente não são contempladas. Acabei trabalhando em um código em java que é baseado nesse só que com um ano de evolução e acesso a realidades práticas e problemas de sistemas que têm nos endereços uma informação chave. Acredito que a forma como esse pacote vai ficar vai contemplar do sistema mais simples ao mais complexo.[/quote]
Óteeemo! :smiley:

Será que alguém pode me explicar porque não consegui postar uma imagem aqui no GUJ? :roll: Tentei + ou - assim -&gt

[abre tag img]http://bp2.blogger.com/_KYeHnrXYwPg/RZ2d9pBtXlI/AAAAAAAAAFM/QxVhqsUGc90/s1600-h/chain_of_responsability.png[fecha tag img]

Valeu!

#429

Rafael,

Estava dando uma olhada nas clases de Inscrição Estadual e vi que todas elas ganharam um atributo nextValidator que é onde é guardado o próximo validador a ser chamado. Esse atributo não poderia estar na classe InscricaoEstadual como “protected”? Talvez até como “private” com os métodos implementados somente na classe InscricaoEstadual já que são todos idênticos. Ao invés de ter 27 métodos idênticos nas classes filhas teria só um na classe mãe.

#430

[quote=dsiviotti]
Talvez até como “private” com os métodos implementados somente na classe InscricaoEstadual já que são todos idênticos.[/quote]
Sim, bem melhor. :smiley:
Sabe como é, fiz depos do Ano Novo! Ainda estava lento… :lol:

[quote=dsiviotti]
Ao invés de ter 27 métodos idênticos nas classes filhas teria só um na classe mãe. [/quote]
Essa vai entrar na categoria “Oh meu Deus! Eu fiz isso!”. :lol:

Pode deixar que eu refaço tudo.

#431

Tem uma coisa que está me incomodando. O método isValid sempre precisa chamar defineCoeficients. O problema é que sempre que isValid é redefinido, é preciso lembrar de chamar defineCoeficients.

[code]
public boolean isValid() {

	// Necessário para que a cadeia de validação funcione.
	defineCoeficients();
	
	int sum; // Sum of Multiply (Digit * Peso)
	int mod; // Module in sum % 11 or sum % 10
	int dv1; // Fisrt Calculated Chek Digit
	
	// If the Digit Count is not correct, return false
	if (!isValidDigitCount()) {
		return false;
	}
	
	// Calculate the Check Digit
	sum = getCalcSum();
	mod = sum % 11;
	if (mod &lt= 1) {
		dv1 = 0;
	} else {
		dv1 = 11 - mod;
	}
	// Returns Calculated Chek Digit = The Real Check Digit
	return dv1 == getDv1();
}[/code]

Só esse comentário já mostra que a coisa não está tão legal assim. Dá pra resolver isso com Template, mas vai deixar as classes um pouco mais complexas, o que não é legal.

Como dificilmente alguém vai criar novas subclasses de InscricaoEstadual, e todas as que já existem são final, não sei se vale a pena mexer. O que acham?

#432

Acho que NÃO vale a pena mexer.
Vamos marcar um skype no FDS para discutirmos?

#433

Acho que NÃO vale a pena mexer.
Vamos marcar um skype no FDS para discutirmos? [/quote]

Por mim tudo bem. Devo estar trabalhando mesmo. Se vai ser liberado algo no dia 22 já é bom gerar o jar e fazer testes. Quando às alterações nas classes, acho que a prioridade gerar uma versão.

#434

Douglas, uma dúvida!

Não ficou bem claro pra mim, se alguma coisa das classes referentes à validação de CPF E CNPJ que eu modifiquei vão ser aproveitadas para as próximas versões.

Ou as classes CpfCnpj, Cpf e Cnpj não precisam de mudanças?

[Editado]
Porque se tiver que fazer alguma coisa nelas, eu posso ver isso enquanto você e o Iron estão cuidando dos testes.

Falandio nisso, como vão os teste? Tá chegando…
[/Editado]

#435

Os do Douglas eu ainda não sei, o meu deu uma atrasada pq o site que eu usava para comparar não está mais no ar e eu uso outros 2 agora para isso.

#436

Os do Douglas eu ainda não sei, o meu deu uma atrasada pq o site que eu usava para comparar não está mais no ar e eu uso outros 2 agora para isso.[/quote]

Se não estivesse atrasado teria algo errado. Minha definiçao de “prazo” se tornou muito singular nos últimos meses.

No domingo devo disponibilizar os testes.

#437

Opa, cai de para-quedas aqui :lol: . Eu estou tentando utilizar a API de vocês aqui e me deparei com a seguinte situação: quando eu passo o CNPJ 06124268000111 para o método de validação Cpf.isValid(CNPJ) eu obtenho true como resposta, ou seja, está validando o número :!: . Agora, quando eu tento criar um objeto da classe Cpf passando o mesmo CNPJ (Cpf cpf = new Cpf(CNPJ)) o método lança uma ValidationException.
Isto é para acontecer ou estou utilizando a API de você forma incorreta (ou os dois quem sabe)?

Grato pela atenção!

Fischer

#438

Fischer ,

Eu nao entendo desta API, mas tu ta tentando criar um CPF com um numero de CNPJ?

]['s

#439

Sim, eu fiz isso propositalmente. Acho meio estranho: o método Cpf.isValid(String cpfOrCnpj) validar tanto CPF como CNPJ, mas se você tentar criar uma mesma instância da classe Cpf passando um CNPJ lança exceção.
Não quero discutir com os criadores da API se isso é certo ou não (se é que existe a forma certa ou a errada), quero apenas saber qual a melhor forma de utilizar a API para que só valide se for passado um CPF para validação.
No momento estou utilizando o contrutor da classe Cpf para isso e tratando a exceção.

Fischer

#440

Fischer, você pode saber melhor o que está acontecendo aqui: http://www.guj.com.br/posts/list/405/20643.java. Veja a partir da terceira mensagem. Ainda estamos discutindo o que fazer com as classes de CNPJ e CPF.

Você poderia contribuir com sua opinião.