quinta-feira, 29 de maio de 2008

Padrão GRASP Polimorfismo

Blog referente a aula do dia 26/05/2008

Padrão GRASP Polimorfismo

Ao falarmos de padrão Polimorfismo , ele já nos aparece como uma solução para um determinado problema.

Como tratar alternativas baseadas no tipo ? como criar plugins ??

Solução: Quando alternativas ou comportamentos relacionados variam com o tipo, é só atribuir responsabilidades aos tipos usando operações polimórficas.

Um bom exemplo:


Ao meu ver , na programação orientada a objetos , o polimorfismo permite que classes mais abstratas representem o mesmo comportamento de classes concretas que referenciam , sendo assim um método pode apresentar várias formas.
O polimorfismo de torna muito importante pois permite que a semântica de uma interface seja efetivamente separada da implementação que a representa.

Os benefícios do polimorfismo , são muitos , mas o principal é a sua clareza e facilidade de manutenção do código.

Exemplo:

public void mostrarCalculo (int operacao, double x, double y)
{ System.out.print("O resultado é: "); switch (operacao) { case SOMA: System.out.print(""+(x+y)); break; case SUBTRACAO: System.out.print(""+(x-y)); break; //... outras operacoes default: throw new UnsupportedOperationException() }}

Além do código ser maior e mais difícil de ler, essa implementação tem outros problemas. Provavelmente esse não será o único método a utilizar operações matemáticas e, portanto, pode-se esperar não um, mas vários switchs como esse pelo código. O que acontece, então, se uma nova operação for adicionada ao sistema? Será necessário que todos os switchs sejam encontrados e substituídos. Com o polimorfismo, a modificação restringiria-se apenas a criação de uma nova classe.

Bom fds a todos !!!

Até o próximo blog.
BIBLIOGRAFIA:
UTILIZANDO UML E PADRÕES - Craig Larman

domingo, 18 de maio de 2008

Padrão MVC

Blog referente a aula 23 do dia 12/05/2008

Padrão MVC

Para começar podemos dizer que MVC é um padrão de arquitetura de software, com o aumento da complexidade das aplicações torna-se viável separação entre os dados e o layout e o Model-View-Controler separa perfeitamente as tarefas de acesso aos dados e a lógica do negócio.

No meu entender um domínio pode ser considerado como a melhor representação do Model , por exemplo Aluno-Professor e Turma fazem parte de um sistema acadêmico.

Muitas aplicações usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar dados. MVC não cita especificamente a camada para acesso aos dados, porque subentende-se que estes métodos estariam encapsulados pelo Model.

Também é no model que ficam armazenadas as regras de negócio.

Neste Padrão é comum dividir a aplicação em camadas separadas: apresentação , domínio e acesso a dados. Em MVC a camada de apresentação também é separada pela View e pela Controler.

View – uma View nada mais é do que uma alternativa para observação de dados de uma ou mais entidades , entidades essas que formam a base de dados.

O View renderiza o model em uma forma específica para a iteração , geralmente uma interface de usuário.

Elas nos possibilitam muito mais do que uma visualização dos dados , as Views também podem ser utilizadas em aplicações.

As Views são responsáveis por enviar dados para o Frame ou seja ela mostram os dados no Frame e recebem também os dados do frame.

A View guarda os seus dados na forma de uma tabela virtual armazenando também em cache , pois todas as aplicações executadas ou não são armazenadas em cachê.

O controler processa e responde a eventos , geralmente ações do usuário , ele geralmente provoca alterações no model.

Até o próximo Blog
BIBLIOGRAFIA:
UTILIZANDO UML E PADRÕES - Craig Larman

sábado, 10 de maio de 2008

Padrão Command

Padrão Command

Referente a aula 22 do dia 5/5/2008

O polimorfismo nos permite encapsular uma informação ou um comando como um objeto.

Permite estabelecer a assinatura de um método muitas vezes pela utilização de um execute ( ) ou um perform ( ).

Isso acaba permitindo encapsular uma informação como um objeto. Um exemplo clássico da importância da utilização do padrão command é a utilização de telas de menu, pois quando o configuramos , temos que configurar os menus com ações que o usuário queira que eles façam assim que for clicado o botão , ou seja quando for executar um comando de salvar ou carregar.

Uma forma de fazermos com que nossa classe utilize um de nossos métodos quando o usuário clicar é usando o polimorfismo , ou seja tornando o nome da operação fixo , variando assim a sua implementação.

Por isso quando se trata de uma aplicação onde serão usados muitos menus independentes, a melhor solução a ser utilizada seria o padrão command.

Um método que o item menu chama quando um usuário o chama é o actionperformed ( ) , mas podemos vir a pensar nele como um execute ( ).

Quando criamos um objeto JmenuItem, podemos fornecer-lhe um comando para executar quando o usuário selecionar o item, nossa intenção em usar o action performed é criar um método que toma uma ação que satisfaça o comando do usuário , geralmente nesses casos , faz-se o uso de uma classe anônima.

Até a próxima !!!!!

sábado, 3 de maio de 2008

Padrão Observer

Blog referente a aula 21 do dia 28

Padrão Observer

Defini uma dependência entre objetos , para que assim ,quando um destes objetos mudar de estado , todos os seus dependentes mudem junto automaticamente.

Vejamos , os objetos aqui no caso são observadores , ou seja , eles observam as mudanças ocorridas nas classe e notificam os objetos sobre as mudanças , mudando todo o seu estado automaticamente.

Mas como todos os padrões que nós já vimos aqui , o Observer também apresenta problemas , pois como faríamos para garantir que os objetos de dependem de outro objeto acompanhem as mudanças
daqueles objetos, e principalmente fazer com que o objeto de interesse atualize os outros objetos quando a mudança ocorrer.

Só que todo esse processo pode ocasionar risco , um deles seria o relacionamento bidirecional entre os objetos , relacionamento esse que pode ocasionar o alto acoplamento.

Uma das grandes vantagens do padrão Observer é a possibilidade de reutilização de seus objetos, sendo que o seu alto acoplamento é diminuído com a utilização de classes abstratas.

Como desvantagem , o abuso em sua em sua utilização pode causar grandes problemas a interface da classe, o que deixa os sistemas cheios de requisições causando uma tempestade de eventos.

Uma excelente semana a todos e até o próximo blog!!!!!
BIBLIOGRAFIA: