AULA 31 e 32 - VARIAÇÕES PROTEGIDAS E XP

Variações Protegidas

Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.Mecanismos de Variações Protegidas· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.Padrão não Fale com EstranhosObjetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.§ Objetos referenciados diretamente – “familiares”§ Objetos referenciados indiretamente – “estranhos”§ Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil· O objeto this· Um parâmetro do método· Um atributo de this· Um elemento de uma coleção que seja de this· Um objeto criado dentro do métodoPor exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.

XP

Extreme Programming, ou XP, é um processo de desenvolvimento de sof-tware voltado para:• Projetos cujos requisitos são vagos e mudam com freqüência;• Desenvolvimento de sistemas orientados a objeto;• Equipes pequenas, preferencialmente até 12 desenvolvedores;• Desenvolvimento incremental (ou iterativo), onde o sistema começa aser implementado logo no início do projeto e vai ganhando novas funci-onalidades ao longo do tempo.Existe uma categoria de processos de desenvolvimento conhecida como Pro-cessos Ágeis de Desenvolvimento, dentro da qual o XP e outros processos seencaixam. Eles compartilham a premissa de que o cliente aprende sobresuas necessidades, na medida em que é capaz de manipular o sistema queestá sendo produzido. Com base no feedback do sistema ele re-avalia as suasnecessidades e prioridades, gerando mudanças que devem ser incorporadasao software. O aprendizado é importante, porque permite que o clientedirecione o desenvolvimento de modo que a equipe produza sempre aquiloque tem o maior valor para o seu negócio.O XP é um processo de desenvolvimento que busca assegurar que o clientereceba o máximo de valor de cada dia de trabalho da equipe de desenvolvi-mento. Ele é organizado em torno de um conjunto de valores e práticas queatuam de forma harmônica e coesa para assegurar que o cliente semprereceba um alto retorno do investimento em software.

AULA 29 e 30 - INVENÇÃO PURA, INDIREÇÃO E NÃO FALE COM ESTRANHOS

Invenção Pura

- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.

- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.

- Problema: A quem atribuir responsabilidades quando as classes do domínio não são adequadas e não se quer violar os princípios da Coesão Alta e do Acoplamento Fraco ? Como criar componentes de software conectáveis ?
- Solução: Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial – que não representa nada no domínio do problema. Tal classe é construída especialmente para melhorar a coesão e diminuir o acoplamento, facilitando a reutilização (uma invenção da imaginação)

Exemplo:
Nesse caso, a solução é criar uma nova classe que é unicamente responsável por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional.
Chamamos esta solução de IntermediárioArmazenamentoPersistente.
Esta classe é uma Invenção Pura.

Beneficios:

-Melhora acoplamento e coesão: a classe venda permanece bem projetada.
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.

Indireção

-Suponha que:
-A aplicação TPV precisa manipular um modem, para transmitir solicitações de autorização de crédito.
-O SO oferece uma API para fazer isso
-A classe ServiçoAutorizaçãodeCrédito é responsável por falar com o modem .Tal classe fica altamente acoplada com a API e o SO.

-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados

-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados

-Benefício: Acoplamento fraco – com o objetivo de desacoplar outros componentes ou serviços, introduz-se uma indireção.
-Muitas invenções puras são conseqüências da indireção.

Não fale com estranhos

-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.
-Objetos referenciados diretamente – “familiares”
-Objetos referenciados indiretamente – “estranhos”
-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.

-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?
-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)

-Lei de Demétrio
-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:
-O objeto this (ou self)
-Um parâmetro do método
-Um atributo de self
-Um elemento de uma coleção que é um atributo de self
-Um objeto criado dentro do método

AULA 27 e 28 - PADRÕES GRASP 2ª PARTE POLIMORFISMO

Polimorfismo

- lternativas com base no tipo: variação condicional é comumente encontrada em programas.
- Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
- Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?

- Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
- Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
- Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo


- Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
- Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.


- Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
- Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente.

AULA 25 e 26 - PADRÃO MVC

O padrão MVC
O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.

Camada de apresentação ou visualização - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação.
inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
É a camada de interface com o usuário.
É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.
modela os dados e o comportamento por atrás do processo de negócios
se preocupa apenas com o armazenamento , manipulação e geração de dados
É um encapsulamento de dados e de comportamento independente da apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.
controla e mapeia as ações
Vantagens do modelo MVC :
Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
Torna a aplicação escalável
É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.
Desvantangens do modelo MVC:
Requer uma quantidade maior de tempo para analizar e modelar o sistema
Requer pessoal especializado
Não é aconselhável para pequenas aplicações

AULA 23 e 24 - PADRÃO COMMAND

Command é um dos 23 padrões de projeto do GOF e é um dos 11 padrões comportamentais


Encapsular uma solicitação como um objeto, desta forma permitindo parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas.


Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada ou sobre o receptor da mesma.
Utilizar quando:
Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;
Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação para um processo diferente e lá atender a solicitação;
Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente.


A chave deste padrão è uma classe abstrata Command, a qual declara uma interface para execução de operações. Na sua forma mais simples, esta interface inclui uma operação abstrata Execute. As subclasses concretas de Command especificam um par receptoração através do armazenamento do receptor como uma variável de instância e pela implementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar a solicitação.


