Também conhecido como estagiário :mrgreen:
Hummmm… Shoes, o que você me diz disso hein? :roll:
Niterói, RJ.
Me manda um email em pvt e eu te convido para o projeto.
Pessoal, o projeto é [size=18]BrazilUtils[/size] e não RioDeJaneiroUtils… será f… para nós pegarmos requisitos inerentes de outros estados!
Mas vamos começar com o que temos, semana q vem vamos postar uns esboços lah para o pessoal ir tendo idéia de como fazer…
É somente uma sugestão,
mas os pacotes poderiam ser divididos por Regiao
tipo
sudeste.sp.*;
sudeste.rj.*;e por ai vai
Falow…
Wagner, dessa forma regionaliza demais a coisa. E existem poucas coisas q seriam exclusivas só para aquela região(Alguma tributação talvez?).A forma como o Douglas está fazendo é a mais clara.Ah, o endereço do projeto é: https://brazilutils.dev.java.net/
Ainda não tem nenhum release/código, mas esta semana colocaremos algo lah. 
Só pra lembrar quem já tiver dado uma olhada no código: as classes que representam cada UF deveriam ser default como a classe StateAC, já acertei isso.
Fiz State como uma superclasse ao invés de uma interface porque acho que muitos métodos serão iguais entre os estados. Assim fica menos coisas para reescrever. Mesmo coisas como Inscrição Estadual podem ser iguais em vários estados, nestes casos basta implementar em State. Até o ICMS, método provável “getICMS()”, deve ser igual em vários estados. Outro detalhe é que ainda não sei se irá ser preciso variáveis comuns, neste caso a interface iria complicar.
PS: Onde vai acontecer debates ao vivo? MSN? ICQ? me avisem para eu criar uma conta. Só tenho do Yahoo.
Eu compreendo, mas não corre o risco de ficar uma POWER abstract class muuuito inchada?Eu não tenho uma noção clara a onde chegaremos devido a existência de muitos impostos,tarifas entre outras, mas tenho medo aonde poderemos chegar…
Tipo, os requisitos federais, teremos coisas do tipo bem isoladas, cpf, cnpj,pg, cada um sendo uma classe.Mas chegando nas unidades federativas,teremos muitos impostos(ICMS), atrelados numa única classe.
Poderá ficar muito monstruosa.
Douglas, eu gostei dessa sua estrutura(está limpa), mas será q deveremos seguir essa estrutura classe-estado?Ou package-estado?
Eu pensei paralelamente numa estrutura parecida, para o q for de competência federal (brazilutils.federal), para sistemas de medidas(conversões), (brazilutils.metrics) e para conversões monetárias (brazilutils.currency)…
Eu compreendo, mas não corre o risco de ficar uma POWER abstract class muuuito inchada?
[/quote]
De forma alguma. A classe State tem N métodos. Cada classe também terá esses N métodos. Não dá pra fugir disso. Veja:
No caso de impostos todas as classes de estado deverão implementar algo do tipo:
getICMS()
getIPVA()
getDUDA()
getOutroImposto()
Para validação etc:
boolean checkIscricaoEstadual(String ie)
String getDigitosInscricaoEstadual(String ie)
Cada método que se possa pensar ser específico de cada estado deve ser declarado em State e sobrer override ou não nos estados.
De qualquer forma, a classe UF do jeito que está já oforece uma alternativa a declarar algo assim
int id;
String nome;
String uf; pois será declarada assim:
int id;
String nome;
UF uf; Onde a classe UF só pode ser criada com uma sigla válida [SP,RJ,MG,etc]
Os métodos acima vão de bônus.
Outra coisa que me fez pensar nesta estrutura de classes é que a classe tipo 'ToolKit" - que aliás acho que deveria se chamar BrKit - deve ter algo tipo getUF. Essse método retorna um objeto da classe UF e é através dele que será possível acessar métodos específicos dos estados dentro da classe nacional. O programador apenas adapta o seu sistema dando um
BrUtil.getBrUtil.setUF( new UF("SP") )a partir daí o getUF se comporta como “getSP” sem ficar explícito nome de estado nenhum - como já havíamos concordado. Exemplo para criar um campo InscricaoEstadual em um objeto será necessário declarar como GenericInscricaoEstadual (acabei de ter uma idéia) e depois instanciar como RJInscricaoEstadual, por exemplo. Só que se eu puser no código
GenericInscricaoEstadual ie = new RJInscricaoEstadual();teremos o mesmo problema de portabilidade. O código deve ser assim (usando BrUtil)
GenericInscricaoEstadual ie = BrUtil.getBrUtil.getUf().createInscricaoEstadual();Para terminar. Só não sei se cada classe StateXX deve ficar no pacote brazilutils.br.xx ou no pacote atual brazilutils.uf. Depende de como vai seguir o projeto.
Vou implementar alguma coisa da classe BrUtil e te mandar para reflexão. :roll:
Como estava refletindo no post anterior, acho que o mais simples é fazer estrutura de pacotes por estado. Porém, cada pacote xx terá sua classe StateXX. Eu fiz tudo num pacote uf porque não tenho o resto da estrutura. Da mesma forma deve ser com a Inscrição Estadual, por exemplo. deve haver um pacote brazilutils.insricaoestadual com uma (Generic)InscricaoEstadual e uma implementação em cada pacote de estado.
Quanto a impostos e coisas assim, acho que devemos tê-los em mente mas sem ficar parado até dar a “solução” para isso. Sinceramente nem sei quantos são os impostos estaduais. Acho que isso tem grande potencial de impacar o projeto. Validar CNPJ, CPF, IE; Padronizar datas e moedas já é um bom começo. A parte de tributos é realmente muito grande e pela minha experiência é bom ter um contador ao lado.
BrUtil poderia ser uma interface.Como a interface básica de Collection para as coleções.Poderíamos ter uma Outra interface(menos genérica) q a estenderia, e aí criaríamos a estrutura para InscriçãoEstadual,Icms…
[quote]Só que se eu puser no código
GenericInscricaoEstadual ie = new RJInscricaoEstadual();
[/quote]
Humm…não poderia rolar, tipo, um auto-boxing?
No segundo.Está claro para quem acessar a que o estado é uma unidade federativa.
Humm… a inscrição estadual muda tanto assim de um estado para outro?
Digo a forma de cálculo?
[quote]
Quanto a impostos e coisas assim, acho que devemos tê-los em mente mas sem ficar parado até dar a “solução” para isso.[/quote]
Concordo.Melhor nem discutir isso por enquanto…
[quote]
Validar CNPJ, CPF, IE; Padronizar datas e moedas já é um bom começo. A parte de tributos é realmente muito grande e pela minha experiência é bom ter um contador ao lado. [/quote]
Ok.Vamos trabalhar nas idéias que jah temos.
Estou só esperando a opinião do Philip para tirar o pé do freio.
A parte de métricas(brazilutils.metrics) eu quero terminar essa semana para jah postar lah algo funcional.
Boone, esses códigos são o “brainstorming” do pessoal, ainda não disponibilizamos nada lah.
Humm…não poderia rolar, tipo, um auto-boxing?
[/quote]
Estava pensando em algo como:
GenericInscricaoEstadual ie = new InscricaoEstadual(new UF("SP") );
...
GenericInscricaoEstadual ie = new InscricaoEstadual(new UF("RJ") );Como seria com auto-boxing?
Calm down!!!Não há resto da estrutura…
Até o momento teríamos algo do tipo:
brazilutils.federal.* //requisitos federais
brazilutils.uf…//os estaduais
brazilutils.currency //monetários
brazilutils.metrics //conversoes e medidas
Algo faltando?Acho q jah estaria mais do q bom para começo de conversa…
Humm…esquece, li rápido d+ e viajei feio… agora entendi o q vc tava
falando!
Mas qto a sua estrutura de pacotes, vc teria algo a salientar em relação a que eu mostrei?
Achei que estivesse:
brazilutils.br.*
brazilutils.br.mg.*
brazilutils.br.sp.*
Onde .mg.* seriam as implementações específicas dos estados.
o pacote brazilutils.uf tem a implementação genérica de um estado e da classe UF para uso geral.
Na verdade, estava pensando em atrelar tudo(na brazilutils.uf.*).Mas essa de deixar uma para representação genérica é a opção.
Só tenho receio d q a estrutura de packages ponha medo nos programadores… eu me pergunto:“Está fácil de reconhecer essa estrutura?”
brazilutils.federal.* //requisitos federais
brazilutils.uf…//implementação genérica
brazilutils.currency //monetários
brazilutils.metrics //conversoes e medidas
brazilutils.br.estados…//implementações específicas…
*** Alterado ***
Concordo
É ISSO. 
Para mim esta beeem mais claro.
Quais são as novidades do projeto?
Douglas, a maioria só vai poder ver o projeto nos fins de semana pq não tem muito tempo…
Na última parte q vc fez (brazilutils.states…) eu gostei bastante, mas o philip ainda não deu um feedback se aquele é um bom caminho.
Essa é uma parte problemática, pois ela inchará bastante, e um mal passo tornará difícil qualquer refactoring… afinal, são + de 5000 municípios.Imagina depois q estiver com um zilhão de coisas ter q mudar muuitas delas…
Tô pensando em marcar uma reunião no sáb,mas alguns dos inscritos no projeto não me deixaram nomes ou deram detalhes via email!Se pronunciem por favor…
Em compensação, a parte de métricas(brazilutils.metrics) eu comecei a fazer sozinho mesmo(finalmente instalei o Eclipse 3.1M6!), e talvez até domingo dê para liberar um código lah(afinal, o pessoal só sabe pedir cadê o código???huahau…).Qualquer coisa fale por email!(Ou ICQ)