Aula 31 e 32 de Projetos Orientado a Objetos

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.

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 interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.

Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.

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.

XP – Extreme Programming

XP, ou Extreme programming, é uma metodologia para desenvolvimento de softwares ágil porém com qualidade indicada para projetos cujos requisitos mudem bastante, utilizam desenvolvimento orientado a objetos e tenham uma equipe de até 12 desenvolvedores. XP enfatiza o envolvimento do cliente e promove o trabalho em equipe.

4 focos principais

comunicação - ao extremo entre cliente e equipe, decisão mútua do que deve ser feito primeiro e o que pode ser deixado pra depois;

simplicidade - manter a simplicidade através do reuso de código e minimizando a construção de código;

feedback - pequenos releases e testes contínuos como mecanismo de retroalimentação;

coragem - ser honesto em dizer o que pode ser feito e o que não pode ser feito.

Bibliografia

Microsoft Corporation Groups, GRASP - Padrões de Software para Atribuição de Responsabilidade Gerais, Disponível em:<http://groups.msn.com/cafedotnet/grasppadresdesoftware.msnw>

Aula 29 e 30 de Projetos Orientado a Objetos

Invenção Pura

Faz uso das classes de domínio para ser implementada, surge nessa implementação um problema que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento". Para resolver esse problema podemos aplicar o conceito de uma classe Artificial ou inventada ela, não é uma classe de domínio por isso podemos associá-la com outras classes que são de domínio para resolver o problema de Alto Acoplamento e Baixa Coesão, atribuindo a ela responsabilidades coesas. Algumas das vantagens são:

Diminui o Acoplamento;
Diminui a pulverização de código e,
Aumenta a coesão.

O principal objetivo de se usar Indireção, é que podemos atribuir a responsabilidade a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.

O Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.

O spring não suporta interceptação de campos, apenas de métodos.

Um exemplo clássico de utilização transparente do suporte a AOP do spring framework, é o gerenciamento de transações declarativas nativo do Spring, que é implementado como um Advice AOP.

Bibliografia

Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 06Junho 2008, 18:20;

GRASP Patterns, Disponível em:<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 06 Junho 2008, 18:20;

Aula 27 e 28 de Projetos Orientado a Objetos

Padrões GRASP

O polimorfismo torna o código mais legível, mais enxuto e facilita a manutenção dos sistemas pois permite que se utilize métodos com o mesmo nome para objetos diferentes. A mesma operação, que foi implementada através da codificação de um método, pode atuar de modo diferente em classes diferentes.

1º - Evitar a condição IF e ELSE
2º - Usar polimorfismo melhorar a conectividade dos componentes

A solução de alguns problemas do polimorfismo tais como criar componentes de softwares conectáveis, é atribuir responsabilidade aos tipos para os quais o comportamento varia, usando operações polimórficos.

Framework – ao contrário da ferramenta ToolKit no framework o desenvolvedor terá que utilizar o roteiro do jeito que está definido na ferramenta, existem vários tipos de frameworks, alguns deles são:

Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.

Bibliografia

Jacques Philippe Sauvé, http://walfredo.dsc.ufcg.edu.br/cursos/2002/progII20021/aulas/o_que_e_polimorfismo.htm>

<http://w3.ualg.pt/~hdaniel/poo/teorica/poot03.pdf> <http://imasters.uol.com.br/artigo/4497/spring_framework_introducao>

Contegix, Disponível em: <http://www.springframework.org/>

Aula 25 e 26 de Projetos Orientado a Objetos

Padrão MVC

Modelo-Vista-Controlador O MVC é uma estrutura padrão de software que pode ser usada para organizar o código de forma que a lógica de trabalho fique separada da apresentação dos dados.

Model

O Model é a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas para administrar e manipular dados. O model deve conter métodos para adicionar, eliminar e atualizar informações na base de dados. Também deve conter métodos para obter a lista existente. De modo geral, a técnica de acesso aos dados deve ser encapsulada no model. Desta forma, se uma aplicação for transferida de um sistema que usa banco de dados para um sistema que usa arquivos texto para guardar as informações, o único elemento que precisa ser alterado será o model - a View e o Controller não precisam ser modificados.

Notificar a View quando seofrer alteração (Padrão Observer);
Armazenar o estado da aplicação;
Armazenar as Regras de Negócio;

View

A view é a parte do componente usada para transformar e preparar os dados do model para que possam ser apresentados de alguma forma, geralmente o controller retira os dados do model e os entrega para a view. Esta, por sua vez, alimenta templates com estes dados para que possam ser apresentados ao usuário. A view não modifica os dados de nenhuma forma, apenas os apresenta.
Enviar os dados para Frame;
Receber os dados e as ações do usuário/Frame;
Ao ser notificada pelo Model, solicitar so Controller a atualização dos dados;
Controller O controller é responsável pelas respostas às ações dos usuários. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controller vai determinar qual solicitação foi feita e vai responder de acordo, fazendo com que o model manipule os dados necessários para depois passá-los para a view para que possam ser mostrados. Considere o controller como o jogador de meio de campo.

