| Autor |
Mensagem |
|
|
camilolopes wrote:ae pessoal qual a diferença em usar assim:
ou assim:
[code]
public int compareTo(Cat ct){
return id-ct.getId();
}
[code]
assim eu testando aqui deduzir que com o " - " posso comparar primitivo e com o compareTo apenas objetos.. seria isso? ou to equivocado?
o métdo compareTo está na realidade comparado objetos Cat
Se a comparação se resume a comparar um inteiro primitivo então a subtração é a forma mais eficiente. Se a comparação de Cat envolve comparar objetos comparáveis então não ha outra forma que invocar compareTo neles.
|
 |
|
|
Ironlynx wrote:
Bom, quanto as features, eu vou prosseguir com o pack de métricas(já tem umas centenas para entrar), e eu estava esperando idéias do pessoal principalmente na parte de Datas(que muitos reclamam, reclamam, mas não dizem direito o que querem) e talvez, Criptografia(ago + ou - básico).
Isso de datas vai mesmo entrar ? Qual seria a vantagem/diferença para as outras API de data ?
A meu ver a vantagem seria se focasse o calendário usado aqui , possivelmente com hipotese de consultar feriados e funcionalidade de dias úteis/ de trabalho
Algumas ideias seria:
o)Uma classe genérica chamada Interval para trabalhar com intervalos de qualquer classe que seja comparable ou tenha um comparator. Esta seria util em geral tb para a parte de moeda e de quantidades/métricas
Interval
start():Object
end():Object
construtor Interval(Object a, Object b , Comparator)
construtor Interval(Comparable a, Comparable b)
contains(object)
isEmpty();
intersect(Interval) Interval
union(Interval) Interval
o) Um TimeInterval que herde de Interval para intervalos de tempo em especifico. TimePoint para pontos no tempo que seria as estremidades do intervalo.
o)Depois classe para data sem hora, hora sem data e hora com data.
o)Conversão fácil para objetos do pacote sql.
o) class Month e Year que seriam TimeInterval e a classe Day
o) Month e Year seriam iteraveis Year itera os meses e Month os seus dias
o) permitir calculos de datas/ horas
TimeInterval extends interval
startPoint():TimePoint
endPoint():TimePoint
toPeriod():Period
TimePoint implements Comparable
until(TimePoint):Timeinterval
Month implements TimeInterval, Comparable
iterator()Iterator // de Day
getName();
Day
number(); // 1,2,3... etc..
isWorkingDay()
isWeekend()
isHolyday() // para feriados...
asDayOfWeek():DayOfWeek
DayOfWeek
SUNDAY // são singletons explicitos e constantes como um Enum
MONDAY
...
number()
getName() // Segunda, terça , etc..
isWeekend()
Period // para calculos
static days(int d);
static months(int m);
static years(int y);
plus(Period ):Period
minus(Period ):Period
days()
hours()
...
CalendarDate implements TimePoint / / subjudago a um Calendar
day():Day
year():Year
month():Month
static today():CalendarDate
static tomorow():CalendarDate
static yesterday():CalendarDate
previous():CalendarDay
next():CalendarDay
plus(Period)
minus(Period)
Exemplos de uso
P0000-07-01T12:23:14 <- padrão iso para periodos que significa que falta 7 meses , 1 dia , 12 horas , 23 minutos e 14 segundos para o dia 2008-01-01 à meia-noite.
-----
Para criptografia algo simples como
byte[] hash = CriptoUtils.md5("stringdeteste");
e
String hashbase64 = CriptoUtils.md5AndBase64("stringdeteste");
O primeiro devolde o hash propriamente dito, o segundo devolde o hash codificando em base64. Este é muito usado para passwords por exemplo.
claro que teriamos tb CriptoUtils.base64(byte[] bytes);
----
Dinheiro
Vamos trabalhar com várias moedas ou só reais ?
Money
ammount
java.util.Currency
// operações de soma etc..
// operações de divisão inteira e parcelada.
java.util.Currency é importante se for para várias moeda, porque contém a informação de quantas casas decimais a moeda aceita (nem todas as moedas tem centavos... algumas tem milésmos e algumas não tem parte decimal)
O truque do Money é usar um long internamente e não um BigDecimal que junto com Currency mantém tudo ok. E a importancia dele é na hora da divisão porque não pode desaparecer/ser criado dinheiro durante a operação.
uma classe abstrata para conversão entre moedas seria interessante tlv possamos fazer uma implementação simples com JDBC (tabela de cotações) para exemplificar. Ou lendo de um xml que seria bom para teste.
Teriamos tb Money m = Brasil.reais("124587") e Money m = Brasil.reais(1458,87) para facilitar as construções.
Formatação já existe com CurrencyFormat
---
pack de metricas: o que é isso a final ?
Pelo codigo parece-me que é conversão de unidades, mas é só isso ?
Espera-se poder converter todas as unidades para todas as outras da mesma especia ? qual é o objetivo e a necessidade aqui ? envolve calculos também ?
|
|
|
|
A interface Serializable marca a classe como autorizada para ser serializada.
Em Java todos os objetos são possíveis de serializar. O método que faz isso usa reflection e um algoritmo bem simples e padrão. Mas por questões de segurança o algoritmo só deve serializar classes que se "autorizem" serializar. Por isso o algoritmo começa por verificar se a classe implementa Serializable. Se não, ele dá erro e para por ai. Se sim, ele continua. Como o algoritmo usa reflection o programador não tem que colocar nenhum método especial para serializar a classe , é tudo automático. Contudo , se ele quiser ,ele pode implementado métodos privados de seralização e des-serialização(veja no javadoc de Serializable o detalhe)
|
|
|
|
ViniGodoy wrote:
sergiotaborda wrote:
Mas não fazem da mesma forma. Por exemplo, numa empresa de entregas trabalhas com dias uteis para entrega. Num banco calculas juros com meses de 30 dias e anos de 360 dias. Nada disto corresponde com o calendário , é uma regra de negocio.
(...)
Porque nem todos os calendários têm 12 meses. Nem todos os meses tem 30 dias.
Não sei se você leu.
Estou falando do GregorianCalendar. Aquele definido pelo papa Gregório, que foi uma correção do calendário Juliano, definido por Julio César tempos antes.
Mas GregorianCalendar herda de Calendar e Calendar é genérico, então GregorianCalendar não pode não o ser. Pode ter método utilitários como getDay , mas os métodos get(int) não podem ser retirados.
Além disso vc fala como se usasse GregorianCalendar directamente. Isso é um erro comum e perigoso. Vc deveria usar Calendar.getInstance(new Locale("pt","BR")) , vai que no futuro este método não retorna mais GregorianCalendar e sim uma versão melhorada ou revista como, digamos, GregorianCalendar2. Vc viola o encapsulamento e isso , claro trás os problemas que vc afirmou. Parece que é tudo mais complicado do que deveria ser. Pois, mas tente usar Calendar.getInstance e verá que faz todo o sentido.
|
|
|
|
Mantu wrote:O HashSet, pelo que eu li, têm como principal vantagem estar baseada em um HashMap, proporcionando uma boa performance nas operações básicas(add, remove, contains e size)desde que o objeto inserido tenha uma implementação boa do hashCode().
Mas notei que esta classe não tem nenhum método para recuperar um objeto. Qual então a vantagem, ou o propósito de se utilizar um HashSet?
Antes de entender o que é um HashSet seria bom entender o que é um Set.Ajudaria a não pensar que HashSet teria que ter forma de pegar os objetos individualmente...
Um Set é um conjunto matemático, ou seja, é um conjunto de elementos todos diferentes e sem nenhum relação especial entre si.
Set<T> é uma especialização porque só permite objetos de um certo tipo criando uma relação abstrata entre eles. Mas só.
Pq eu quero um Set ? porque ele impede repetição. Então se eu faço N .add() num set não tenho que verificar se o elemento já está lá. Num list eu teria que fazer isso manualmente, o que é menos eficiente.
Um conjunto de listeners é um exemplo classico. Não é necessário informar o mesmo listener do mesmo evento mais do que uma vez - pode até ser danoso - então um set é o ideal. O novo CopyOnWriteArraySet é excelente para este fim.
Qual a implementação mais rápida de um Set ?
Sendo que a sua função é apenas impedir repetições e iterar, o gargalo é saber com eficiência se o elemento já está no conjunto. Que melhor forma de fazer isso se não pela comparação de hashCode dos objetos ? E dai o nome HashSet.
Bom ,mas e se hashcode não for a melhor forma ? Ela é genérica, mas para casos em que existem mais relações entre os objetos não é a mais eficiente. Se os objetos são ordenáveis, TreeSet é muito melhor.
Isso é muito bonito, mas se eu quero manter a ordem de iteração ?
List resolveria o problema, mas eu não quero pegar os elementos, eu so quero iterar , na mesma ordem, pelos elementos. Então LinkedHashSet faz o trabalho. O uso de hashcode é irrelevante face à funcionalidade de manter a ordem de iteração que é o objetivo.
Mas e se eu só carrego o Set uma vez ?
Neste caso a procura por duplicados nem tem que ser assim tão eficiente podendo usar um array para guardar os elementos (que aumenta a eficiencia de iterar) e uso CopyOnWriteArraySet. Que tem outra vantagem, ele pode ser usado concorrentemente sem nenhum problema de causar uma falha na iteração.
Existem Set para todos os gostos e requisitos. Agora, querer obter um so elemento de um Set revela que algo está errado , ou com a escolha de Set em vez de List ou Queue , ou com a tentativa em si, que como já foi dito não faz sentido.
Contudo, para pegar o primeiro elementos basta fazer set.iterator.next() supondo que se sabe que o set tem elementos.
|
|
|
|
RafaelRio wrote:e deixar o código do que já lançamos mais "parrudo", com ajuda de ferramentas.
O que significa exactamente "parrudo" e "ajuda de ferramentas" ?
|
|
|
|
ViniGodoy wrote:
sergiotaborda wrote:
Concerteza acharia maravilhoso fazer intervalo = date1.minus(date2) mas isto está errado pelo próprio conceito de data. Data é um conceito cultural e não um conceito cientifico. a operação "diferença de data" não é unica ela depende do contexto em que está sendo feita.
Exatamente por isso Calendar não define operações de subtração, apenas de soma. É realmente muito complexo e a Calendar faz o trabalho que se propõe a fazer.
Ok, mas porque GregorianCalendar não define? Eu poderia ter métodos para trabalhar facilmente num calendário gregoriano. Além do que, embora o conceito possa estar errado, infelizmente, as pessoas fazem SIM contas com datas!
Mas não fazem da mesma forma. Por exemplo, numa empresa de entregas trabalhas com dias uteis para entrega. Num banco calculas juros com meses de 30 dias e anos de 360 dias. Nada disto corresponde com o calendário , é uma regra de negocio.
ViniGodoy wrote:
Veja o método get do calendário gregoriano. Ele é simplesmente ridículo! Usaram o mesmo método para retornar vários fields. Por que essa decisão?
Porque nem todos os calendários têm 12 meses. Nem todos os meses tem 30 dias.
ViniGodoy wrote:
Por que não simplesmente gregorianCalendar.getDay()?
O dia do mês , do ano , da semana ?
O assunto é muito mais complexo do se imagina à primeira vista.
|
|
|
|
jack_-_ganzha wrote:
O erro não é ter que lidar com conceitos complicados. O erro é expor uma interface complicada para manipular datas. Joda-Time, por exemplo, apesar de lidar com as mesmas complicações, oferece uma interface bem mais humana.
valeuz...
Calendar não foi feito para ser uma interface humana. Da mesma forma que Joda Time não foi. TimeAndMoneyAPI foi e tem um monte de defeitos . Pq ? simplesmente pq o próprio assunto de datas e calendários é muito complexo.
Concerteza acharia maravilhoso fazer intervalo = date1.minus(date2) mas isto está errado pelo próprio conceito de data. Data é um conceito cultural e não um conceito cientifico. a operação "diferença de data" não é unica ela depende do contexto em que está sendo feita.
Exatamente por isso Calendar não define operações de subtração, apenas de soma. É realmente muito complexo e a Calendar faz o trabalho que se propõe a fazer.
O que ela não faz é o trabalho que seus inventores se propuseram -universalidade- nem o que o programador precisa - simplicidade e encapsulamento total de todas as regras. Só que um programador no brasil não calcula diferença de datas da mesma forma que um na china - e lá se vai o encapsulamento.
Concerteza a Date and Time API irá resolver muitos dos dilemas dos programadores, mas os problemas de calcular diferenças continuarão.
veja porque
http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-time.html
Agora, o que isto tem a ver com o tema ? Date e Calendar não são odiáveis. Em VB e Delphi nem existe nada parecido , em C nem pensar.
Date e Calendar demonstram exatamente como o Java é maior que essas lamexices, pq quem não gosta pode sempre fazer melhor! E depois enviar para o JCP tal como vez o pessoal da JT.
|
|
|
|
Como havia dito deixo aqui o codigo que baixei do CVS junto com o que adicionei. Eu tentei adicionar tudo em pacotes separados para vcs verem a diferença. Existem alteraçoes que eu ainda nao comentei.
Fora a inclusao de uma sub'API especifica para validaçao e a inclusao de interfaces e classes abstractas para facilitar o trabalho de validacao , existe um outro ponto mais ...
Procurem em http://en.wikipedia.org/wiki/ISO_3166-1 procurem pelo brasil e cliquem em SO 3166-2:BR. Aqui sao apresentados os codigo completos dos estados e DF. Isso é um padrão internacional e não apenas do brasil.
A duvida é a seguite : não sei até que ponto a API deve ficar amarrada a consideracoes apenas brasileiras. Parece-me que sendo uma API de localização de aplicações ela tem que ser especifica, mas isso não significa que não se possam deixar ganchos para facilitar o trabalho de extençao e mesmo a compreencao da API. Com vista isto introduzi dois conceitos o t
de Unidade Territorial (TU) e o pais (Country)
TU tem dois atributos : codigo do pais e codigo de TU que seria o codigo da ISO 3166-2 , que no caso do brasil são as siglas dos estados.
FIz a UF herdar de TU por uma questão para que de certa forma se possa ser compativel com a ISO e ao mesmo tempo poder diferenciar explicitamente as UF . A UF tem um nome em protugues que a TU não tem ( e não teria como ter) . A classe Brazil que falei antes é um Country. e as UF são TU. à primeira vista isto é inutil ,mas serve para deixar claro o que Brazil e UF são , assim como compatabilizar isso com a ISO e possivelmente depois com as API de Locale e TimeZone (trabalho futuro)
Isso me leva a outro ponto: parece que estão querendo incluir uma sub-API para tratamento de datas. Isso é muito complicado e parecer ser a reinvenção da rda, já que a PI joda Time está ai ... mas eu não li nada sobre quais as intenções de ter mais uma API para isso.... Contudo, mesmo que fossemos fazer essa sub API sugiro que seja apenas uma fachada para a api JODA -TIme, que no futuro possamos substiturir pela Date and Time API que será o padrão logo, logo.
Em relação ao que vc escerveram:
Com o modelo de CodeNumber e VAlidator a transição para um outro modelo de numeros e valdiaçoes é simples. Podemos ter o validador CPFValidator e CPFValidator2007 (supondo que o novo padrão entre em 2007) e com compositeValidator poderemos validar os dois simultanemante. Acho que isso não será um problema se usarmos esta estruttura.
Defacto eu não tivemuito tempo para estudar a API, isso devendo-se principalmente ao fato de que ela é dificil de ler e ao facto de que não domino algumas partes, como a barcode API. O meu aport neste momento
vai mais na organização e estrutura do codigo, por isso realmente não me prendi com a implmentação (aliás, pq estou propondo outra) Mas tentei implementar o algoritmo de validação de CNPJ e IE de são paulo para demonstrar as vantagem do novo modelo que proponho. Deem uma olhada por favor. A minha procupação com a API é que ela parte de conceitos muito simples que são tratados -não se ofendam - de forma simplista, mas que não são tão simples assim porque envolvem internacionalização. (como telefone, por exemplo, mas falarei disso outra hora). VC poderão argumentar que o objectivo não é fazer uma API válida para outros paizes que não o brazil, mas ai eu teria de invocar o paradoxo do inventor e o facto de que se api é compativel com outros paizes poderiamos ver, no futuro, algum grupo extendê-la para o seu ppr pais sendo uma mao na roda para quem trabalho com expostações/importações.
Quanto ao texto extenso, vcs vao desculpar mas eu não tenho muito tempo e tenho que deixar bem claro o que proponho para minimiar duvidas e portanto futura escrita. Nas próximas semanas não vou poder usar o meu computador de desenvolvimento por isso apenas estarei conversando com vcs sobre a API, mas assim que me for possivel estou disponivel para codificar mais coisas.
P.S: Deem uma olhada no pacote adress onde tem um esboço do uma api para endereços Uma outra coisa que parece simples, mas não é.
|
|
|
|
Chain of Responsabiliy = Cadeia de Responsabilidade , como foi dito quando um objecto não sabe/pode/quer fazer o que tem a fazer ele delega ao próximo. Próximo é um conceito relativo, não significa que ha uma arvore, nem que o proximo existe.
Exemplo do padrão CoR são os Filter da tecnologia de servelt e os proprios servelet em si. Filter é mais obvio pq vc pode encadear os filtros quando o request vai para o servelet e na volta
(Request) --> filtro1 -> filtro2 ---- > filtro N -- > Servelet --> filtro N -- > ... > filtro 1 --> (Response)
Isto é CoR.
Os servelet usam o mesmo pattern através de RequestDispatcher. Aqui a delegação é explicita, o servelet escolhe outro servlet para delegar o trabalho. Nos filtros ela é implicita, fica denifia no web.xml.
Pq este padrão é ruim ? Ele não é ruim. ele é otimo, mas para aquilo que se pretende. Existe uma diferença fundamental entre um objecto Request/Response e um objecto como CNPJ. A diferença é que a cada passo cada membro é livre de ler e escrever no objecto que lhe foi passado. É como aquelas brincadeiras que uma pessoa fala algo no ouvido da outra e assim por diante e no fim o que a ultima pessa fala é diferente do que a primeira disso. Isso se deve a que os membros da cadeia mudaram (ou não) a mensagem. É um padrão para processamento de mensagens. Ora, CNPJ não é uma mensagem, ele não pode ser manipulado.
Composite é muito simples de implementar e usar. Um Validador que é composto de outros validadores. A ordem não é pre-estabelecida e com uma interface como validator é muito simples o usuário criar outros validadores para coisa mais especificas ou de negocio.
Exemplo: a API aceita 00000000 como um cpf válido. possivelmente o programador que a usar não vai querer isso. Ele pode introduzir um validador na cadeia para não permitir isso, mas é opcional. claro que a API irá prover um validador mais restrictivo (espero que vá) ,mas o seu uso é opcional.
Poderia ser criado tb um validador complementar ou seja, ele aceita o valor se algum dos seus validadores o aceita (OR). Este conceito é diferente do outro que só aceita se todos aceitam(AND). Desta forma
por exmeplo uma string poderia ser aceite como CNPJ ou CPF desde que fosse válido para um dos dois.
embora as classes de validação sejam para simplificar as classes e os mecanismos ela servem para uso da API, o usuáro não é obridado a usá-las. Como eu falei antes ele irá usar Brasil.ie("83857475").isValidFor(UF).
MAS uma API é melhor quando dá mais liberdade ao usuário.
Vejam a diferença
Agora:
depois
O que eu estou fazendo no primeiro codigo ? Estou adicionando inscrções estatuais umas às outras ?! e pq coloco o numero em rs ? poderia ser rj ?
Fora isso , o codigo tem comentários assim "isto é necessário para a validação em cadeia funcionar" ... meio estranho , não é ?
E na segunda forma ? Estou criando um validador, composto de vários validadores e pedindo que seja validado uma inscrição estadual que não sei a que estado pertence.
Vcs que digam qual acham mais simples.
Por que deveria usar Composite? Mas hei, nada disto impde que exista um IENumber.isValidFor(UF uf). so que ele irá usar o validador internamente e não ele mesmo processar a validação.
O que se quer é que cada objeto cuite de sua própria responsabilidade (validar a IE para um estado)
Sim, mas qual objecto ? Um objecto InscriçãoEstatual pode validar-se a si mesma ? Isso é como eu dizer que sou otimo jogador de futebol. Eu, sobre mim, digo o que quiser. A responsabilidade tem que ser de um validador, certo ? (é o treinador/olheiro que avaliaria se sou bom ou não, não eu mesmo). Até porque existe uma razão muito simples para que o objecto não se possa validar: validação pode ter muitas regras , nem todas préviamente conhecidas pela API. Imagina um email Ele pode ser validado com base na mascara, mas tb com base no dns do servidor e até mesmo enviando um email para o endereço, e ainda fazendo todas ao mesmo tempo. O ponto é que a validação que a API se propoe é apenas uma das muitas possiveis.É a validação padrão.
O que se quer é que cada objeto cuite de sua própria responsabilidade (validar a IE para um estado)
Não segundo a diretiva chamada de Separação de Responsabilidade (Separation of Concerns , cuja tradução literal é Separação de Preocupações). O objecto CodeNumber deve preocupar-se em tranportar os dados e fornecer operações simples com eles, como asDigits() , o validador preocupa-se em validar o CodeNumber e o formatador em formatar e desformatar o Codenumber de uma string. Compara isso com
Number e NumberFormat , Date e DateFormat. E para validação veja a API de validação usada no JGoodies.
Por que deveria usar Composite?
Porque é mais simples de entender , usar e implementar. Reduz código nos objectos de numeros , centraliza a validação e sua regras e é mais flexivel para futuras alterações/extenções. Facilita tb o teste de uniddae pq se limita o dominio de objetos a testar por vez
quanto ao desempenho.... as implementações que eu vi não sao failfast. Por exemplo a de CNPJ calcula os dois digitos verificadores e depois testa os dois. Ela tem que testar o primeiro, se der errado já retorna false e pronto. Isso é Failfast e é mais rápido. imagine validar 1000 CNPJ tendo que calcular sempre os dois digitos verificadores... Outras coisas o uso de coleções em vez de arrays e coisas assim , menos preocupantes... mas que limitam o desempenho da mesma forma.
Programar de forma elegante é importante, sobretudo num projeto opensource porque:
1) simplifica o codigo quase sempre caido no paradoxo do inventor (quando vc tenta fazer mais generico vc resolve mais problemas de formas mais simples)
2) É mais facil as outros programadores entender sem ter que ler comentários e ao usuario final de usar.
3) É normalmente mais eficiente e extensivel.
4) Evita refactoring constante e quando necessário ele é minimizado.
5) Os programadores aprender mais sobre design e patterns.
|
|
|
|
Thereza Cristina da MOtta wrote:Olá....gostaria de saber como faço para sair de um JFrame sem sair do sitema....obrigada
|
|
|
|
Vc tem que declarar ArrayList<Produto> e não apenas ArrayList. Isto SÒ funciona em java 5 ou superior. Para o java 1.4 e anterior vc deixa a declaração como está e usa
nota: pelo codigo vc quer encontrar o produto pelo nome.
Então o melhor é usar Map como HashMap em vez de list.
|
|
|
|
bom, então vamos lá ...
Eu acessei o codigo da api e tenho algumas duvidas/perguntas/sugestões.
Primeiro que tudo a padronização de nomes. O ideal é programar usando inglês porque facilita a criação de nomes compostos , mas por outro lado existem coisas muito especificas para as quais não existe uma tradução direta. Eu gostava de saber qual é a directriz: se se deve preferir o ingles ou não. Em qualquer dos casos a API pecisa de uma refactoração geral relativamente a isso. sugiro que se use Ingles e que se traduzm ou abreviem os nomes especificos. Exemplo Inscrição Estadual = IE
Mas o javadoc acho que deveria ser primeiramente em portugues uma vez que o publico alvo é o brasileiro e todos sabemos como nem todos os programadores dominam o ingles.
Depois existe a falta de aplicação de design patterns e os aplicados nem sempre estão bem aplicados. Por exemplo , o chain of responsability não se aplica da forma que está sendo aplicada à logica de validação. O padrão que se deveria aplicar era Composite. Depois ha uma violação grave de separação de responsabilidade. Objectos como cnjp não se devem validar a si mesmos. Eles deveriam atuar como VO e ter objectos especiais para a validação. A minha proposta é que se implemente a seguinte estrutura
interface Validator
public boolean isValid(Object obj) throws ClassCastException
Este objeto faz validações. Se o objecto passado não puder ser validado por ete validador uma ClassCastException acontece. (por exemplo, tentar validar CEP com o validador de CPF )
Com isto é simples criar um
class CompositeValidator implements Validator
addValidator(Validator v)
Este objecto permite adicionar vários validadores que se encadeiam na validação do mesmo objeto.
Isto permite também que sejam criados validadores de negocio e acidionados à regra. Por exemplo, o Endereço tem que ser válido E ser de São Paulo
A interface AutoValidatable com o unico método isValid() marca objetos que se podem auto validar. Mas na reaidade o que eles farão é invocar o validadadro certo.
Outra coisa são os numeros de identificação como CNPJ, CEP , etc...
Eles representam códigos alfanumericos, normalmente apenas numericos.
Eles não representam as entidades Cadastro Nacional de Pessoa Juridica, e apenas o numero do cadastro. então sugiro que os nomes sejam alterados para CNPJNumber , CPFNumber e assim por diante. A exceção é o CEP porque ele representa reamente um codigo (Codigo de Endereçamento Postal).
Em relaçao a isto tenho outro ideia. Definir uma interface marcadora chamada CodeNumber que implementa CharSequence e representa codigos alfanumericos com métodos utilitários como asDigits() que retorna um int[] com os digitos nos lugares certos e digitAt(index)
Isto facilita imenso na hora da validação pq a transformação para int é muito usada. CharSequence tem o método length tb muito util na hora de fazer validações. Todos este codenumber são imutáveis e aceita uma string no cosntrutor. Esta strng sempre será desformatada e guardada internamente desse jeito.
Depois , a classe Brazil . esta classe tem metodos estáticos utilitários para as operações mais comuns como por exemplo Brasil.cnpj("0099843747").isValid()
isto poupa o utilizador de ter que criar um monte de objeto vara fazer algo simples. Mas, pode se quiser, criá-los. Isto é apenas para ajudar.
Existe a classe UF com várias instancias estáticas.
Esta classe tem dois problemas: 1) cada UF contem uma inscriçãoEstadual.
Isto não é necessário e obriga a construção de objectos que podem não vir a ser usados. A UF deveria ter apenas o nome e sigla. Esta sigla é na realidade um codigo curto para o estado o codigo mesmo é "BR-SP" como definido pela ISO . Acho que isso deveria ser tomado em conta colocando os métdos getCode() e getShortCode().
A lista de estados é obtida com o metodos estático values() ,mas internamente ele cria um colection. Isto poderia ser feito via reflection e usar um cache. O retorno deveria ser um array para evitar alterações ou um unmodifiableCollection.
Esse objects Inscriçãoestadual são na realidade validadores misturados com VO. como sugeri , o ideial é separar isso. Um objeto IENumber heradsndo Codenumber para colocar os numeros e Objectos validator para o validar. Os validadores obdecem a uma naumenclarura exemplo IEValidatorForSP com o UF no fim. Desta forma é possivel obter os validadores por reflection e ter o metodo estático IEValidator.getInstance(UF) que obtem o validador correcto para a UF. Dessa forma é simples criar o método Brazil.ie("numero").isValidFor(UF)
Isto, junto com o CompositeValidator permite fazer validações em cadeia de forma simples e permite o codigo dos validadores e dos codenumber ser muito simples. ao contrário do que é agora com métodos estanhos que dizem servir para encadear as validações (?!)...
Eu criei este códigos mas estão noutra máquina, eu deixarei eles aqui assim que possivel. Mas enquanto isso aqui ficam as sugestões para discussão. (tenho mais sugestões, mas fica para depois)
Na minha opinião a padronização e aplicação dos desing paterns só ajuda o desenvolvimento e o uso da API. E ainda estamos a tempo de marcar deprecated ou até mesmo remover métodos e objectos que não cumpra seu papel
outro assunto é relatiamente a casos de uso. Em que cenário, por exemplo, eu iria querer validar uma Inscrição Estadual em vários Estados?
Uma lista deste casos, traduzida numa unidade de teste seria tb util.
|
|
|
|
Os objectos dentro de uma colecção continuam sendo eles mesmos
|
|
|
|
|
Eu queria saber se tem lgum lugar especifico para discutir sobre esta API ou se pode ser aqui mesmo no guj...
|
|
|
|
|
|