Também conhecido como Action, Transaction (Ação, Transação, respectivamente).
Obtido em http://pt.wikipedia.org/wiki/Command


EXEMPLO:


public class DvdName {


private String titleName;


public DvdName(String titleName) {


this.setTitleName(titleName);


}


public final void setTitleName(String titleNameIn) {


this.titleName = titleNameIn;


}


public final String getTitleName() {


return this.titleName;


}


public void setNameStarsOn() {


this.setTitleName(this.getTitleName().replace(' ','*'));


}


public void setNameStarsOff() {


this.setTitleName(this.getTitleName().replace('*',' '));


}


public String toString() {


return ("DVD: " + this.getTitleName());


}


}


public abstract class CommandAbstract {


public abstract void execute();


}


public class DvdCommandNameStarsOn extends CommandAbstract {


private DvdName dvdName;


public DvdCommandNameStarsOn(DvdName dvdNameIn) {


this.dvdName = dvdNameIn;


}


public void execute() {this.dvdName.setNameStarsOn();


}


}


public class DvdCommandNameStarsOff extends CommandAbstract {


private DvdName dvdName;


public DvdCommandNameStarsOff(DvdName dvdNameIn) {


this.dvdName = dvdNameIn;


}


public void execute() {


this.dvdName.setNameStarsOff();


}


}


class TestCommand {


public static void main(String[] args) {DvdName jayAndBob = new DvdName("Jay and Silent Bob Strike Back");


DvdName spongeBob = new DvdName("Sponge Bob Squarepants - " +"Nautical Nonsense and Sponge Buddies");


System.out.println("as first instantiated");


System.out.println(jayAndBob.toString());


System.out.println(spongeBob.toString());


CommandAbstract bobStarsOn = new DvdCommandNameStarsOn(jayAndBob);


CommandAbstract bobStarsOff = new DvdCommandNameStarsOff(jayAndBob);


CommandAbstract spongeStarsOn = new DvdCommandNameStarsOn(spongeBob);


CommandAbstract spongeStarsOff = new DvdCommandNameStarsOff(spongeBob);


bobStarsOn.execute();spongeStarsOn.execute();


System.out.println(" ");System.out.println("stars on");


System.out.println(jayAndBob.toString());


System.out.println(spongeBob.toString());


spongeStarsOff.execute();System.out.println(" ");


System.out.println("sponge stars off");


System.out.println(jayAndBob.toString());


System.out.println(spongeBob.toString());


}}

UML do Exempo:

AULA 21 e 22 - PADRÃO OBSERVER

O padrão Observer define uma relação de dependência "um-para-muitos" entre objetos, tal que quando há mudança no estado de um objeto, todos os seus dependentes são notificados e atualizados automaticamente. Esse padrão tem como elementos participantes o Subject, que define uma interface para adicionar/remover dependentes e notificar os dependentes; o ConcreteSubject, que retém o estado de interesse dos objetos ConcreteObserver e notifica esses objetos de sua mudança de estado; o Observer que define uma interface para atualizar os objetos que precisam ser notificados das mudanças no Subject e o ConcreteObserver, que implementa a interface de Observer e precisa atualizar o seu estado conforme o estado do Subject ao qual está associado.
No sistema proposto, o padrão Observer é aplicado em: • ControladorDeJogo - É responsabilidade de cada Controlador de Jogo apresentar graficamente o estado atual do jogo. Para isso, o ControladorDeJogo atua como observador (ConcreteObserver) sobre a Sessão, sendo notificado de cada modificação no Estado. • Sessao - A Sessao por sua vez, atua como o objeto observado (ConcreteSubject) notificando os objetos dependentes das mudanças no Estado. • ControladorDeSessoes - O ControladorDeSessoes apresenta ao usuário todas as sessões disponíveis, para que o Controlador possa apresentar toda Sessao recentemente criada e deixe de apresentar aquelas que já terminaram, o controlador atua como observador sobre o ServidorDePartidas, sendo notificado de toda Sessao que é criada ou terminada. • ServidorDePartidas - O ServidorDePartidas, assim como a Sessao, atua como objeto observado tendo como responsabilidade notificar cada ControladorDeSessoes quando uma sessao e criada ou terminada.
Observação: Tendo em vista as constantes alterações no Estado devido a dinâmica do jogo, é interessante que cada ControladorDeJogo seja notificado uma única vez por ciclo, ou seja, permitir que a LogicaDoJogo atualize cada elemento para então notificar os Controladores.

AULA 19 e 20 - PADRÃO SINGLENTON

Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Exemplos

Em Java
Segue um exemplo em Java de classe Singleton usada em log de dados. Esta classe suporta inicialização sob demanda e ambientes multi-thread.public class SingletonLog {
// Construtor privado. Suprime o construtor publico padrao.
private SingletonLog() {
// Leitura da configuração de log. Normalmente descrita em um arquivo.
}
// Faz o log de eventos da aplicacao
public void doLog(String eventDescription) {

}
//Retorna a instancia unica da classe SingletonLog
public static SingletonLog getInstance() {
return SingletonLogHolder.instance;
}
//Classe auxiliar para criacao da instancia. Evita problemas de sincronizacao de threads.
private static class SingletonLogHolder {
private static SingletonLog instance = new SingletonLog();
}
}