| Autor |
Mensagem |
|
|
rodrigoy wrote:
É difícil imaginar uma situação que você necessite demonstrar isso no modelo. Tente imaginar um requisito que te force a usar o pattern prototype... Esse pattern fornece uma solução para a implementação e não para a análise.
Requisito:
Suponhamos que estou desenvolvendo uma aplicação que manipula quadrados. O usuário tem como um de seus objetivos configurar um tamanho, cor, textura e etc.. para que seus quadrados já iniciem desta forma.
"Este objetivo já me leva a pensar em usar um prototipo no meu projeto".
Esse pattern fornece uma solução para projeto, como conseguencia seu projeto vai refletir na sua implementação.
Padrões de Projeto antes de tudo fornecem soluções para projeto, e não fornece uma solução para análise. Se pensarmos que a fase de análise tem um objetivo totalmente diferente da de projeto.
rodrigoy wrote:
É mais válido fazer o modelo se aproximar dos requisitos do que do código. Isso garante que você não vai se aprofundar demais no design. Já ouviu falar na expressão "o analista está programando no Rose?!?". Basicamente é o sintoma do BigDesignUpFront....
UML=Ferramenta de Análise
UML para mim é uma ferramenta de análise/projeto.
Por exemplo na fase de analise eu utilizaria a uml para fazer um diagrama de classes conceituais(Modelo de dominio) que estara bem proximo dos meus requisitos, alias este modelo representara meu problema real.
Agora na fase de projeto eu utilizaria a uml para fazer um diagrama de classes de projeto que estara bem proximo da estrutura que eu vou implementar. Esta fase transforma seu proplema real em "computavel", ou seja, faz com que ele possa ser resolvido com logica computacional. Nesta fase voce pode ate usar uma tecnica como diminuição do hiato de representação, que faz com que seu projeto se aproxime do seu dominio.
Coisas como essa voce encontra em varios livros como Utilizando UML e padrões 2 ed LARMAN.
Agora se isso tudo é um exagero ou não é uma outra conversa.
Só fiquei um pouco espantado quando você disse que padrões de projeto fornece uma solução para a implementação e UML=Ferramenta de Análise.
|
 |
