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:

sábado, 26 de abril de 2008

Padrão Singleton

Aula 22 referente a aula do dia 22 de abril de 2008

Padrão Singleton

Possui a função de garantir que uma classe possua uma única instância, possui uma boa semelhança em relação ao padrão criador dos Padrões GRASP.

Outro objetivo desse padrão é prover um ponto de acesso a classe, se bem que temos que refletir sobre os problemas que podem ocorrer , primeiramente , como iremos controlar o número de instâncias da classe em questão , ou de qualquer outras classes, como armazená-las e principalmente como definir o acesso a elas?

É por isso que temos que utilizar o método synchronized, para evitar que dois objetos tentem criar as instancias ao mesmo tempo.

Vantagens do Singleton

- Pode vir a possuir subclasses , devido a utilização de métodos estáticos.

- Acesso a vários objetos

Desvantagens

- A sua implementação depende da linguagem utilizada
- Difícil de se implementar em um ambiente distribuído
- Difícil de implementar em ambiente multithreaded
- De difícil teste , pois pode haver momentos em que suas aplicações dependam de uma instância extra.

Bom , por enquanto é só , pessoal , espero que tenha conseguido clarear bem a idéia do que vem a ser o padrão Singleton.

Bom final de semana a todos e até a próxima.
BIBLIOGRAFIA:

sábado, 19 de abril de 2008

Padrões GOF

Aula 19 do dia 14/04/2008

Padrões GOF

Primeiramente , devemos nos perguntar , o que é um Padrão ?

È uma maneira de alcance de objetivo , seja esta de forma documentada ou testada.

Como no bimestre que se passou , falamos de padrões GRASP , daremos continuidade ao nosso estudo ,falando dos padrões GOF (Gang of Four).

Cada padrão nos mostra um problema que acontece várias vezes , so que ele nos dá a possibilidade de confecção de uma solução base que poderá ser utilizada em vários outros objetos, ou seja, através dele nós podemos confeccionar uma solução padronizada , que poderá ser reutilizada várias vezes.

Eu penso que para um leigo qualquer na área as informações fornecidas acima não fazem nenhuma diferença , mas para um desenvolvedor que procura ascensão na área , padrões GOF dão ao profissional na área de TI , um salto em sua carreira , ajudam um desenvolvedor calouro a pensar como um especialista, auxiliam na documentação de sistemas já desenvolvidos ou que venham a ser desenvolvidos e o melhor , facilita bastante na aprendizagem.

Os padrões proporcionam ao desenvolvedor uma melhor organização dos seus sistemas , pois possibilitam o uso de soluções com nome , facilitando assim o entendimento.

Elementos de um padrão

São os que se seguem abaixo:

- Nome: Nome do Padrão a ser estabelecido.
- Problema: Quando se deve aplicar um padrão , e sobre quais condições devemos utilizá-lo.
- Solução.
- Conseqüências.

Padrão Adapter

Sua função é tornar classes com interfaces diferentes compatíveis.
* Momento JAVA – Vamos recordar um assunto que todos nós conhecemos do 3º termo em JAVA , falaremos de interface.
* Interfaces são coleções de métodos que permitem que objetos de uma classe acessem objetos de outras classes.
Este padrão cria uma classe que se adapte as necessidades de outra classe.

Quanto ao tipo de adaptador , existem dois tipos:

Adaptador de objetos e adaptador de classes e como foi pedido no laboratório tentarei confeccionar um exemplo de cada um deles.
Adaptador de Classe

Public class Professor {
Destino [] destino = new Destino [2];
public void concluirDestino ( ) {
destinos[0] = new DestinoEmCurso ( );
destinos[1] = new Adaptador ( );
// ...
}
Public void concluiDestino ( ) {
for (int i = 1; i < destino.length; i++) {
alvo.operacao( );
}
}
}



ADAPTADOR

Public class Adaptador extends ClasseAtual implements Destino
Public void execução ( ) {
String texto = metodoUtilUm(“Aula Ministrada.”);
}
}


Public class ClasseAtual {
Public void metodoUtilUm(String texto) {
System.out.println(texto);
}

}

Bibliografia:

http://padroes-de-projeto-de-software.cartilha.regularize.com.br/list/18/cartilha/post/85/

Boa semana a todos , até a próxima

terça-feira, 1 de abril de 2008

Padrão Controlador

Referente a aula do dia 25/3/2008
Padrão Controlador
Controlador Problema: Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?
O princípio da separação Modelo-Visão pode ser enunciado em duas partes:- Não conecte diretamente objetos pertencentes à interface com o usuário (visão) com objetos não pertencentes à interface com o usuário (IU).
- Permitir o desenvolvimento separado das camadas de apresentação e negócio.
- Minimizar o impacto na camada de negócio das alterações nos requisitos da interface com o usuário.
- Permitir a existência de múltiplas visões simultâneas para uma mesma camada de negócios (por exemplo, a visualização de dados de vendas na forma tabular ou através de um gráfico de pizzas). O objeto Controlador responde a uma questão básica no projeto de sistemas OO: Como conectar a camada de apresentação à camada da lógica do negócio?O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.
- Um objeto Controlador para todo o sistema- Um objeto Controlador por Caso de Uso (ou por cenário de Caso de Uso) Os benefícios do padrão controlador são:
- Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio
- Oportunidade para controlar o estado do caso de uso.
Bom foi mais ou menos o que eu entendi , admito que em certos momentos não resumi muito , por que tenho que admitir que senti um pouco de dificuldade em explicar este padrão , espero que mesmo assim tenha conseguido passar um pouco de que eu entendi.
Até o próximo blog
Marcos Vinicius