| Autor |
Mensagem |
|
|
dudaskank wrote:A resposta do cadu555 é a melhor de todas! São as mesmas que eu daria! hahahaha
Pô, tem um monte de lixo free por aí.
dudaskank wrote:Python tem guj?
Deve ter gup... 
Todos os motivos do LIPE são bons pra usar Java, mas não dá pra esquecer que não é nenhuma bala de prata. Tem alguns problemas que podem ser resolvidos muito mais facilmente que com outras linguagens.
Sou a favor da liberdade de escolha, e de escrever o mínimo de código possível. Ou seja, se tem lib, pegue a lib. Se dá pra fazer em Python com 20 linhas, faça em Python. Se der pra fazer bem mais rápido e robusto em .NET (se houver uma noite fria no inferno), faça em .NET.
O importante é não ficar preso, nem fazer trabalhos chatos só pra manter a homogeneidade.
[]s!
|
 |
|
|
Cara, não é isso...
pq vc não adiciona os seus shapes como componentes filhos?
Tem umas propriedades do JPanel que vc tem que prestar atenção:
1. size(Dimension): um repaint() só atualiza a área visível do componente. Mas da primeira vez, ele pinta de qq jeito. Se vc desenhou pra fora do tamando do componente da primeira vez, ele pinta, e vc vê o resultado.
2. opaque(boolean) dos filhos: a área visível é o tamanho do componente menos tudo o que está em cima dele e é opaco. Se vc tem filhos opacos, o Swing só desenha os filhos, e pode estar pulando o seu JPanel.
3. tamanho do pai: muitos componentes têm um viewport separado do size, é o caso do JScrollPane por exemplo, a AWT só redesenha o pedaço que está visível. Dependendo do layout que o pai do seu JPanel tem, vc pode não estar recebendo a área inteira.
Outra coisa que vc pode fazer é não pintar o fundo na mão, setar o background pra uma cor nada a ver (eu gosto de Color.CYAN e Color.YELLOW) quando constrói o JPanel e chamar super.paintComponent(g). Assim vc vê o que é que ele tá pintando de verdade...
[]s
|
|
|
|
ClassOnLine, vc é um bot?  Já tem 1.4.2 final por aí...
Dirk, use o Ant. Dirk, use o Ant. Dirk, use o Ant...
irk, use o Ant. Dirk, use o Ant. Dirk, use o Ant...D
rk, use o Ant. Dirk, use o Ant. Dirk, use o Ant...Di
k, use o Ant. Dirk, use o Ant. Dirk, use o Ant...Dir
, use o Ant. Dirk, use o Ant. Dirk, use o Ant...Dirk
[]s!
|
|
|
|
|
que vergonha, postar o dever de casa no GUJ...
|
|
|
|
Hmmm... boa sorte, cara... achar uma lib pra XML que funciona com java 1.2 é foda...
Uma coisa que vc pode fazer, que dá um trabalhão, é pegar uma lib pra dom (e.g. dom4j) e montar vc mesmo o DOM pra esses objetos...
algo pronto vai ser difícil. Aliás, nem o DOM4J eu sei se roda com 1.2...
Mas eu acho muito estranho (embora eu acredite em você, aqui tb usamos o Weblogic num projeto e eu sei como é isso) não conseguir rodar sob a JVM 1.4.
Ah, outra coisa que vc pode fazer, é seriar os objetos e mandar num stream pra um servidor que tá rodando em outra JVM, e gerar o XML com XStream... ou usa RMI!! 
[]s
|
|
|
|
Legal essa discussão...
Mas acho que essa dúvida já está na frente de uma outra, que deveria ter surgido bem antes: por que Ponto, Reta e Polígono são irmãs?
Separar as responsabilidades é muito importante. Me parece que vc está desenhando de baixo pra cima, e fez uma escolha com grandes implicações logo no começo: usar herança pra separar preocupações...
Se sua idéia é reaproveitar código, recomendo que vc imagine (não precisa implementar) interfaces com as suas preocupações. Por exemplo, vc quer desenhar esses objetos na tela? Implementa uma interface Desenhavel. Que ela tem que ter?
Não vejo motivo pra não considerar Reta uma subclasse de Polígono, e Ponto uma sublcasse de Reta. Mas tb não vejo grandes motivos pra ter sequer uma herança aí... se a herança não te ajuda a reaproveitar código, joga ela fora e pega outra idéia!! : ))
Se vc trabalha muito com listas de pontos, recomendo o padrão visitor. Por exemplo:
Outro padrão que tá aí e surgiu como mágica é o Strategy: do ponto de vista da operação mover, o que difere um ponto de uma reta de um polígono é o número de pontos!
Mas ainda tá estranho, não tá? Ao longo do desenvolvimento, c pode acabar tirando ponto da hierarquia e dizendo que ele tb implementa Movable e pronto... : )
[]s!
|
|
|
|
Bom, minha primeira sugestão é a seguinte: já que seu sistema é prevalente, vc começa desenhando ele bem simples, sem fazer tanto MVC, isola bem só o view.
O pessoal andou falando sobre modelos de domínio anêmicos, e como a gente vence a tentação de ter várias classes que só guardam dado, não fazem nada.
Já que vc já sabe que vai usar o prevayler, vc pode pensar nas suas transações primeiro, e desenhar o modelo (i.e. a camada Model) baseado no seu conhecimento sobre os comandos que operam nele.
Vai contando como a coisa evolui, pra gente poder dar mais palpite!! (eu adoro dar palpite )
[]s!
|
|
|
|
Bem legal!!
Simples, direto e completo. Tô louco pra ver a parte 2... : )
[]s!
|
|
|
|
Pergunta idiota: vc tem imagens no seu JAR?
Vc compactou as imagens? Vc consegue reduzir o tamanho da maioria dos arquivos sem perder muita qualidade...
Dependendo do target-version do seu applet (1.4.2?), vc pode tentar compactar o jar com pak2000. Nunca fiz, mas a economia é proporcional ao número de classes e referências entre elas (ou seja, bom pra Swing). Mas só 1.4.2 jars compactados assim.
Aliás, que tamanho tá o seu jar, e pra que tamanho vc quer ele??
[]s!
|
|
|
|
Pô, agora fiquei sedento por uma comparação entre isso e Strategy.
O exemplo de acesso ao banco é interessante, mas vejo uns problemas:
1. como se lida com falhas? Se meu query() não faz nada, posso executar o process()?
2. Vou acabar tendo uma hierarquia meio besta: provavelmente eu vou ter uma classe que implementa connect() e disconnect(), da qual eu derivo as outras.
3. Me soa meio AOP de pobre.
Desculpa meter o pau logo de cara, mas eu quero é entender melhor, se é um padrão, é pq traz vantagens. Acho que faltou discutir as forças envolvidas na adoção desse pattern, e as vantagens de seguir esse caminho...
aquelão!
|
|
|
|
Isso me lembra a discussão sobre modelo de domínio anêmico.
Acho que se vc tem BOs ricos, que usam serviços de outros BOs e objetos num container IoC, vale usar uma Factory.
Ou melhor dizendo, vale usar o padrão ''Factory'', que pode ser um método de um objeto que também está no container!! : )
Ou seja, sua factory pode passar para o BO, além dos valores que vêm do VO, wrappers e objetos do container.
Por exemplo, se seu BO faz prevalência, ele pode ter um construtor que recebe um Prevayler, e a Factory fica meio assim:
Hmmm, não gostei. Melhor seria:
E aih, q vcs me dizem?? Já sei que tem um antipattern aí no meio, a Factory não faz nada com o objeto Prevayler, ela só passa pros filhos. Mas não parei pra pensar se dá pra fazer diferente...
[]s!
|
|
|
|
Hmmm, mais ou menos...
esse maldito actions.xml, podia muito bem ser gerado automaticamente. Ter que escrever na mão é um saco, aparecem erros de digitação (tipo MyAtcion), e são sempre muito parecidos.
Pensa assim:
Isso não é muito menor que o xml:
Tem todos os problemas de auto-geração de código, e o fato do nome dos templates estar no source engessa muito. Mas imagina que eu tenho um task pro Ant que me gera um actions.xml e esqueletos pros meus templates? Sei não...
Pra mim, quanto menos XML melhor. Se bem que dá pra fazer um task pro Ant que gera um esqueleto pro actions.xml. Se for bem feito, dá pra fazer até ele só atualizar o que for novo!!
Hmmmmm.... 
[]s!
|
|
|
|
Cara, adorei essa thread!
Eu tb nunca tinha lido sobre o modelo anêmico, e percebi que grande parte das coisas que eu tenho desenvolvido sofre um pouco desse mal.
Geralmente a gente fala de separação de interesses (Separation of Concerns, até hoje não achei uma tradução definitiva pra isso) e acaba separando dado do código.
gcobr wrote:- Teriamos objetos do domínio acessando Session Beans para buscar/validar informações e isso parece muito estranho.
Pois eh, olha como já tá na cabeça que os objetos de domínio são por natureza passivos...
Eu acho que o vício (bom, hoje, e nesse contexto, parece um vício, quem sabe em alguns anos volta a ser moda) surge em parte pela grande quantidade de material que a gente lê e que é feita pensando num ambiente web, com HTTP, etc. Quase todos os meus value objects são pensados pra mapear valores que vêm de um POST, ou que vão ser exibidos numa página. Esses caras não têm nenhum motivo pra implementar regras de negócio.
Na verdade, escrevi tudo isso pra fazer essa pergunta: esses objetos devem e serão sempre value objects? Alguém já implementou algo diferente?
[]s!
|
|
|
|
danieldestro wrote:
Ou seja, é só permitir que clientes novos de uma locadora, tbm possa locar em outra...
Ah, bom, então não tem nem conflito! Bom, não sei, dá pra alugar em uma e devolver na outra??
Se a base compartilhada é só a de usuários, é sussa...
sobre discar com java não sei nada, sei que existe uma tal de java.comm pra falar com modem...
[]s!
|
|
|
|
Gente, ele tá perguntando sobre GridBagLayout...
Curinga, vc vai ter que olhar o Javadoc da GridBagConstraints (algo me diz que pela idade do post, ele já fez isso), particularmente ipadx e ipady, além de weight e anchor. GridBagLayout é pensado pra usar no NetBeans, é desumano trabalhar com ele na mão.
Vale mais vc ter uma combinação de JPanels com BorderLayout e JPanels com GridLayout, instâncias de Box tb ajudam muito.
[]s
|
|
|
|
|
|