JRimum - Novo projeto open source brasileiro.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

gilmatryx wrote:

sergiotaborda wrote:
Uma outra coisa que faz pouco, ou nenhum sentido, é a herança de um objeto com um monte de métodos estáticos para verificar nulidade. Isso caberia numa classe utilitária e dificilmente num objeto padrão, muito menos num "Layer SuperType" de onde todo o mundo herda. Isso é bem estanho.

Gostamos de legibilidade e tentamos ser práticos, achamos melhor fazer:
(...)
O Intellisense é muito melhor para esse tipo de coisa.

Melhor que isso seja uma coisa básica de todas as classes se não teremos que ficar importando isso toda hora.

O seu argumento é, basciamente, "temos perguiça de fazer import de um classe utilitária e por isso optamos por enchar todas as classes com todos os métodos utilitátios possiveis". É um péssimo argumento.
Voce resolve tudo isso de forma elegante criando uma classe utilitária de métodos estáticos ( à lá Math) e usando static import.
Como isso vc escreve exactamente os codigos que mostrou mas sem pesar nas classes que interessam.

Veja o exemplo do JUnit. Ele define os métodos assertXXX dessa forma. Nas versões antigas era métodos da classe de teste, mas isso era porque existia uma classe de teste. Agora que isso não existe mais, os métodos são chamados via import estático

Além do que o método toString() de Object utiliza o ToStringBuilder do commons do apache, isso também fica em um lugar só, assim não preciso fazer um para cada classe.

Isso é uma falha no encapsulamento (API leakeage). Quem usa a sua API não tem culpa das API que vc usa. Não precisa nem saber. Não ha problema nenhum em especificar toString() em uma interface ( vide CharSequence) mas tem que ser por um bom motivo. Se não , Object já define isso.

Por outro lado usar uma API externa para escrever o toString é forçar a barra. Vc não precisa disso. Meio que passa a ideia de que vc não sabe escrever o toString...

Além do logging também, como não usamos AOP, isso tudo fica em um lugar só fica como serviços básicos da classe, para o nosso propósito e no nosso pensamento lógico.

Pois é, esse é o problema de sempre: "o nosso pensamento logico" e o pensamento logico dos usuários da sua API? não interessam ? e as boas práticas ?

Esses foram os aspectos que consideramos para esse Object do JRimum.Embora consideremos mais como uma decisão de praticidade mesmo. Mas pode ser que seja uma atrocidade ou barbaridade para algum principio de programação. Desconheço como uma ofensa grave, reconheço que não é nenhum tipo de "Boa Prática".

Ainda bem que reconhece. ainda está a tempo de mudar isso na versão 2

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

gilmatryx wrote:

sergiotaborda wrote:
Vc não cria classes chamadas ClassCliente nem InterfaceRelogio então porque criar EnumSexo ou IBanco ?
Banco é Banco. Se precisa de formas diferentes crie outros nomes prefixo comuns são Default, Abstract, Generic
O principio de encapsulamento implica que interface e classe devem ser indistinguíveis. Vcs violam isso usando prefixos como I e Enum. Não ha necessidade.

Nem todos no projeto são a favor desses prefixos, alguns concordam inteiramente com a sua colocação.

Foi apresentado o argumento que um tipo, por exemplo sendo uma interface, não possui o mesmo comportamento se o mesmo for uma classe, mas eles não deram muita importância. Perguntou-se, por que as IDEs diferenciam esses tipos com ícones diferentes? Posso dar um new em uma interface? Se eu souber antecipadamente que aquele identificador é uma interface nem tento fazer isso.

Vc está brincado , certo ? Desde quando o que um IDE faz é argumento ?
O IDE põe icones diferentes porque ele pode. apenas isso. Um IDE é um aplicativo gráfico ele precisa passar informações gráficamente. Esse, com certeza, não é o foco de uma API.

O ponto é exactamente ao contrário. Interfaces e classes não devem ser destinguiveis. Se alguem tentar dar new numa interface não tem problema ( classe anonima são feita assim). Interfaces são importantes. Defender o programador da sua ignorania não é uma preocupação de quem constroi uma API publica. Se o cara tenta dar new num enum o problema é dele, não dos designers da API.

