Padrão Controller

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.

Lida com o tratamento de mensagens ou eventos de sistema.

Atribuir a responsabilidade de tratar eventos do sistema a uma classe que representeuma das seguintes opções:

▪Representa o sistema como um todo, um dispositivo ou um subsistema (umcontrolador fachada);
▪Representa um caso de uso em que o evento de sistema ocorre (controlador de casode uso ou sessão).

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.

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

Acoplamento de Controle

Um controlador é um objeto responsável por tratar um evento de sistema (caso de uso), mas que pertence à camada de domínio.

Problema:
Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?

Solução:
Uma classe que representa uma das seguintes opções:

– Representa o ”sistema”, todo o negócio ou organização (Controlador fachada);
– Representa todo o negócio e
– Representa algo do mundo real que é ativo e envolvido na tarefa (Controlador de papel);
– Representa um “tratador artificial” dos eventos de sistema de um caso de uso (Controlador de caso de uso)

O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.

Existem duas alternativas possíveis para o objeto controlador:

- Um objeto Controlador para todo o sistema
- Um objeto Controlador por 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.

» Evita que objetos da camada apresentação tratem as operações do sistema;
» Aumenta o potencial de reutilização;
» Possibilita o controle de seqüência de operações do sistema.

Padrão Baixo Acoplamento:


O padrão baixo acomplamento tem como objetivo a redução e miniminização da conexão de um objeto com outros. Esta conexão esta relacionada a ter conhecimento sobre os outros objetos ou simplemente depender de outros objetos. De forma sujacente manter o acoplamento baixo significa redizir o impacto de mudança já que ao se alterar um objeto um mínimo de outros objetos serão afetados.

Problema: Como aumentar independência dos objetos de forma a possibilitar a sua reutilização?

Solução: Atribuindo responsabilidades de maneira que o acoplamento permaneça fraco.


Resulta num acoplamento geral mais fraco entre as classes:

»Resulta em classes mais independentes;
»Reduz o impacto de mudanças;
»Aumenta o potencial de reutilização;
»Não deve ser utilizado isolado dos outros padrões.

