Aulas 33 e 34

EXTREME PROGRAMMING

Antes de começarmos a entender o que é XP, vamos analisar um pouco da evolução do desenvolvimento de software ao passar do tempo:
Por volta de 1960 os computadores começaram a ser utilizados cada vez com mais intensidade nas empresas, uma vez que, até então, estavam quase que exclusivamente limitados ao uso militar. As máquinas eram caríssimas, e por isso, seus recursos deveriam ser explorados ao máximo. Os programas eram otimizados ao extremo para a arquitetura do computador em que iriam rodar, e os poucos programadores que existiam não estavam muito preocupados com a legibilidade do que escreviam, até porque não tinham mesmo muita opção. Existem muitas histórias sobre programas de computadores que simplesmente tinham que ser descartados quando uma arquitetura de hardware era substituída por outra.

Valores

Feedback
Algumas pessoas seriam capazes de caminhar na beira de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as conseqüências daquilo que pediu. Os clientes, por sua vez, procuram se manter presencialmente próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que surja ao longo do desenvolvimento.

Comunicação
Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

Simplicidade
O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

Coragem
Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando acontece cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção.

Conclusão
Trabalhar com Extreme Programming equivale a encarar o desenvolvimento de software de uma forma diferente daquela a que estamos habituados. Trata-se de uma forma mais humana, onde todos - clientes, desenvolvedores e demais interessados no projeto - são identificados como pessoas que falham e que acertam. A estrutura de desenvolvimento criada pelo XP procura ajudar o projeto a explorar o que as pessoas têm de melhor e solucionar suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização para evitar que trabalhos desnecessários sejam executados. Isso ajuda a poupar tempo, recursos e permite gerar maior valor para os clientes. Extreme Programming é a arte de maximizar o trabalho que não será feito. Pois, mais importante que trabalhar muito e produzir muito, é produzir a coisa certa, aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas, fazendo isso de forma consistente, segura e rápida ao longo de todo o andamento do projeto.

Link: http://www.nce.ufrj.br/conceito/artigos/2006/015p1-3.htm

Aulas 31 e 32

Padrão Invenção Pura

Problema:

A quem atribuir responsabilidades quando qua do 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 reutilização (uma invenção da imaginação).

Exemplo: Se for necessário salvar instâncias de Venda em um banco de dados relacional, considerando o padrão Expert, esta responsabilidade pode ser atribuída à própria classe Venda.
Porém há as seguintes implicações:
-Grande número de operações voltadas ao banco de dados- diminuição da coesão-
A classe Venda tem que ser acoplada com a interface do banco de dados relacional aumento do acoplamento–
Salvar objetos é uma tarefa geral, necessária em muitas classes – duplicação de código, baixa reutilização.
-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 PersistentStorageBroker.
Esta classe é uma Invenção Pura.

Padrão Indireção
Problema: Quem irá evitar o acoplamento direto? Como desacoplar objetos de maneiraa 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çãoentre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados.

Exemplo:
O exemplo de uma Invenção Pura de desacoplar Venda dos serviços de banco de dados relacionais, também é um exemplo de Indireção. O PersistentStorageBroker atua como um intermediário entre Venda e o banco de dados.

Link: http://www.inf.ufg.br/~juliano/ensino/especializacao/ProjSw2007/ProjetoOO.pdf

Aulas 29 e 30

Padrão Polimorfismo

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.O Polimorfismo significa "existindo em muitas formas". Ele permite que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam. Assim, um mesmo método pode apresentar várias formas, de acordo com seu contexto.

O objetivo principal do polimorfismo é:

- Evitar a condição IF e ELSE;

- Usar polimorfismo melhorar a conectividade dos componentes.

Aulas 27 e 28

Exercícios:

1º) Um objeto "A" precisa executar um método quando o estado do objeto "B" for alterada. Qual o padrão GOF deve ser usado? Qual o papel do objeto "B" e do objeto "A" nesse padrão?


2º) Qual o padrão GOF deve ser usado quando necessitamos executar diversas ações de forma atômica

3º) Uma classe de conexão só pode ter, no máximo, 10 instâncias. Qual o padrão GOF a usar?

