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....