Quanto aos nomes: Nomenclatura é primeiro pilar de qualquer norma. Até da linguagem omnipresente. Não é algo que se possa desconsiderar ou levar "na boa". Isso é pricipalmente assim quando a API é publica. Se fosse privada o problema seria da organização, mas sendo publica o problema é de todo o mundo. O sucesso da sua API depende de quão inteligivel ela é e não apenas do que ela faz.

Muito já foi discutido no grupo JRimum, aqui vou colocar algumas coisas da lista de desenvolvedores do jrimum:

Dois problemas ai
1) Discutir muito não signfiica nada. Os politicos fazem a vida discutindo.
2) A API é publica, logo o que a equipe de desenvolvimento pensa ou acha equivale a 40% da solução. A opinião de quem vai usar precisa ser ouvida.

Não sei, mas fica aqui o registro que queremos aumentar o reuso e a usabilidade para nós brasileiros.

Este assunto não tem nada a haver com ser brasileiro , de brasileiro ou para brasileiro. Nem tem nada a haver com a funcionaldiade da API. Tem a haver com o design da API. O seguimento de normas, padrões , coisas com que o mundo concorda e não apenas meia duzia de pessoas.

Pareceu-me haver uma preocupação com o seguimento de padrões relativos ao dominio ( os padrões das associações de bancos) e isso é bom. Seguir padrões como small data types, etc.. Tudo isso é bom. Mas se não for acompanhado de uma normal de design vai tudo para o lixo. E por "norma" me refiro a algo imparcial, aceite e usado pela maioria

Por exemplo, não fazia muito sentido ter smal data types mutáveis. Eu desconfiei- e já confirou- que é por causa do hibernate ,etc..
Isso é uma falha no design. É API leakage. É preocupar-se demais com o como a para o quê a API irá ser usada. É bom fornecer ganchos mas não é bom supor demais ( early otimization) Por exemplo, bastaria os small data types serem extenciveis para que, quem precisar, os estenda e torne compativel com o hibernate. Ou a propria API pode ter um pacote de compatibilidade desse tipo.
Mas não precisa fazer parte do core da API.

Paulo Silveira wrote:
Oi Gilmar!
Iamos criar as classes de dominio (CPF, CNPJ, etc). optamos por nao cria-las para nao forcar a pessoa a usar nosso dominio, mas ai devido a sugestoes iamos cria-las e deixa-las opcionais. Quem sabe podemos trabalhar em conjunto.

Claro, podemos sim, qual é sua proposta de como trabalhar?
Seremos fornecedores um do outro, tipo fazemos o domínio e vcs os validadores?
Ou modelamos em conjunto para um dos projetos?
OU juntamos os projetos?
Não tenho nem idéia. Como seria? Eu particularmente estou disposto sim. Agregando valor , ...
Tamos aí.

mrblack wrote:
Tri massa o projeto, legal ver a iniciativa do pessoal, mas na minha sincera opinião, não vejo motivos pra sair criando projetos que ja fazem o que outros muitos fazem só porquê uma ou outra feature não me agrada ou não existe, seria legal o pessoal colaborar com os projetos já existentes e acabar um pouco com essa confusão, mas enfim, parabéns.

Agora, me corrijam se eu estiver errado, o 'número' do RG não é composto somente por números, até onde eu me lembro em Santa Catarina, por exemplo, eles têm letras também, não sei se isto acontece em outros estados, sendo assim setNumero na classe RG deveria receber alguma outra coisa mas não um long.

Quanto a sair criando projetos indiscriminadamente..., bom não sou a favor, falei anteriormente que ia ter que mudar todo um projeto existente e muitas vezes os envolvidos (donos dos projetos) relutam, não concordam ,não aceitam, etc.

Referente ao RG não tínhamos como validar na hora do design essa informação, mas foi discutido. Como não é vital para o boleto bancário (que focamos no momento) acabou que esquecemos. Obrigado pela observação.

