Indireção

Blog referente a aula do dia 02/06/2008

Bom dia caros visitantes, hoje falarei sobre um padrão muito interessante , interessante pelo fato de que ele facilita e muuuuiiiiiiitooooo a vida de um desenvolvedor, projetista,analista e etc...

No episódio de hoje !!!

Indireção

O problema surge justamente em saber a qual objeto atribuir a responsabilidade de ser o mediador evitando a ocorrência de acoplamento direto entre os objetos.

Uma boa e inteligente solução para este tipo de problema seria a criação de um mediador, ou seja , cria-se um objeto intermediário para controlar outros componentes causando uma indireção entre eles.

Em outras palavras , o padrão Indireção atribui responsabilidade a um objeto intermediário para ser o mediador entre outros componentes, evitando assim que eles sejam diretamente acoplados.
Um bom exemplo disso seria como na Invenção Pura, a utilização do Armazenamento Persistente que atua como um intermediário entre a venda e o banco de dados.

Uma das maiores motivações para a indireção é o acoplamento fraco, onde um intermediário é usado para desacoplar os componentes.

A Indireção serviu como padrão modelo para muitos outros padrões, o adapter é um deles , até Invenções Puras são criadas através do padrão indireção.

Uma de suas vantagens é o fraco acoplamento entre suas classes.

Boa semana a todos !!!

Bibliografia:

http:// groups.msn.com/cafedotnet/grasppadresssoftware.msnw

Livro - UTILIZANDO UML E PADRÕES - Craig Larman

Invenção Pura !!!!!

Blog referente a aula do dia 26/05/2008

Solução

Consiste em inventar uma classe que suporte a coesão alta , acoplamento fraco e a reutilização, é uma classe fruto da imaginação, inventada de momento, o que acaba por tornar o projeto muito puro.

O problema se origina de maneira ao se atribuir responsabilidades apenas as classes de domínio, acaba por ocasionar problemas com coesão e acoplamento, ou pior tornam a classe impossível de ser reutilizada.

Veja um exemplo:

Pelo que entendi , a classe venda de acordo com o padrão especialista seria o responsável por salvar as suas próprias instancias em um banco de dados, só que é importante salientar que:

Seriam necessárias dúvidas operações de suporte relacionadas a banco de dados, nenhuma delas relacionadas a venda , o que tornaria a classe "Venda" não coesa.

Além disso a classe venda precisa ser acoplada ao banco de dados relacional aumentando assim o seu acoplamento.

Sendo assim , mesmo que o padrão especialista concorde que venda é a classe essencial para salvar a si mesma em um BD, ela leva todos os problemas que pedem que seja inventado algo e é aí que entra a invenção pura.

Uma solução seria criar uma classe exclusiva, exclusiva no sentido de ser utilizada somente para salvar os dados em um banco de dados relacional através de armazenamento persistente.

Peraí , mas o que vêm a ser "Armazenamento Persistente"??

Nada mais é do que algo criado por conveniência para auxiliar o desenvolvedor.

Segues abaixo alguns dos problemas resolvidos por invenção pura:

- A classe fica bem projetada com alta coesão e acoplamento fraco.

A classe armazenamento persistente por ser usada como auxilio ao desenvolvedor torna-se apta as ser utilizada várias vezes.

Por hoje é só pe-pe-pessoal, hehehe

Até semana que vêm.

BIBLIOGRAFIA:

http://groups.msn.com/cafedotnet/graspadress

UTILIZANDO UML E PADRÕES - Craig Larman

Inversão de Controle e Injeção de Dependência - 26-05-2008

Referente a aula 25 do dia 26/05/2008

Vamos aprender mais ???

heheheheh

Hoje nós iremos aprender um pouco sobre dois assuntos muito importantes !!!

Inversão de Controle e Injeção de Dependência

Inversão de controle – Também chamado de princípio de hollywood, ou seja “não nos chame , nós chamamos vc” . Um exemplo disso é o Template Method.

É uma forma de controlar e desenvolver aplicações de forma a deixa-las mais simples e mais limpas . Digamos que ele seja usado para dar uma certa “elegância” ao código.

Injeção de dependência – É uma técnica utilizada pra instanciar classes concretas, se fazer um acoplamento entre elas. Projetos que usam este tipo de injeção beneficiam muitos containeres de injeção de dependência.
É um padrão utilizado quando é necessário manter o baixo nível de acoplamento entre os módulos do sistema.
Neste tipo de Padrão as dependências entre os módulos não são definidas pelo programador e sim pelo container, este sim é responsável por injetar os componentes. Este padrão se relaciona com o padrão inversão de controle , mas isso não quer dizer que os dois tenham propósitos idênticos ou sejam a mesma coisa.

Olha , gostei muito desse assunto , espero que os próximos assuntos não sejam tão chatos e complexos como os anteriores.

heheheh

Ta pensando o quê !!!!, pensa que ser um bom desenvolvedor é fácil !!!!

Rala meu filho !!!!, rala !!!

heheheheh

Até o próximo blog !!!

BIBLIOGRAFIA:

http://pt.wikipedia.org/wiki/Inversão_de_controle

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:

http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/proj1/proj5.htm

UTILIZANDO UML E PADRÕES - Craig Larman

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:

http://pt.wikipedia.org/wiki/MVC

UTILIZANDO UML E PADRÕES - Craig Larman

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 !!!!!

http://www.javafree.org/news/view.jf?idNew=1246

http://www.javafree.org/news/view.jf?idNew=1246

http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm

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:

http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/observer.htm

http://www.mundooo.com.br/php/modules.php?name=News&file=article&sid=798