public class Produto
{
private integer idProduto;
private string descrição;
private double valorUnitário;

public string getdescrição(){
return dscrição;
} public void setDescrição(string valor)
{ descrição=valor;
}

public class ItemVenda {
private double qtde;
private Produto p;

public void setP (Produto p) {
this.p = p;
}

public class Venda {
private Set itemVendaLiat=new HashSet();
private Date dataVenda;
private integer idvenda;
public criar Itemvenda (Produto P, double qtde)
{
Itemvenda i =new ItemVenda();
i.setP(p);
i.setQtde(qtde);
itemVendaList.add(i);
}

Atribui à classe "A" a responsabilidade de instanciar a classe B caso algumas destas condições sejam verdadeiras (quanto mais alternativas sejam verdadeiras melhor).

Padrão Criador

Problema: Quem deveria ser responsável pela criação de uma nova instância de classe?

Solução: Atribuir à classe B a responsabilidade de criar uma instância da classe A se uma das seguintes condições for verdadeira:

– B agrega objetos A;
– B contém objetos A;
– B registra instâncias de objetos A;
– B usa de maneira muito próxima objetos A;
– B tem os dados de inicialização de A (B é expert em
relação à criação de A.

Acoplamento
O acoplamento é uma medida de quão fortemente uma classe está conectada a outras classes, tem conhecimento das mesmas ou depende delas.

Problema: Como aumentar independência dos objetos de forma a possibilitar a sua reutilização?

Solução: Atribuindo responsabilidades de maneira que o acoplamento permaneça fraco.

Alta Coesão

Coesão é a medida de quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe.

Problema: Como manter a complexidade de um sistema ou objeto sob controle?

Solução: Atribuindo responsabilidades de maneira que a coesão permaneça alta.


Acoplamento fraco e coesão alta são princípios a serem seguidos durante todas as decisões de projeto; são objetivos adjacentes a serem levados em conta continuamente.

Uma classe com coesão baixa faz muitas coisas não relacionadas, ou executa demasiado trabalho.

»Coesão funcional alta especialização das classes;
»Uma classe com Coesão alta tem um número relativamente pequeno de métodos, com funcionalidades altamente relacionadas;
»A manutenção e as melhorias do sistema são facilitadas;
»Reduz o impacto de mudanças;
»Aumenta o potencial de reutilização;
»Não deve ser utilizado isolado dos outros padrões.

Aula realizada em Laboratório.

Um sistema O.O. é composto por vários objetos que colaboram entre si, trocando "mensagens" para satisfazer aos requisitos do sistema proposto, o planejamento de como dividir as responsabilidades entre os objetos é essencial para obter um sistema fácil de entender, robusto, reutilizável e extensível.

GRASP: ajuda a definir as responsabilidades, o seu estudo possibilita entender os princípios de um bom projeto O.O.

Responsabilidades: São as descrições do que os objetos tem de fazer, os métodos são as implementações das responsabilidades.
Obs: nem sempre uma responsabilidade é satisfeita somente por um método, grandes responsabilidades são divididas para manter a coesão da Classe.


Os principais padrões GRASP:

- Especialista
- Criador
- Coesão alta
- Acoplamento fraco
- Controlador


Especialista na Informação:

Problema: Qual é o princípio geral para a atribuição de responsabilidades aos objetos?

Solução: Atribua a responsabilidade ao especialista: a classe que tem as informações necessárias para assumir a responsabilidade.

Benefícios: O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas.

Isto normalmente leva a um baixo acoplamento entre as classes.

O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter.

Contradição: Em algumas situações, a solução sugerida pelo especialista pode ser indesejada, por às vezes causar baixa coesão.

Padrões GRASP - (General Responsibility Assignment Software Patterns)
Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto.

As responsabilidades estão relacionadas às obrigações de um objeto em termos do seu comportamento.
Elas são de dois tipos:
-- Conhecer
-- Fazer

As responsabilidades de fazer de um objeto incluem:
- Fazer algo ele próprio
- Iniciar ações em outros objetos
- Controlar e coordenar atividades em outros objetos

As responsabilidades do conhecer de um objeto incluem:
- Conhecer dados privados encapsulados
- Conhecer objetos relacionados
- Conhecer coisas que ele pode derivar ou calcular

Exemplos:
• Uma Venda tem a responsabilidade de criar linha de detalhe (fazer algo).
• Uma Venda tem a responsabilidade de saber sua data (conhecer algo).

Granularidade

Uma responsabilidade pode envolver um único método (ou poucos).
Exemplo: Criar uma linha de detalhe.

Uma reponsabilidade pode envolver dezenas de classes e métodos.
Exemplo: Responsabilidade de fornecer acesso a um BD.

Uma responsabilidade não é igual a um método.
Mas métodos são usados para implementar responsabilidades.

Uma responsabilidade não é a mesma coisa que um método.
Os métodos são implementados para satisfazer responsabilidades.

As responsabilidades são implementadas usando métodos que agem sozinhos ou colaboram com outros métodos e objetos.

Referências:
LINK 1
LINK 2

Diagrama de Sequência:
O diagrama de seqüência dá ênfase à ordenação temporal das mensagens e as principais características que o diferencia do diagrama de colaboração são: possui linha de vida do objeto que é uma linha tracejada que representa a existência de um objeto em um período de tempo e também existe o foco de controle que é um retângulo alto e estreito que mostra o período durante o qual o objeto está desempenhando uma ação, diretamente ou por meio de um procedimento subordinado, enquanto que o diagrama de colaboração possui um caminho para identificar se o objeto é global, local etc e possui também um número de seqüência que indica a ordem temporal de uma mensagem.
Exemplo:



Diagrama de Colaboração:
O diagrama de colaboração dá ênfase à organização estrutural dos objetos que enviam a recebem mensagens. O diagrama de colaboração é formado colocando-se primeiro os objetos que participam da interação como os vértices de um gráfico, depois, representa-se os vínculos que conectam esses objetos como os arcos dos gráficos e finalmente, adorna-se esses vínculos com as mensagens que os objetos enviam e recebem.
Exemplo:


Obs: Os diagramas de seqüência e colaboração são semanticamente equivalentes, sendo assim, o diagrama de uma forma pode ser convertido no outro sem qualquer perda de informação, entretanto, isso não significa que os dois diagramas visualizarão as mesmas informações explicitamente.

Link Referência Bibliográfica

Projeto Orientado a Objeto:
Objetivo: Projetar sistemas usando objetos auto-contidos e classes de objetos.

Análise vs Projeto

Análise: é modelar um problema, é uma atividade de investigação. "O que deve ser feito", ou seja, entender.

Projeto: é a modelagem da solução, se dedica a desenvolver um modelo orientado a objeto de um sistema de software para implementar os requisitos.

Durante a Análise OO, a ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema.

Durante o Projeto orientado a objeto, a ênfase está em achar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem de programação OO. Esses objetos podem ter atributos ou métodos.


Continua....