danieldestro wrote:
Acho legal vocês buscarem uma aderência ao DDD, mas acredito ser esmero ou utopia demais modelar as classes desta forma, haja vista que pouquíssimos irão de fato usufruir destas facilidades.

EU, por exemplo, dificilmente usaria pessoa.addRG(rg). Certamente eu usaria Pessoa do meu modelo, podendo até incorporar o RG do projeto.

Sou mais a favor do KISS, neste caso, pois trata-se de biblioteca utilitária (genérica) e não específica ao problema de negócio. Assim acaba podendo engessar o desenvolvimento.

Bom, já falei que focamos no componente bancário (boleto) e pra ser sincero com todos, mais especificamente no domínio bancário. É normal que sistemas corporativos se utilizem de meios para fazer integrações com bancos (instituição financeira) e o modelo que estávamos pensando no momento de design era esse.

Mas caso a comunidade opine, em maioria, por mais flexibilidade e independência, ..., acho que tomaremos outro rumo no design.

This message was edited 2 times. Last update was at 03/07/2008 13:04:46

sergiotaborda wrote:
O seu argumento é, basciamente, "temos perguiça de fazer import de um classe utilitária e por isso optamos por enchar todas as classes com todos os métodos utilitátios possiveis". É um péssimo argumento.
Voce resolve tudo isso de forma elegante criando uma classe utilitária de métodos estáticos ( à lá Math) e usando static import.
Como isso vc escreve exactamente os codigos que mostrou mas sem pesar nas classes que interessam.

Veja o exemplo do JUnit. Ele define os métodos assertXXX dessa forma. Nas versões antigas era métodos da classe de teste, mas isso era porque existia uma classe de teste. Agora que isso não existe mais, os métodos são chamados via import estático

Cara, vc realmente está por dentro do desenvolvimento do projeto, capturou rapidinho os bons e maus costumes nossos. Olha o que tenho a te dizer é que ser preguiçoso hoje em dia é moda

.

Na verdade queremos realmente esse tipo de observação. Pelo que vc está falando, vc não gostaria de ter esses métodos comparativos em qualquer classe que vc use. Pelo que entendi, se a Sun colocasse esse tipo de método hoje em Object vc não iria gostar, pois vc provavelmente não usa muito.
A questão para nós foi, Bicho, toda hora ter que saber da nulidade ou não de uma referência é normal para nós, vamos fazer assim. Todos quando estavam usando gostaram, lógico é uma pequena amostra de desenvolvedores, mas mostrou-se útil. Uso esse tipo de comparação toda hora em outros projetos acho super útil. Acho que a palavra super pesou muito.

Lembro de novo o projeto ta incubado para isso. Se nós não tivéssemos deixado esses métodos teríamos ter que explicar e um protótipo é sempre melhor. Mas UMA VEZ muito obrigado.
Mas até agora só vc falou desse ponto. Queríamos que o pessoal falasse também gostando ou não.

sergiotaborda wrote:
Isso é uma falha no encapsulamento (API leakeage). Quem usa a sua API não tem culpa das API que vc usa. Não precisa nem saber. Não ha problema nenhum em especificar toString() em uma interface ( vide CharSequence) mas tem que ser por um bom motivo. Se não , Object já define isso.

Por outro lado usar uma API externa para escrever o toString é forçar a barra. Vc não precisa disso. Meio que passa a ideia de que vc não sabe escrever o toString...

Cara a interface é para dizer que todos os nossos objetos devem ser serializáveis e que o toString() deve ser usado para exibir os atributos e valores do objeto. Para nós ele só serve para isso, aí no momento de uma exceção os valores são escritos. Caso o usuário não queira esse comportamento..., sobrescreve o método.
Já em escrever o meu próprio toString(), onde fica o reuso se eu tenho uma classe que faz isso para mim perfeitamente. Não concordo não, nem acho que seja forçar a barra, isso sim é uma coisa a lá Math ou Util. Caso o usuário da API queria um logging mais apurado habilitando o nível mais detalhado, ele vai ver uma coisa como essa:

Já pensou em escrever um toString que informasse os valores assim para cada classe? Não me agrada nem um pouco a idéia. Só escrevemos para as que tem tipos pesados nos atributos, como um File da vida.

Adicionado posteriormente caso alguém leia a thread. Exemplo de uso do commons para toString equals e hashCode:

https://jaxb2-commons.dev.java.net/commons-lang-plugin/

sergiotaborda wrote:

gilmatryx wrote:
Esses foram os aspectos que consideramos para esse Object do JRimum.Embora consideremos mais como uma decisão de praticidade mesmo. Mas pode ser que seja uma atrocidade ou barbaridade para algum principio de programação. Desconheço como uma ofensa grave, reconheço que não é nenhum tipo de "Boa Prática".

Ainda bem que reconhece. ainda está a tempo de mudar isso na versão 2

Pois é, estamos aqui para ouvi e melhorar, e vc tem ajudando bastante, estamos bastante gratos com suas observações.

sergiotaborda wrote:
Vc está brincado , certo ? Desde quando o que um IDE faz é argumento ?
O IDE põe icones diferentes porque ele pode. apenas isso. Um IDE é um aplicativo gráfico ele precisa passar informações gráficamente. Esse, com certeza, não é o foco de uma API.

Entendo que uma IDE como o Eclipse, NetBeans,etc, são o resultado de muito uso, pesquisa e representam toda uma cultura relacionada a programação. Um ícone ( Coisa, fato, pessoa, etc., que evoca fortemente certas qualidades ou características de algo, ou que é muito representativo dele ) usado para uma interface e um diferente para classe tem uma razão não acha?
Por que será que o padrão javadoc dá escreve interfaces em itálico, classes abstratas tem no identificador da classe a palavra abstract? Por que jamais iremos escrever uma interface e uma classe com o mesmo nome a não ser que estejam em pacotes diferentes?
Acho que é porque são diferentes.

sergiotaborda wrote:
O ponto é exactamente ao contrário. Interfaces e classes não devem ser destinguiveis. Se alguem tentar dar new numa interface não tem problema ( classe anonima são feita assim). Interfaces são importantes. Defender o programador da sua ignorania não é uma preocupação de quem constroi uma API publica. Se o cara tenta dar new num enum o problema é dele, não dos designers da API.

Me dá uma sugestão para escrever um Enumeration, uma classe concreta, uma classe abstrata e uma interface para um Título. Sério, não to tirando onda não. Nós temos esse caso. Tudo referente a título.

sergiotaborda wrote:
Quanto aos nomes: Nomenclatura é primeiro pilar de qualquer norma. Até da linguagem omnipresente. Não é algo que se possa desconsiderar ou levar "na boa". Isso é pricipalmente assim quando a API é publica. Se fosse privada o problema seria da organização, mas sendo publica o problema é de todo o mundo. O sucesso da sua API depende de quão inteligivel ela é e não apenas do que ela faz

Concordo plenamente, mas, até agora, só vc opinou sobre isso. Gostaria que o pessoal falasse mais a respeito afinal não é só de um grupo, é público.

sergiotaborda wrote:
Dois problemas ai
1) Discutir muito não signfiica nada. Os politicos fazem a vida discutindo.
2) A API é publica, logo o que a equipe de desenvolvimento pensa ou acha equivale a 40% da solução. A opinião de quem vai usar precisa ser ouvida

Por isso estamos aqui ouvindo a todos e anotando tudo para tentar melhorar. Muito já foi discutido no JRimum sobre isso e tomamos uma decisão e pronto. Se ficássemos ouvindo colocando em fórum, ouvindo, etc... A API não estaria em uma versão de avaliação. Desta forma viemos para cá com uma exemplo (A versão incubada) onde fica fácil a comunicação a respeito das soluções e decisões tomadas.

gilmatryx wrote:
Mas estamos abertos para sugestões e padronizações nacionais também, o GUJ poderia fazer, sei lá, uma enquete para uma dada padronização nacional.