Tratar os eventos da View;
Selecionar o que mostrar na View;

Bibliografia

Model-View-Controller (MVC)
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm>

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

Padrões de Projeto : O modelo MVC - Model View Controller <http://www.macoratti.net/vbn_mvc.htm>

Aula 23 e 24 de Projetos Orientado a Objetos

Padrão Command

O padrão Command é baseado em: encapsular uma solicitação como uma objeto, assim permitindo filas, rollbacks e façam logs. Conhecido também como Action ou Transaction.
O uso deste padrão muitas vezes é utilizado para substituir procedures no banco de dados, ou seja, caso o programador quiser que seu software execute um calculo ou então faça uma inserção em varias tabelas de seu banco de dados através de uma única solicitação, ele pode fazer com que seja realizado isso no próprio banco, ou seja, que o banco processe esta informação ou ele pode utilizar a camada de aplicação utilizando uma transaction, pois a mesma permite rollbacks e commit, assim mantendo a segurança de se houver falha em uma parte da inserção ou do calculo, não executara esta solicitação por inteiro.

Bibliografia: Material fornecido pelo professor e conhecimentos próprios.

Aula 21 e 22 de Projetos Orientado a Objetos

Padrão Observer

Este padrão tem como objetivo definir uma dependência de um para muitos entre objetos, para que quando um objeto mudar seu estado, seus dependentes atualizem automaticamente.
Este padrão disponibiliza uma facilidade maior de manutenção, pois a cada alteração de um objeto, não é necessária a atualização de todos os seu objetos dependentes, ou seja, não sendo necessário se preocupar com outros objetos, pois automaticamente eles iram reconhecer a atualização.
- Vantagens:
– Tanto observadores quando sujeitos observados
podem ser reutilizados e ter sua interface e
implementação alteradas sem afetar o sistema
– O acoplamento forte implicado pelo relacionamento
bidirecional é reduzido com o uso de interfaces e
classes abstratas
- Desvantagens:
– O abuso pode causar sério impacto na performance.
– Sistemas onde todos notificam todos a cada
mudança ficam inundados de requisições
("tempestade de eventos")

Bibliografia: Material fornecido pelo professor

Aula 19 e 20 de Projetos Orientado a Objetos

Padrão Singleton
O padrão Singleton, ou seja, o padrão de responsabilidade foge à regra comum de que as responsabilidades devem ser distribuídas ao Máximo. Este padrão centraliza a responsabilidade em uma única instância de uma classe, assim garantindo que uma classe terá apenas uma única instância e garantindo um acesso global a ela. Este padrão garante que apenas um objeto exista independente do número de requisições que ele irá sofrer.
A utilização de Singleton tem que ser bem analisada, pois existem alguns pontos fortes porem alguns pontos fracos também.
Pontos Fortes:
- Acesso central e extensível a recursos e objetos
– Pode ter subclasses* (o que seria impossível se fosse apenas
usada uma classe com métodos estáticos)

Pontos Fracos:
– Qualidade da implementação depende da linguagem
– Difícil de testar (simulações podem depender de instância extra)
– Uso (abuso) como substituto para variáveis globais
– Criação "preguiçosa" é complicada em ambiente multithreaded
– Difícil ou impossível de implementar em ambiente distribuído (é
preciso garantir que cópias serializadas refiram-se ao mesmo
objeto)

Bibliografia: Material fornecido pelo professor.

Aula 17 e 18 de Projetos Orientado a Objetos

Padrões GOF
A criação de padrões nada mais, nada menos é definir uma forma linear de como proceder com determinadas tarefas. Assim como o cirurgião deve seguir procedimentos padronizados em uma cirurgia, um programador também deve seguir padrões no seu desenvolvimento, para que em seu ambiente de trabalho ele consiga manter uma linguagem única entre seus companheiros de trabalho.
No desenvolvimento de projetos onde existe a descrição de objetos que se comunicam e classe que são customizadas, foi descrito por Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, 23 padrões de projetos úteis.

Esses 23 padrões utilizam as melhores praticas em OO, utilizando polimorfismo, herança, modularidade, composição e abstração. Onde esses padrões são classificados por GAMMA em:

- Por propósito:
Criação de Classes e objetos
Alteração da estrutura de uma aplicação
Controle de seu comportamento

- Por escopo:
Classe
Objeto

E diferente de Gamma, METSKER classifica em 5 Grupos:

- Oferecer um interface.
- Atribuir uma responsabilidade
- Realizar a construção de classes ou objetos
- Controlar formas de operação
- Implementar uma extensão para a aplicação