4º) Duas classes "B" e "B" tem iterfaces distintas. Qual o padrão deve ser usado se a classe "B" precisar um método da classe "A" ?

5º) Voçê deseja que uma classe de terceiros use um método de sua classe. Qual o melhor padrão?

Aula 25 e 26

MVC

Model-view-controller (MVC) é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afectam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.
O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interacção com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto.


Model

A representação "domínio" específica da informação em que a aplicação opera. Por exemplo, aluno, professor e turma fazem parte do domínio de um sistema acadêmico. É comum haver confusão pensando que Model é um outro nome para a camada de domínio. Lógica de domínio adiciona sentido à dados crus (por exemplo, calcular se hoje é aniversário do usuário, ou calcular o total de impostos e fretes sobre um determinado carrinho de compras).
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.

View
"Renderiza" o model em uma forma específica para a interação, geralmente uma interface de usuário.

Controller
Processa e responde a eventos, geralmente ações do usuário, e pode invocar alterações no Model.

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

AULA 23 e 24

PADRÃO COMMAND


Propósito:
Encapsular uma requisição como um objeto, permitindo que os clientes parametrizem diferentes requisições, filas ou fazer o registro de log de requisições e dar suporte operações que podem ser desfeitas.


Também conhecido como:
Action ou Transaction
Motivação:
As vezes precisamos executar uma operação sem se preocupar com qual objeto que vai realiza-la
ou simplesmente não conhecemos qual objeto vai receber a delegação para executar tal operação.
Em uma aplicação Client/Servidor geralmente temos o componente Menu que é composto de
vários itens. Cada item do menu eqüivale uma operação, como salvar um arquivo, ler arquivo,
apagar arquivo, selecionar a paleta de cores e etc..


Aplicação:
Use o padrão Command quando você precisa:
- Parametrizar objetos por uma ação a ser executada
- Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command
poder ter o ciclo de vida independente da requisição do cliente.
- Suporte para desfazer operações. A operação "execute" do Command, pode armazenar
estados para reverter seus efeitos no próprio comando. Basta acrescentar na interface
Command uma operação chamada "Unexecute", que terá a responsabilidade de desfazer a
operação realizada pelo "execute". Os comandos realizados podem ser armazenados em lista
histórica.
- Estruturar um sistema em torno de operações de alto nível, como transações por
exemplo. Uma transação encapsula um conjunto de mudanças nos dados. O padrão
Command provê uma maneira de modelar transações. O Command tem uma interface comum, assim podemos chamar todas as transações do mesmo jeito.
- Reduzir acoplamento entre as requisições dos clientes e o objetos que as executam.


Solução:
Implemente o padrão Command para encapsular as operações e reduzir o acoplamento entre as requisições e os objetos que as executam. Para facilitar implantação de novas operações e tornar mais simples a manutenção das operações.


Conseqüências:
O padrão Command tem as seguintes conseqüências:
- Comand reduz o acoplamento (dependência) entre o objeto que chama a operação e o objeto
que executa a operação.
- Command é objeto que pode ser estendido e manipulado por outros objetos
- É mais fácil de acrescentar novas operações ou novos comandos, pois você não tem que
mudar as classes existentes.

Aulas 21 e 22

PADRÃO OBSERVER

O padrão Observer, é utilizado para quando você precisa encapsular objetos que você não conhece, dentro de um outro e notificá-los após uma determinada ação.

Pré-Requisitos
Entendimento de orientação à objetos;
Capacidade de abstração;

Situações
Você precisa de um log de ações no seu sistema administrativo;
Você precisa saber quando alguém executou os comandos do seu WebService;
Quando um visitante do seu site fizer cadastro, deve inicializar todas as tabelas relacionadas;


Motivações
Tradicionalmente, aconselha-se o uso de padrões de projeto, pois são uma maneira unificada de falar de um determinado algoritmo;
Segundo estudos, é um padrão com nível máximo de uso;
O .NET Framework utiliza em seus componentes;
Encapsulamento e entendimento simples e fácil;
Utilização correta da orientação à objetos;


O Padrão Observer representa uma dependência de um para muitos entre objetos para que quando um objeto mude de estado, todos os seus objetos dependentes sejam alterados automaticamente.

LINK: http://infotecfatos.blogspot.com/2008/01/padres-de-projetos.html