Não sei, mas fica aqui o registro que queremos aumentar o reuso e a usabilidade para nós brasileiros.

sergiotaborda wrote:
Este assunto não tem nada a haver com ser brasileiro , de brasileiro ou para brasileiro. Nem tem nada a haver com a funcionaldiade da API. Tem a haver com o design da API. O seguimento de normas, padrões , coisas com que o mundo concorda e não apenas meia duzia de pessoas.

Quis dizer que estamos aqui para ouvir as sugestões dos quase 188.000.000 de brasileiros caso todos seja programadores. Estamos aqui para ouvir, entender e contribuir estamos com vc e com todos os outros. É uma questão de ser brasileiro sim, por que se nós (A maioria dos brasileiros) decidisse que a codificação da API deveria ser com acentuação nós assim faríamos, o problema é que poucas pessoas ajudam como vc. Seguir o padrão mundial é o ideal mas nem sempre o Real. E também se alguém aparecesse com uma solução que fugisse do padrão mundial mas que melhorasse o nosso lado faríamos na mesma hora. As vezes é preciso criar padrões. Não que seja o nosso caso.

sergiotaborda wrote:
Pareceu-me haver uma preocupação com o seguimento de padrões relativos ao dominio ( os padrões das associações de bancos) e isso é bom. Seguir padrões como small data types, etc.. Tudo isso é bom. Mas se não for acompanhado de uma normal de design vai tudo para o lixo. E por "norma" me refiro a algo imparcial, aceite e usado pela maioria

Olha só, até agora a maioria aqui é vc. Mais uma vez obrigado pelo feedback. Sim e tiny types não era padrão algum até pouco tempo, tipo, um ano.

sergiotaborda wrote:
Por exemplo, não fazia muito sentido ter smal data types mutáveis. Eu desconfiei- e já confirou- que é por causa do hibernate ,etc..
Isso é uma falha no design. É API leakage. É preocupar-se demais com o como a para o quê a API irá ser usada. É bom fornecer ganchos mas não é bom supor demais ( early otimization) Por exemplo, bastaria os small data types serem extenciveis para que, quem precisar, os estenda e torne compativel com o hibernate. Ou a propria API pode ter um pacote de compatibilidade desse tipo.
Mas não precisa fazer parte do core da API.

Da pra dar um exemplo essa não ficou muito claro, por que não faz muito sentido ser mutável?

Fala galera...

Pessoal, gostaria primeiramente de agradecer o feedback aí de vocês, Isso é muito importante para que a biblioteca Bobepo e o Projeto JRimum como um todo possa evoluir.

Estou observando cada post, assim como meus companheiros de projeto, e tenham certeza que tudo o que vocês falaram por aqui vai ser abordado nos encontros do grupo JRimum.

Gilmar e Rômulo já responderam a vários questionamentos, então não vou ser redundante, mas quero fazer apenas um pequeno comentário sobre:

boaglio wrote:
Pelo que vi ele tem um projeto chamado Bopepo que faz a mesma coisa que o JBoleto faz...

Não! Não faz a mesma coisa! O fato de gerar boletos bancários é uma característica que as bibliotecas Bopepo e JBoleto têem em comum, entretanto o Bopepo é bem diferente em vários aspectos, como por exemplo no design das classes (visando reuso), documentação, e principalmente no tocante aos recursos de "personalização livre do boleto" e "flexibilidade".

Isto que estou falando pode ser visto de maneira bem clara nos novos tutoriais que acabei de disponibilizar no site do grupo JRimum:
Gerando boletos bancários: Boleto em 3 minutos!
Gerando boletos personalizados: Boleto personalizado com imagens, textos estáticos e dinâmicos definidos "a mão livre" pelo usuário.

Dêem uma olhada nos vídeos, sobretudo no Gerando boletos personalizados que vocês vão começar a descobrir algumas das diferenças ente Bopepo e JBoleto.

Um abraço a todos.
Grato pelo feedback.

Notícias, artigos e o maior fórum brasileiro sobre Java