Adapter

O padrão Adapter, que é o padrão de interface, tem por si o objetivo de transformar a interface de uma classe, de uma forma esperada para o cliente, e ainda permite a comunicação entre duas classes que não poderiam trabalhar juntas devido a incompatibilidade de suas interfaces.

Dois Tipos de Adapter:

- Adaptador de Objetos: Quando o alvo é uma classe, usa agregação.
- Adaptador de Classe: Quando o alvo é uma interface, usa herança múltipla.

É utilizado o class Adapter quando houver uma interface que permita a implementação estática. E o objeto Adapter quando for desejado um acoplamento menor.

Bibliografia: Material fornecido pelo Professor

Aula 15 e 16 de Projetos Orientado a Objetos

Alta Coesão

Verificar se uma classe esta realmente dentro de seu foco, é verificarmos a coesão dela. Para sabermos se uma classe esta coesa, devemos analisar o quão focada ou relacionada estão relacionados os módulos de uma classe. Quando uma classe esta coesa, falamos que tem um a alta coesão, quando não, falamos que esta com baixa coesão, dificultando o entendimento, o reuso e sua manutenção entre outros pontos.

Tipos de Coesão:

*Concidental
*Lógica
*Temporal
*Procedural
*De Comunicação
*Seqüencial
*Funcional

Concidental: estão agrupadas por mera coincidência, não existe nenhuma coesão entre os módulos.

Lógica: Semelhante ao acoplamento de controle, quando existe um controle entre os módulos.

Temporal: os módulos estão coesos, apenas, por algum evento de tempo.

Procedural: faz com que os módulos que estão acoplados por procedimentos, porém os procedimentos nem sempre estão coesos.

De Comunicação: Quando dois ou mais métodos manipulam o mesmo dado, porém não existe significado entre eles, e eles se encontram juntos.

Seqüencial: Quando vários métodos ocorrem seqüencialmente, ou seja, quando a entrada de um é a saída do outro.

Funcional: Quando todos os métodos estão coesos e trabalhando em busca do mesmo objetivo.

Controller (Controlador)

Controlador é um objeto responsável pelo tratamento de eventos do sistema, ele quem define métodos para as operações.
Dentro do MCV (Model, Controller, View) que é a programação em três camadas, ele se encontra na camada central, fazendo a ponte entre as operações de sistema e os métodos que são as classes.

Aula 13 e 14 de Projetos Orientado a Objetos

- Tipos de Acoplamento

Dentro da ordem de acoplamento temos, Acoplamento de dados, Acoplamento de controle, acoplamento de dados globais e acoplamento de dados internos. Vamos estar falando um pouco sobre cada um desses nesta postagem.
O acoplamento de dados que na listagem é considerado o melhor, consiste em existir duas classes onde uma passa um objeto como parâmetro para a outra, assim havendo uma mudança no objeto passado por parâmetro, automaticamente ira influenciar nas outras classes.
Acoplamento de controle é quando uma classe passa um objeto de controle para a outra, ou seja, passar flags como parâmetro para definir e controlar o que a outra classe ira realizar.
Acoplamento de dados globais, a forma mais conhecida disso são as variáveis globais, pois é onde vários objetos compartilham o mesmo dado.
Acoplamento de dados internos é quando um determinado objeto de uma classe altera dados locais de uma outra, isso geralmente ocorre quando usado métodos públicos e protegidos, é aconselhado utilizar métodos privados onde existam outra para entrada e saída de dados desse método.

Aula 9,10,11 e 12 de Projetos Orientado a Objetos

- Baixo Acoplamento

Para entendermos melhor Acoplamento vamos descrever seu significado. Acoplamento é a forma de se medir o quanto uma classe esta ligada a outra, ou melhor dizendo, o quanto uma determinada classe depende de uma outra. Com este conceito nos faz lembrar de Herança, e é exatamente isso, a herança é um grande exemplo de acoplamento forte. Agora surge então um novo questionamento, “Qual a diferença de acoplamento Fraco(Baixo) e Acoplamento Forte(Alto)?”, a diferença é que o baixo não tem muitas dependências, ou seja, não depende de muitas outras classes e o acoplamento forte é o contrario disso.
Uma situação que nos vale a ressaltar é, a questão de forte acoplamento. Uma classe forte acoplada implica em algumas situações desfavoráveis, que são: difícil entendimento quando ela sozinha, difícil reutilização, ou seja, limita a dinâmica do código e uma outra situação é que fica sensível às mudanças ocorridas nas classes de que ela depende, assim qualquer mudança realizada nas outras classes ira influenciar.
Uma forma de trabalhar mais dinamicamente e reaproveitando mais as classes, é minimizar ao Maximo o acoplamento, ou seja, quanto mais baixo acoplada estiver suas classes, mais irão ser reaproveitadas.
Podemos citar ainda alguns tipos de acoplamento em ordem do “melhor” para o “pior”: Acoplamento de dados à Acoplamento de Controle à Acoplamento de Dados Globais à Acoplamento de Dados Internos.

