Padrões GRASP (Padrão Especialista na informação)

AULA 5

Como foi abordado na postagem anterior, padrões de software são princípios gerais de soluções que guiam o desenvolvimento de software, em outras palavras, são normas que permitem o desenvolvimento de alta qualidade de produtos de software. Existem nove destes padrões, mas vamos nos concentrar apenas nos cinco primeiros que são:

1. Especialista na informação: Padrão mais utilizado para atribuir responsabilidades, é aquele que atribui responsabilidades a quem realmente detêm a informação necessária para preencher os requisitos daquela responsabilidade.
2. Padrão Criador: qual a classe responsável por criar instâncias de outra?
3. Baixo Acoplamento: responsável por minimizar dependências entre as classes e maximizar o reuso.
4. Alta Coesão: responsável por manter a alta coesão entre as classes, ou seja, delegar responsabilidades e não deixar que certas classes assumam responsabilidades de outras.
5. Controlador: responsável por tratar eventos do sistema, eventos são operações geradas por um ator externo do sistema.

Agora que já definimos cada um dos cinco primeiros padrões, vamos entender cada um com mais clareza.

Padrão Especialista

O principal objetivo dos padrões de projeto de software é a atribuição de responsabilidades, e o padrão especialista como o próprio nome já diz, é aquele responsável por atribuir responsabilidade à classe que tem informação necessária para suprir aquela responsabilidade.

É o padrão mais usado de todos, a informação necessária para uma determinada classe geralmente está espalhada entre várias classes, e através deste padrão é possível descobrir esta informação, bem como no mesmo caminho feito para esta descoberta, conhecer outros “expert information” de outras classes que estão relacionadas entre si.

As conseqüências do uso deste padrão é que o encapsulamento é mantido, já que objetos usam sua própria informação para cumprir responsabilidades, leva ao fraco acoplamento entre objetos e à alta coesão já que objetos fazem tudo que é relacionado à sua própria informação.

Este Padrão também é conhecido como:

1. "Colocar as responsabilidades com os dados";
2. "Quem sabe, faz";
3. "Animação";
4. "Eu mesmo faço";
5. "Colocar os serviços junto as atributos que eles manipulam";
   

5 primeiros Padrões

Atribuições de Responsabilidades e Padrões de Projeto

Aula 4

Quando entramos em um novo emprego e já temos experiência nas atividades que vamos exercer naquela empresa pode ocorrer duas coisas: primeiro, o chefe nos atribui responsabilidades sobre a nossa parte do serviço, ou seja, temos obrigação de fazer determinadas tarefas, é o que foi designado para fazermos, segundo, como já temos experiência sobre o serviço que nos foi passado, ou seja, já conhecemos o trabalho que iremos desenvolver, temos a obrigação de conhecer sobre as nossas responsabilidades.

A mesma coisa acontece com um sistema orientado a objeto, ele é composto de objetos que enviam mensagens uns para os outros, lembrando que uma mensagem é um método executado no contexto de um objeto, ou melhor, dentro do objeto, pois bem, continuando, se um objeto de uma classe não sabe quando disparar determinado método ou conhecer os objetos ao qual está relacionado, definitivamente a comunicação entre objetos nesse sistema estará seriamente comprometida.

Padrões de software são um conjunto de princípios gerais e de soluções que guiam o desenvolvimento de software. São eles que definem a distribuição de responsabilidades entre objetos ou classes. Segundo a UML, as responsabilidades de objetos estão divididas em dois tipos e possuem diferentes granularidades:

Obrigação de fazer: o objeto pode fazer algo a si mesmo, pode iniciar, controlar ou coordenar ações em outros objetos.

Obrigação de conhecer: um objeto tem obrigação de conhecer os objetos aos quais está relacionado, conhecer dados encapsulados.

Granularidade baixa: uma responsabilidade pode envolver um único método, ou poucos.

Granularidade alta: uma responsabilidade pode envolver dezenas classes e métodos.

Só lembrando que uma responsabilidade não é um método, mas os métodos são usados para implementar responsabilidades.

Referências:

Padrões para atribuir Responsabilidades

Diagramas de Interação

Aula 3

A UML é uma linguagem para especificação, documentação e melhor visualização de sistemas orientados a objetos. Ela permite que os desenvolvedores visualizem melhor os produtos do seu trabalho através de diagramas, mas não diz como fazê-los.

A UML possui diversos diagramas, sendo a maioria deles para a fase de análise, os mais importantes da fase de projeto são os diagramas de interação, estes diagramas são responsáveis por mostrar como as mensagens interagem entre os objetos, lembrando que essas mensagens se referem a métodos, e um objeto só se comunica com outro se conhecer os métodos deste, um objeto ainda pode mandar mensagens a outro mesmo quando ele não estiver ativo, ou até mesmo quando ainda não foi criado, isso é possível através do conceito de enfileiramento, basicamente como o cash de um sistema operacional. Os diagramas de interação podem se subdividir em dois: Diagrama de Seqüência e Diagrama de colaboração.

Diagrama de Seqüência:

Ilustram a interação entre os objetos através de raias que são colocadas sempre à direita de cada novo objeto, as mensagens para cada objeto seguem uma ordem vertical de cima para baixo, com isso a clareza dessas mensagens é evidente. As trocas de mensagens podem ser tanto síncronas, quando o controle é passado para o objeto que foi invocado até que esse método termine sua execução, quanto assíncrona, quando o controle é passado diretamente para o objeto que invoca o método.

Particularmente é um bom diagrama para se trabalhar, pela simplicidade e pela fácil localização de mensagens.

Ex:

Diagrama de colaboração:

O diagrama de colaboração, diferentemente do diagrama de seqüência, procura dá ênfase na localização estrutural dos objetos e não na ordem temporal das mensagens destes objetos, a identificação dos objetos é feita através de enumeração, uma vez que estes ficam misturados, é difícil identificá-los, assim como no de seqüência, um objeto é representado por um retângulo e a convenção na troca de mensagens também é a mesma.

O diagrama de colaboração possui uma notação mais complexa, mas são os mais adequados para explicar ou demonstrar rapidamente um processo na lógica de um programa.

Ex:

Referências:

Unicap

Elementos da UML

Análise e Projeto Orientados a objeto

Aula 1 e 2

Análise e projeto orientados a objetos, quais são as diferenças entre eles e quais as definições de cada um.

A análise é a fase onde é feita o levantamento de informações que definirão as características do sistema, esse é um passo importante, pois não se trata somente de levantar dados aleatoriamente, mas de compreender o objetivo daquele sistema. No caso da análise orientada a objetos é onde é feita a representação dos objetos e suas estruturas, definições de classes, relacionamento entre objetos e classes, além de observar o comportamento dos objetos.

Já o projeto parte do ponto onde termina a análise, ou seja, inicia-se a partir dos dados levantados através da investigação feita pela análise, em outros termos, é uma investigação mais profunda, onde começa a surgir a solução para o problema.

Em uma linguagem mais simples, a análise é onde é definido o problema, entender o problema, já o projeto é a solução, criar soluções para o problema. Na análise as informações são para o cliente discutir e aprovar, já no projeto as informações são importantes apenas para o programador.