Que padrão é esse? :D

Luca wrote:Olá

O procedimento correto é imaginar que se ninguém respondeu é porque ninguém sabe e então a gente deve ir no google mesmo. Bom é quando o cara volta aqui e coloca a solução que ele achou no google. Este é o espírito de comunidade.

[]s
Luca

Concordo plenamente, mas pode acontecer de, por um azar dos Deuses no dia em que o coitado postou não tinha ninguém conectado que soubesse a resposta pra ajudar. Por exemplo, só 2 dias depois alguém que saberia conectou e daí já era...

Ok, tá explicado.

Galera eu fio no gogle e achei uns links legais.
Também fui no gtk-gnutella e achei uns pdf's ilegais,

pelo que eu li (e continuo lendo) meu problema aqui é a alta acoplação dos objetos, isto é, meu GOD object sabe demais sobre os outros objetos; GOD esse, que, aliás, é um tipo de Command:

http://en.wikipedia.org/wiki/Command_pattern

isso se reforça quando lembramos que todas as ações do sistema (abriSessao, fecharSessao, tryLogin, etc.) estão aqui. A diferença para um Command decente que você conheça é que eu só tenho um (anti-pattern GOD) e possui aquela complicação do alto acoplamento, ou seja, ele realmente sabe que os componentes com que ele lida são JFrames, Bancos, e tais objetos, que recebem instâncias dele também o conhecem muito profundamente; tem acesso a toda sua interface pública. No caso dos membros dele é pior porque não só a interface pública de uma tela de login fica exposta como também certos detalhes da classe pai (JFrame) ficam visíveis. Como eu disse alta acomplação; "só dá certo se for com esse aí".

para sanar um pouco a solução seria quebrar a interface pública do pessoal, de forma a garantir uma certa abstração (janela de login recebe no construtor algum fulano que implemente uma interface dedicada com métodos exclusivos disso; a própria janela de login deve implementar chamadas padrão para uma tela de login; assim não importa se for feito em SWT, JCurses ou o escambau) nas funcionalidades do sistema.

Todavia ainda não encontrei uma forma decente de "dar boot" no sistema;

mesmo que meu GOD object não existisse:

1- Eu ainda ia ter de instanciar as coisas em algum lugar. ainda não li o suficiente para resolver essa parte.

2- Depois de instanciados, eles teriam de se comunicar (os dados do formuláro para o banco, por exemplo) e trocar informações. estou aqui na mesma situação do ítem antenrior.

O que eu posso dizer até agora é que do jeto que está a coisa funciona, mas seria legal a manutenção ser simplificada.

Luca wrote:Olá

Sombriks wrote:É isso aí, ninguém tem contra-cenário pra mim? Muito legal o senso de comunidade da comunidade...

Penso que você não leu minha resposta e então vou repetir:

Como melhorar? Simples: Fazer como todo mundo faz com cada classe com sua responsabilidade.

É feio dar "UP" em posts de forum.

[]s
Luca

Luca, eu sinto dizer mas essa forma simples de melhorar remove não mais que um pingo d'agua num oceano. Pôxa, o que custa dar links de coisas que já leu, contar situações vividas?

Luca wrote:Olá

O procedimento correto é imaginar que se ninguém respondeu é porque ninguém sabe e então a gente deve ir no google mesmo. Bom é quando o cara volta aqui e coloca a solução que ele achou no google. Este é o espírito de comunidade.

[]s
Luca

me desculpe pelo "UP", realmente não cometerei esse tipo de gafe denovo,

Pra finalizar, se alguém está, ou já passou por cenário semelhante (Objetão com tudo dentro regendo a banda de janelas e banco,

), por favor deixe a sua contribuição.

Diga lá,

O que eu faria no seu caso seria esquecer, por enquanto, esse projeto, e me dedicar a estudar padrões de software por um tempo. Depois que você vir o monte de idéias legais que existem por aí, você vai ter ânimo pra implementar uma versão 2.0 desse sistema, agora fazendo as coisas de maneira mais organizada.

Dê uma lida no livro 'Design Patterns', do Gamma.
Com certeza vai te ajudar a pensar melhor.

Té mais,

iSoron wrote:Diga lá,

O que eu faria no seu caso seria esquecer, por enquanto, esse projeto, e me dedicar a estudar padrões de software por um tempo. Depois que você vir o monte de idéias legais que existem por aí, você vai ter ânimo pra implementar uma versão 2.0 desse sistema, agora fazendo as coisas de maneira mais organizada.

Dê uma lida no livro 'Design Patterns', do Gamma.
Com certeza vai te ajudar a pensar melhor.

Té mais,

Acredito que o chefe/cliente dele não vá gostar mto da idéia de deixar o projeto de lado

Vai "distribuindo os poderes" desse GOD object entre outros objetos, comece pela parte de persistencia que, acredito eu, seja a mais fácil de fazer isso

Sombriks wrote:1- Eu ainda ia ter de instanciar as coisas em algum lugar. ainda não li o suficiente para resolver essa parte.

Procure algo sobre fábricas ou injeção de dependências.

Sombriks wrote:2- Depois de instanciados, eles teriam de se comunicar (os dados do formuláro para o banco, por exemplo) e trocar informações. estou aqui na mesma situação do ítem antenrior.

Model-view-presenter, presentation model, e aqui.

Entusiasta Java Membro desde: 21/11/2006 16:33:11 Mensagens: 20 Offline

Cara, sei muuuito menos que a maioria dos que postaram aqui.
Realmente estou longe de desenvolvedores como o Luca, e o cv.
(Realmente eu tenho visto muitos posts deles, e com certeza, os caras sabem o que falam x])
Tá. Agora vamos ver se consigo ajudar com o pouco que sei.
Existe um modelo de desenvolvimento, chamado Model-View-Controller. Consiste em construir sua aplicação de modo que uma camada (uma classe) cuide do Modelo, que será como ela acessará os dados (trocando em miúdos, a classe que se conecta e passa/recebe dados do banco), uma classe controller que irá receber os dados inseridos pelo usuário através da camada View, ou as requisições de dados feitas pelo usuário, e que irá repassar esse pedido a classe modelo, fazendo a ponte entre essa e a classe View, que será a classe de visualização, que cuida das janelas e interação com o usuário. Na prática, o Usuário irá "ver" através da classe view; Essa, por sua vez, repassa os dados que o usuário insere para a classe controller, que irá acessar a classe modelo e dizer para ela o que tem q ser feito no nosso banco.
E para a questão de ter que instanciar em algum lugar.. talvez vc se depare com o problema de não poder instanciar a classe de acesso ao banco toda vez que você for chamar um método da mesma, pois para isso basta uma instância. Isso, já vou te adiantar, se resolve com a Design pattern Singleton. Tem sobre ela aqui nos artigos da GUJ.

Ah, e acessa o www.jairelton.com. Tem ótimos tutoriais com voz e vídeo sobre tudo isso que você tá procurando.
Bom, sei que é pouco, e não posso garantir que está correto. Mas creito que já te dê um rumo pra onde estudar. Se falei besteira, me corrijam!

E a propósito, dá um pulo no www.netbeans.org e vê os tutoriais; Ajuda muito a entender como desenvolver a parte de GUI e como conectar com o banco.. sem fazer nada de errado

Um grande abraço, espero ter ajudado.

Douglas Vargas

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