Aula 7 e 8 de Projetos Orientado a Objetos

- Criador

O padrão de atribuição de responsabilidades é baseado na criação de objetos de uma classe, ou seja, uma classe tem a responsabilidade de instanciar uma outra para a criação de um objeto.
Vamos dizer que temos uma classe "Nota" e uma outra classe "Item", na classe Nota contém objetos da classe Item, assim também agrega os seus objetos pois o item faz parte da nota. Para buscar informações de um Item é preciso que a classe Nota instancie a Item para que assim utilize as informações de Item.
Nesse caso a classe Nota é um grande candidato para criar as instâncias, assim podemos definir que uma classe criador é uma classe que irá: conter, agregar, instanciar, usar ou possuir objetos de uma outra classe.

Aula 5 e 6 de Projetos Orientado a Objetos

As cinco primeiras atribuições de responsabilidade nos princípios fundamentais de projetos baseados em objetos.
Especialista na informação surge do seguinte principio: Existe uma situação onde é esperado um resultado e para chegar a ate este resultado, devemos encontrar a classe que contenha a informação necessária para dar a solução.
Desta forma podemos fazer uma analogia de que para um software cada “especialista” tem sua responsabilidade, visualmente para o usuário do software esta tudo sendo realizado em um único lugar, porem na realidade para chegar ao resultado desejado o software junta todas as classes que contenham as informações onde irão gerar o resultado desejado. Como exemplo podemos citar um estoque onde manualmente o responsável pelo estoque deve retirar o produto diminuir do estoque e calcular a quantidade atual, já com isso automatizado o software terá varias classes onde cada uma terá sua responsabilidade, sendo assim as informações estão dispersas onde serão reunidas para se chegar ao resultado.
Assim temos como conseqüência o fraco acoplamento entre objetos, o encapsulamento é mantido e dando uma maior coesão sendo que os fazem tudo relacionado às suas informações.

Aula 3 e 4 de Projetos Orientado a Objetos

Citados na postagem anterior, os diagramas de seqüência e de colaboração são duas ferramentas utilizadas para maior entendimento do que será executado no projeto e até mesmo uma forma de mostrar graficamente para leigos em código de programação entenderem. O diagrama de colaboração é mais simples em comparação com o diagrama de seqüência, ou até mesmo podemos dizer que um pouco desorganizado, pois as classes e associações não tem uma linha definida, pode ser organizada conforme ficar melhor no espaço existente sendo assim facilitando para quem criar uma desorganização, porem poderá ser organizado se o construtor o fizer bem. Já no diagrama de seqüência é criado em raias, ou seja para cada objeto criado surge uma raia que determinará o seu "tempo de vida", assim sendo mais assimétrico, e conforme as mensagem são criadas de objeto para objeto a linha de tempo vai descendo, ou seja, a seqüência respeita a ordem de cima para baixo e seguindo se as setas, como um mapa de caça ao tesouro. Em ambos diagramas para cada instancia criada é necessária a utilização da palavra create, para definir que esta sendo criada uma nova instancia de um objeto. Dentro disso existem padrões a serem seguidos, como qualquer outro projeto. Seguir regras, criar modelos e ter referencias e etc.

Aula 1 e 2 de Projetos Orientado a Objetos

Em se tratando de projetos orientado a objetos podemos citar dois pontos fortes: Análise e Implementação. A parte de análise, que é o start do projeto pois é onde envolve toda parte levantamento de requisitos, entrevistas com usuários e definição dos pontos com o cliente e etc. Trabalhar com o princípio do 5W2H, Why(Por que), What(O que), When(Quando), Who(Quem), Where(Onde), How(Como), How Much(Quanto), utilizar a WBS como modelo de gestão de projeto, ou seja, todo planejamento de pessoas, tempo e custo. Definições de tecnologia são muito importantes nessa etapa do projeto, pois a analise é realizada com base na tecnologia a ser utilizada na implementação. Após esta fase de análise vem a parte de implementação do projeto, ou seja, o passo posterior a análise, colocar em prática o que foi levantado. Ferramentas de UML são muito importantes nesse momento, pois é da leitura de diagramas como: Seqüência ou colaboração, que irão definir as tarefas que serão executadas pelo software e de que forma quem esta utilizando deverá proceder. Sendo assim o uso de UML da se por importante pelo fato de que uma analise mal elaborada terá grandes chances de resultar em um projeto mal sucedido, alem de que mantém uma documentação completa do projeto facilitando em sua manutenção que se da durante toda elaboração do projeto.