| Autor |
Mensagem |
|
|
Luca wrote:Olá
sergiotaborda wrote:Então , hoje em dia, o correto é usar os termos TO e VO
Leia o blog do Phillipe Calçado para entender porque raramente se usa VO e TO do jeito descrito nos design patterns da Sun.
[]s
Luca
Qual blog ?
A pergunta era sobre conceitos , não sobre uso
|
 |
|
|
afsrj wrote:Resumo bom...mas acho que o POJO e o VO estao errados...Ou nao?!
Esclarecendo:
Suponho que diz que VO está errado poruqe vc associa VO como sendo a mesma coisa que DTO. Na verdade isso é um erro histórico que não é mais correto. No principio dos tempos DTO era sinónimo de VO, mas também era sinónimo de muitas outras coisas. Várias tecnologias usavam o termo DTO para se referirem a coisas diferentes. Então o termo DTO transformou-se num problema e atualmente considerado obsuleto. Para subtituir veio o termo TO que não deixa duvidas do que é. O termo VO tem realmente outro significado que não é sinónimo deste. Veja http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
Então , hoje em dia, o correto é usar os termos TO e VO e não DTO pq causa confusão.
Quanto ao POJO não sei por quê você acha que possa estar errado. Veja http://en.wikipedia.org/wiki/Plain_Old_Java_Object
|
|
|
|
pcalcado wrote:Estão corretos exceto que JavaBeans, na verdade, é uma especificação de modelo de componentes manipuláveis por intefaces gráficas falida e que o nome é utilizado hoje vulgarmente para qualquer coisa que obedeça a nomenclatura de get/set.
É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html
|
|
|
|
ViniGodoy wrote:O princípio é o seguinte, todo Vector é um Stack, mas nem todo Stack é um Vector. Isso porque Vector é uma superclasse de Stack.
Não será que é ao contrário? Veja bem, se Stack herda de Vector , Todos os Stack são tb Vector. Mas nenhum outro Vector é Stack excepto o poprio Stack.
Se todo o Vector fosse Stack, como vc afirma então se: ClassX extends Vector , ClassX é um Vector e pelo que vc disse ClassX seria um Stack. Isso é falso. ClassX não tem o método pop(), por exemplo.
|
|
|
|
pedromv wrote:Olá galera do GUJ.
Estou com dúvidas conceituais sobre os 4 termos citados no título. Afinal de contas, quais são as diferenças e semelhanças entre essa sopa de letrinhas que eu citei? O que significa cada um desses termos e onde são usados?
Gostaria de pedir para que ninguém respondesse no "achismo", pois isso já aconteceu em outros tópicos relacionados e no fim das contas eu não consegui sanar minha dúvida.
Grato
VO = Value Object. Objeto de valor. É um objeto normalmente imutável (não tem set) que serve para conter um valor. Exemplos: Integer, BigDecimal (outros exemplos incluir os design patterns Money e Range)
DTO ou apenas TO = (Data) Transfer Object. Objecto de transferencia. Serve para enviar dados entre camadas do sistema que podem ou não estar na mesma máquina. São Serializáveis.
POJO = Plain Old Java Object (Velho e Simples Objecto Java) é um referencia a objectos que não dependem da herança de interfaces ou classes de frameworks externos.
JavaBean = Padrão para escrever objetos que contém estado. É uma especificação. Algumas coisas necessárias são : Construtor publico sem argumentos e metodos de acesso começam com set/get, mas tem mais.
|
|
|
|
ViniGodoy wrote:
Sérgio, falou você dizer uma coisa... quais são as coisas que você odeia/não gosta no Java?
Quando eu souber de alguma vc será o primeiro a saber.
|
|
|
|
ViniGodoy wrote:
Mas até certo ponto concordo com você. Se olhar da perspectiva do Java e do futuro, é melhor mesmo que os unsigned fiquem de fora. Esse é uma coisa que odeio, mas aceito.  Por isso que eu ressaltei que a raiva só vem "quando estou interagindo com aplicações C/C++".
Então o titulo deste topico deveria ser "coisas que odeio no C quando interajo com ele usando Java"
Como você diz que "não é suposto" um JTextField não ter algo assim?
Porque o JTextField é o controlador. O modelo que deve ter um forma de validar isso. Como tal vc tem que colocar essa funcinalidade do Document.
Mas um document não tem limite (já imaginou um word com limite de caracteres?) é a aplicação do document, a sua aplicação que quer limitar. E então vc deve criar um document especifico. Que é o que todo o mundo faz. Se vc me disser que poderia existir um Document com essa capacidade, tudo bem. Isso cai no mesmo requisito do JTreeTable. Mas que é uma coisa odiável é dizer demais.
Eu não gosto de switch e também não recorro a ifs tão frequentemente. Depois de patterns como State e Strategy eles quase não são necessários. Aliás, não é uma das refatorações do catálogo do Fowler?
Eu não falei em retirar o switch. Falei em retirar o break e o fall through do switch. Também não falei em syntax suggar, nem em usar ele com Strings, isso foi por sua própria conta.
O poder do switch vem do fall throught , tirando isso o switch vira um if/else if simplificado , ou seja, vira sintax sugar. E nesse caso, adicionar mais sintaz sugar como o uso de String não faz mal nenhum.
|
|
|
|
|
Vc pode resolver seu problema com a API HTTPClient da Apache. É bem simples de usar e vc pode fazer post, get , o que vc quiser.
|
|
|
|
fabgp2001 wrote: Olá,
Eu queria saber como o cara instala uma aplicacao grafica substituindo um console num servidor sem ambiente grafico instalado.
]['s
Nesse caso limpar a tela tb não será muito imporante , será ?
|
|
|
|
ViniGodoy wrote:
sergiotaborda wrote:
mas é claro que são. Vc está tentando usar C++ com java , o que vc esperava ? A questão é que a falta de unsinged no java não afecta o java, por isso não é um problema no java. O problema é que C usa unsigned, o problema é do C. Quando vc vai tentar misturar os dois , como o C tem problemas, eles aparecem na integração. Agora , char é unsigned e é um numero sim. Faça 'a' + 1 e verá que o o java faz a conta.
Se não gosta de workarrounds não use C com java.
Bom, quem me dera poder sempre escolher com que servidor eu iria me conectar. Não fui eu quem programou o servidor. No nosso caso, não teria nem cabimento alterar a linguagem do cliente, nem reprogramar o servidor.
Mas foi vc que escolheu java ... se sabia que o servidor era C pq não usou C tb ?
Agora vc vai responder que prefere java por uma serie de razões... bom, então isso so leva a concluir que C é mais odiável que java. E isso so reforça a minha afirmação que o java não precisa ter unsigned. aliás unsigned é uma aberração da natureza. o C só tem isso pq ele gosta de dar liberdade total para o programador fazer as cagadas que quiser.
Quando vc programava em C ou C++ vc ouvioa falar em desing patterns ?
Isso so significa que C nunca foi preocupado com fazer a coisa certa, apenas com fazer a coisa funcionar.
sergiotaborda wrote:
Caro, deamons não têm interface e não escrevem para o console, escrevem para um arquivo de log. portanto, esse não é um exemplo da necessidade de um comando para limpar a tela...
Mas , mesmo que fosse, mais um vez seria o exeplo de como não fazer um demon e por isso, vc cai em problemas, que se vc fizer direito não existem.
Acho que você não pegou o espírito da coisa. Isso era um exemplo. E não foi o único que dei. Veja como controlar o tamanho do texto de um textfield! Você tem que recorrer a interface document, escrever um monte de código, quando na maioria das aplicações ele simplesmente tem um setLength().
O exemplo do textfield é igualmente inutil. Não é suposto um textfield ter limite. MAS bolas java é OO se vc quer ter um setLength, crie um! Isso seria um probema se não fosse possivel solucioná-lo facilmente.
Mas esse problema advem de uma cultura no brasil de super protecionismo. Em java isso não é mais ncessário. Existe uma coisa chamada validação. Se o cara escreveu mais do que devia o problema é dele. simplesmete não aceite. (isso é o que vc faz em web) Agora, se vc gosta de ser user friendly, então tudo bem, seja, faça como eu e adicione essas funcionalidades por conta. Afinal com OO vc so tem que fazer isso uma vez. ( e na web use javascript, mas lembre-se que o javascript pode ser desabiliado)
sergiotaborda wrote:
Eu já fiz isso, e funciona. Não é um workarround.
E como você fez para achar o caminho dos plugins? Funciona sempre, mesmo que o usuário troque o diretório da aplicação? Se funcionar, por favor, me passe o código, gostaria muito de ver isso rodando sem workarounds.
Ora como, da mesma forma que o eclipse. Existe uma estrutura de pastas
os plugins estão numa delas. com file(".") obtém a raiz e a partir dai é facil.
sergiotaborda wrote:
Vc não quer fall through ? use if/else if
Depois de remover o break, removam também os genérics ... afinal podemos codificar tão bem ou melhor sem isso.
Ambos existem para simplificar a vida do programador.
o falal througth é necessário pq minimiza a escrita de código e aumenta a rapidez. Se vc acha que é inutil é pq vc nunca usou. Se vc acha perigoso ... bem .. threads tb é perigoso e não vejo ninguem se quixar que java tem threads e não deveria ter pq é perigoso... se vc programa bem, fall throught nunca é um problema. Se vc programa mal, ai sim, mas ai vc aprender a programar melhor. Não é um problema da linguagem.
Nesse caso, talvez fosse melhor voltamos com os ponteiros e as instruções direto em assembly (como o comando asm, do C), não acha?
Acho. Quem não gosta de switch deve usar C ou assembly mesmo.
Eu programava em VB e tinha uma coisa chamada select case. Era muito util e não tinha fall. Quando aprendi java achei um saco o switch. Achei que nunca o iria usar. Afinal so pode usar com costantes etc... mas depois que usei as primeira vezes vi que faz todo o sentido e era o select case que estava errado. Se a SUN dicidir adicionar um sintax sugar para switch com string tudo bem , o groovy tem isso. Mas retirar o switch é um tiro no pé.
Mas como eu disse antes, se não gosta de switch , use if / else if que não tem como errar.
Eu tb não gostava, agora acho uma aberração ouvir vc dizer que não gosta ... como os tempos mundam ....
|
|
|
|
ViniGodoy wrote:
sergiotaborda wrote:
Porque raios vc faz um wait baseado num calculo ??
Simples, você pode estar fazendo um wait baseado num timeout máximo. E gostaria que esse wait aguardasse somente até o restante do tempo.
Esse timeout tem de ser calculado, até porque o wait está sujeito a spurious wakeups como eu mesmo ressaltei.
Gostaria de um exemplo da necessidade disso. Está-me a parecer uma coisa demasiado especifica ( e que provavelmente pode ter outro tipo de implemenação) contudo, vc pode criar seu proprio método wait e usuá-lo dentro do método vc coloca essas logicas que vc não gosta.
sergiotaborda wrote:
use char. char é unsigned
(...)
Entretanto, tanto a sua solução, quanto a dos livros, são workarounds. (...)E o que não gosto é ter de recorrer a um workaround.
mas é claro que são. Vc está tentando usar C++ com java , o que vc esperava ? A questão é que a falta de unsinged no java não afecta o java, por isso não é um problema no java. O problema é que C usa unsigned, o problema é do C. Quando vc vai tentar misturar os dois , como o C tem problemas, eles aparecem na integração. Agora , char é unsigned e é um numero sim. Faça 'a' + 1 e verá que o o java faz a conta.
Se não gosta de workarrounds não use C com java.
Não, não faço muitas aplicações no console. Esse foi apenas um exemplo. E essa é uma pergunta clássica de alunos que estão aprendendo java... Agora, mesmo o unix tem diversas aplicações que são estritamente controladas por console e não vejo porque usar o swing quando estiver fazendo uma aplicação que será um deamon ou coisa do gênero.
Caro, deamons não têm interface e não escrevem para o console, escrevem para um arquivo de log. portanto, esse não é um exemplo da necessidade de um comando para limpar a tela...
Mas , mesmo que fosse, mais um vez seria o exeplo de como não fazer um demon e por isso, vc cai em problemas, que se vc fizer direito não existem.
A sua solução também não retorna o local onde a aplicação está gravada, e sim o diretório onde o usuário iniciou a aplicação.
Sendo que o usuário so pode lança a aplicação de onde ela existe , dá no mesmo.
São coisas diferentes. Tente implementar uma aplicação como o eclipse, que possui plugins em uma pasta específica, cada uma com seu arquivo manifest, e você saberá do que estou falando. Você simplesmente não tem como descobrir onde a pasta dos plugins está para ler os manifests e instancia-los com reflexão. A não ser recorrendo a um executável externo ou a perguntar para o usuário durante a primeira inicialização. Novamente, workarounds.
Eu já fiz isso, e funciona. Não é um workarround.
sergiotaborda wrote:
é que podem não existir n bytes para ler...
Nesse caso, eu gostaria de espera-los.
A API já faz isso por vc. Se o array não tem mais bytes é pq não chegaram mais.
sergiotaborda wrote:
Vc não quer fall through ? use if/else if
Depois de remover o break, removam também os genérics ... afinal podemos codificar tão bem ou melhor sem isso.
O que raios os generics tem a ver com o fall through?
Ambos existem para simplificar a vida do programador.
o falal througth é necessário pq minimiza a escrita de código e aumenta a rapidez. Se vc acha que é inutil é pq vc nunca usou. Se vc acha perigoso ... bem .. threads tb é perigoso e não vejo ninguem se quixar que java tem threads e não deveria ter pq é perigoso... se vc programa bem, fall throught nunca é um problema. Se vc programa mal, ai sim, mas ai vc aprender a programar melhor. Não é um problema da linguagem.
sergiotaborda wrote:
Ela está ficando gorda porque os programadores não usam as classes que deveriam, não mudam o código quando algo fica deprecated. E é por causa deles que API é gorda.
Essa foi uma frase injusta. Existem programadores descuidados, mas a razão não é essa. É porque existem sistemas legados e as empresas não podem ficar simplesmente investindo em modifica-los
Razão pela qual a SUN as protege deixando a API gorda.
Se vc gosta desse tipo de protecção, não tem como se queixar que a API é gorda (aliás vc quer incluir JTreTable a fins , o que a deixaria ainda mais gorda)
Se vc não gosta desse tipo de protecção , como eu, gostaria de ver o que é deprecated simplesmente desaparecer.
Se as empresesas não podem usar a versão com os deprecated retirados, não mudem de jvm
E não é xitismo, é que as coisas que foram ditas que sao odiáveis em java, ou não são odiáveis o unão são problemas do java.
|
|
|
|
aleeebr wrote:ola amigos!
pois bem, a duvida eh a seguinte, eu tenho um for que a cada iteração joga termo a termo de uma matriz a uma String, e no final da iteração, uso um setText() para passar a string para o JTextArea, estou usando um wait(500) pra ver cada modificacao, seria um jogo de puzzle
o problema q ta dando q nao muda o JTextArea a cada iteração, tentei com wait, deu excecao IllegalMonitorStateException.
o for está +- assim
O que devo fazer?
Esse erro que vc esta tendo é pq não se pode usar wait sem fazer sincronismo, ou seja usar o bloco synchronized.
Mas usar wait não vai fazer o loop demorar mais. para fazer isso use Thread.sleep(300) (este não precisa de sincronização)
Se vc usar sleep vai provavelmente funcionar, mas se quer alguma coisa temporizada use um Timer (temporizador). E como vc está usado swing, use o timer do swing. Ele gera um evento a cada X milisegundos e ai vc
preenche o texto.
Mas o melhor mesmo era não usar nada disto. simplesmente escreve a matriz inteira no text area e pronto.
|
|
|
|
A certificação não é uma prova de exceções ... é uma prova que tenta avaliar o conhecimento e o verdadeiro conhecimento so se observa em situações muito especificas. Ser especifico é diferente de ser excepcional.
Mas se encontra alguem que acha que ser certificado é simples, que não exige conhecimento e estudo, então que pegue um mock exam por ai e faça. Se nem os criadores do exame tiram 100% é porque não é assim tão simples. Eu tirei 98% no meu , em ingles, e não me pareceu dificil, mas estive meses fazendo mock exames.
O motivo é simplemente incompetencia mental para entender o mundo fora de uma sala de aula. Por isso que quem sai de dentro de uma para o mundo está sempre tão despreparado.
Por outro lado, também é verdade que nada garante que uma pessoa certificada como programador sabe programar. Porque programar é mais que conhecer a linguagem, é conhecer as API e saber fazer algoritmos.
É que a dificição de programador para a SUN é de uma pessoa que apenas escreve código, quanto, como todos sabemos muito bem que um "programador" faz muito mais que isso ( atua como o que a SUN classifica de desenvolvedor).
|
|
|
|
1) Junto estão os fontes de uma implementação minha do padrão Money (dinheiro é diferente de moeda, cuja classe é Currency e é padrão do java)
Ainda não tem todos os comentários , por isso qualquer duvida é só perguntar.
Dinheiro implica o uso de moeda. A Classe não força o use de nenhum classe particular para moeda. Pode usar a sua ppr classe desde que tenha equals bem definido. Se não tiver uma classe especial para isso ,pode usar java.util.Currency para a moeda que quiser.
Lemberem-se que a classe é genérica , para se usada com qualquer moeda.
2) Para mostrar valores monetários num JTextField basta usar um MaskFormat , mas atenção que o o formato é diferente conforme a moeda. Mas se é só para real, é bem simples. Não use R$ pq só atrapalha . Se tiver que mostrar R$ use um JLabel ao lado , ou coisa assim.
|
|
|
|
elomarns wrote:
Luca wrote:Olá
Além da falta de inteiros de 64 bits, o que sempre senti falta no Java foi facilidade de acessar dispositivo periféricos. Não fosse por isto, Java teria sido realmente VB killer.
Pensando a posteriori, teria sido muito melhor que a Sun tivesse investido em facilidade de uso de periféricos TODO o tempo que gastou com J2EE (menos servlets e JMS).
[]s
Luca
Talvez eu esteja falando besteira, bem provável aliás, mas se eu não me engano, o long, que é um tipo inteiro, tem 64 bits.
Exactamente.
byte = 8 bits
short = 16 bits
int = 32 bits
long = 64 bits
|
|
|
|
|
|