|
|
A questão é se no meu projeto eu descubro que minha classe deve usar o padrão prototipo eu defino um interface qualquer para representar isso ou eu utilizo a inteface clonable fornecida pelo java??
|
|
|
|
|
Concordo que o projeto não deve estar preso a implementação, mas sera que tem como fazer algo generico não simplista que pode ser implementado em qualquer linguagem?
|
|
|
|
Luca wrote:
Preferir composição à herança é historicamente a primeira manifestação de programar para interfaces. E o que você pediu foi a história.
Acho que uma coisa não tem muito a ver com a outra trocando em miudos voce pode programar para a inteface de uma classe pai e utilizar uma classe filha em run time. Por tanto a herança não prejudica a programação para interface.
Preferir composição à herança é muito mencionado pois pessoas utilizam herança para implementar o conceito de papel que é uma forma ruim de se implementar papel.
Ao meu ver programar para interface surgiu para ajudar as pessoas programar de forma melhor com encapsulamento não só para se utilizar de polimorfismo.
O maior beneficio de se programar para interface é controlar o efeito colateral de alterações, ou seja utilizar encapsulamento!
Na verdade tem muitos benefícios até quando você utiliza abstração vc programa para interface...
|
|
|
|
Estou tentando iniciar um modelo no Enterprise Architect, só que não estou conseguindo utilizar as classe base do Java como String.
Alguem sabe se tem como adicionar uma biblioteca, ou seja, alguem sabe como eu faço para utilizar as classes fornecidas pelo java dentro do EA?
Se algume puder ajudar....
|
|
|
|
AllMighty wrote:
Outra descrição útil é do Ralph Johson no wiki original:
Ralph Johnson wrote:In MVC, the Controller is a strategy that the view uses to handle user input. In the original MVC, it polls for user actions, but it can also be event-driven. The purpose is to handle fairly low-level events.
Fowler e Larman utilizam essa visão que o controlador é uma estratégia da view.
AllMighty wrote:
Glenn Krasner e Stephen Pope wrote:Controllers contain the interface between the associated models and views and the input device (e.g. keyboard, pointing device, time). Controllers also deal with scheduling interactions with other View-Controller paris: they track mouse movement between application views and implemetn messages for mouse button activity and input from the input sensor.
Muito bacana esta descrição porem não consegui entender o que ele quis passar aqui:
Controllers also deal with scheduling interactions with other View-Controller paris: they track mouse movement between application views and implemetn messages for mouse button activity and input from the input sensor.
Ele esta dizendo que controladores tratam tambem de interações entre views-controles, como por exemplo utilizar dados de outra view ou estartar algo em outra view ou até mesmo controlar transições de janelas? 
Ae AllMighty obrigado mesmo pela força que vc tem me dado te devo essa...
|
|
|
|
O trabalho do controle não é:
1. Receber uma ação;
2. Extrair os dados da view para que a ação seja efetuada no controle;
3. Validar os dados extraidos da view;
4. Executar a ação no modelo.
Sera que as responsabilidades não são essas?
Porque se definimos legal as responsábilidade dele podemos fazer algo generico.
Alguém sabe onde eu encontro as especificações das responsábilidades do MVC, que não seja dizer a view tem a responsabilidade de apresentar os dados, o controle tem a responsabilidade de controlar a view e o model tem a responsábilidade de fornecer uma indireção para a aplicação.
Todos os autores que eu li dão essas resposábilidades vagas como em:
Padrões de aplicações corporativas FOWLER
UML e Padrões LARMAN
Aprenda OO em 21 dias SINTES
Ainda não tive a oportunidade de ver no POSA que é o livro que o FOWLER recomenda como referencia para MVC, se alguem puder me passar o que ele diz lá.
Espero que vcs opinem...
[]s
|
|
|
|
kuchma wrote:
brunohansen wrote:Se alguém quiser opinar me ajudaria muito!
Bom, se eh pra dar opiniao...
Se voce vai desenvolver usando MVC parece natural que seja o Controller que gerencie isso. As Views (telas) apresentam os dados, os Models (negocio) representam os dados e o (ou os) Controller fazem o meio-de-campo, que poderia incluir o controle do fluxo da aplicacao (qual tela vai pra onde).
Marcio Kuchma
Antes de tudo obrigado por opinar...
Mas assim eu não estaria gerando uma certa dependência entre view e controle?
Eu também pensei em colocar as transições no controler porém me surgiram algumas dúvidas:
1- Se eu mudar a view grafica por uma uma view de linha de comando será que as transições continuarão sendo executadas da mesma forma? como eu generalizaria o controle de transição de views para eu poder trocar de view sem trocar o controle junto... Se tiver que trocar os dois juntos é um proble digno de refatoração dale "rifle";
2- Se eu tenho duas views totalmente iguais em termo de funcionalidade a única coisa que muda é a transição de janelas "As ordens que eu posso abrir as janelas são diferentes". Eu teria realmente a necessidade de criar dois controles?
Hoje eu estou me perguntando por que não colocar o gerenciamento de transição de janela na propria view alem do mais cada view pode ter uma transição diferente.
Derrepente seria uma boa criar um mecanismo proprio para gerenciar somente trancição entre janelas.
[]s
|
|
|
|
Giuliano Mega wrote:
Bruno, sem querer ser chato, mas transição de quê entre janelas?
Transição de uma janela para outra.(Sequência de apresentação de janelas)
[]s
|
|
|
|
Estou iniciando um projeto da camada de apresentação de um software!
Estou afim de usar MVC dentro desta camada!
Só que me surgiu uma dúvida.
Quem controla a transição entre as janelas?
Se alguém quiser opinar me ajudaria muito!
[]s
|
|
|
|
Uma coisa que não me sinto confortavel é fazer com que objetos de negocio tenham contato com repositórios.
Será que tem uma forma boa de fazer com que objetos de negocio não tenham contato com o repositório?
Será que persistir dados é um problema de negocio???
Será que persistir dados é um problema de aplicação???
Se for de negocio justifica meus objetos de negocio terem contato com o repositorio, agora se for um problema de aplicação já não justifica muito...
Se alguém puder comentar sobre esse problema e me ajudar a refletir melhor...
abraços...
Ahhhhh Shoes parabéns pela matéria! Fowler na mente!
|
|
|
|
microfilo wrote:Rose!
Que rose voce usa?? roda no xp home??
|
|
|
|
klebergf, Rafael Nunes
Vou dra uma olhada no EA pelo o que vcs falaram parece bom....
|
|
|
|
ramilani12 wrote:utilizo JUDE e até agora atendeu as minhas necessidades , mas o Enterprise Architect e muito bom pena é o preço mas só roda em Windows , tentamos rodar Enterprise no Linux com emulador Windows foi uma catastrofe ..utilizo o JUDE devido indepedencia de platafroma desenvolvido em JAVA ...
O problema no JUDE é o engenharia reversa quando funções tem throws. A ultima vez que eu olhei ele ele tava na versão 2.5.1
|
|
|
|
Vc já usou ou usa isso? Da ultima vez que eu dei uma futucada nele, ele tinha mais BUG que o WINDOWS!!
|
|
|
|