GRASP - Padrão Criador - Aula 7

BLOG referente a aula 7 do dia 25/2/2008 – Padrão GRASP Criador.


Boa tarde !!!!!

Bom , conforme combinado semana passada continuarei a explicar os conceitos explicados em aula , vou tentar passar a minha visão sobre o que me foi entendido.

Já começamos a falar do padrão Criador ressaltando um problema característico.

A quem pertence a responsabilidade em criar novas instâncias de uma classe ??

É tão obvio que nem precisa de resposta , visto o nome do padrão , certo ? Ao padrão criador é atribuída essa responsabilidade , é ele quem cria as instancias da classe.

Vamos tomar como exemplo a classe BETA e a classe ALPHA , vejamos que para que beta seja dado como criador da classe ALPHA é preciso que se aplique pelo menos duas das condições abaixo:

- BETA agrega os objetos da classe ALPHA
- BETA contém os objetos da classe ALPHA
- BETA registra as instancias da classe ALPHA
- BETA usa muitos objetos da classe ALPHA
- BETA possui os dados usados para iniciar ALPHA

Se pelo menos duas das condições acima tornarem-se verdadeiras então BETA se consolidará como criador de ALPHA.

Vejamos o exemplo abaixo:

De acordo com a figura acima , quem deveria criar uma instancia de LinhaDetalheVenda deveria ser a classe Venda , pois a mesma agrega as instâncias de LinhaDetalheVenda.

Chegando a essa conclusão temos o seguinte diagrama:

Onde como podemos ver , a classe Venda tornou-se criadora dos objetos da classe LinhaDetalheVenda.

O objetivo mais comum do padrão Criador é encontrar um criador de que tenha necessidade em se conectar com o objeto criado e essa conexão se faz pelo princípio da agregação que se baseia no conceito todo-parte ou montante-parte , como um Avião que agrega uma asa ou um corpo agrega um braço.

Geralmente a criação é um trabalho meio árduo , complexo pois na maioria das vezes é utilizado para melhorar aplicações já existentes melhorando assim a sua apresentação , o que evita o efeito espaguete , como falado em aula.

Bom , sei que parece que não me expressei muito hoje , mas é que este assunto é pequeno mesmo , espero ter me expressado corretamente , aguardo comentários , pois toda e qualquer forma de crítica vinda será considerada como construtiva.

Abraço a todos !!!!

Até o próximo blog.

21/2/2008

Esta postagem é referente a 5ª aula do dia 18/2/2008

Introdução ao GRASP - 1ª Parte:

Estou de volta !!!!!
Mais uma semana de aula , e como aconteceu na semana passada vou tentar passar um pouco de meu entendimento sobre o que foi passado na 5ª aula.

Vamos começar uma introdução sobre o GRASP.
Pêra aí , o que é GRASP ????
Poxa vida!!! ,eu nem começo a explicação e já vou falando grego !!!
Calma !, GRASP nada mais é do que um conjunto de padrões que tem por objetivo atribuir responsabilidades aos objetos.
Mas que responsabilidades ???
São as obrigações dos objetos em relação ao seu comportamento perante a outros objetos.
Podem ser de dois tipos:
Obrigação em conhecer: é a obrigação que um objeto tem em conhecer os objetos com o qual se relaciona assim como os seus comportamentos.
Bom , vou me arriscar e dar um exemplo meu mesmo , me corrijam se eu tiver errado.
Ex: “A classe compra é responsável por conhecer o seu total”.
Obrigação em fazer: Esse é bem mais fácil , é a parte criativa e operacional do processo, nela se cria um objeto , ou pode-se encadear uma ação em outros objetos
Segue abaixo mais um exemplo!!!
Ex: Um empréstimo é responsável por criar TiposDeEmprestimo”.

Pude concluir que essas responsábilidades as quais o assunto se refere são obrigações de um tipo ou de uma classe e que podem possuir diferentes tipos de granularidades.

São duas

Granularidade Baixa - Nela uma responsabilidade pode envolver um único método.

Ex: Criar uma linha de detalhe.

Granularidade Alta - Nela uma responsabilidade pode envolver várias classes e métodos.

Ex: Responsabilidade de fornecer um acesso a um BD.

OBS: é importante salientar algo , é muito importante não confundir responsabilidade com método , pois são duas coisas diferentes , os métodos são usados apenas para implementar as responsabilidades.

Falando em métodos , existem aqueles que agem por sí sós ou ajudam outros métodos.

Exemplo: A classe venda pode definir um ou mais métodos para conhecer seu total. Para conseguir esse objetivo a Venda pode enviar uma mensagem obterSubTotal para cada objeto LinhaDeItemDeVenda.
Fonte: Material do Professor Bosco

Responsabilidades e Diagramas de iteração

Essa parte não foi tão difícil de entender , se eu estiver certo os diagramas de iteração nos orientam quanto as atribuições das responsabilidades aos objetos.

O diagram acima mostra que os objetos da classe venda são responsáveis por criar linhas de detalhe de venda e que devem colaborar com os objetos da classe LinhaDetalheVenda.

Padrões

Padrões descrevem um problema que ocorre frequentemente , então eles descrevem uma forma de solução padrão , solução essa que poderá ser utilizada em vários tipos diferentes de problemas , mas veja que o que se reutiliza são apenas as classes e as suas colaborações.

Curiosidade: Os Padrões GRASP são de Larman , que se não me engano é o autor do livro que adotaremos neste semestre , "é pelo jeito o Larman não é fraco não".

Bom já falei muito dos padrões , mas acho melhor eu parar de enrolar um pouco e começar falando do primeiro padrão que é:

Especialista na informação:

Nada mais é do que a classe que possui a informação necessária para safizfazer a necessidade imposta.

Geralmente é procurada no modelo de projetos.

Bom , mas uma vez espero ter passado com clareza minhas conclusões

Semana que vêm continuarei com a segunda parte sobre este importante assunto

um bom fds a todos !!!!!!

abraço !!!!

Uma introdução a POO(Projeto Orientado a Objeto) na minha visão

By Marcos Vinicius

Maravilha , finalmente estou chegando ao ponto de bala , sexto termo onde começarei a por a mão na massa , ver as tendências de mercado , me aprofundar mais em JAVA e principalmente em UML.
Como pude concluir a matéria em questão ministrada pelo professor João Bosco é uma continuação da rotina de um projeto , pelo que puder entender em UML eu aprendi a fazer os diagramas , já a fase de projeto é como uma tradução do que esta no diagrama para o código propriamente dito.

A fase de projeto que é a nossa área de estudo no momento nada mais é do que colocar no código fielmente toda a análise dos requisitos contidas nos diagramas, tanto a fase de analise quanto a de projeto estão sujeitas a várias mudanças , mudanças essas que podem ser feitas nas implementações até que se estabilize a iteração.

O projeto baseado em objetos é feito em cima dos diagramas de colaboração e de seqüência , mas primeiramente para um melhor entendimento é preciso se perguntar , para que a utilização deles ?

Primeiramente eu entendo que se um sistema nada mais é do que vários objetos , esses mesmos objetos precisam se comunicar , é aí que entram os diagramas de iteração. É nesses diagramas onde ocorre a troca de mensagens entre os objetos , uma forma de ilustração de como os objetos colaboram entre si com o objetivo de atender os requisitos feitos na análise.

Agora vou falar um pouco dos diagramas de iteração , são dois:

Diagrama de Colaboração – Bom não tenho nada contra a preferência de ninguém , mas eu particularmente prefiro o diagrama de seqüência , pois é bem mais ordenado que o de colaboração , o D.C apesar de ser bem ilustrado não apresenta nenhum tipo de ordenação e sua leitura é bem mais complexa , eu mesmo como aprendiz passaria bem longe dele , mas isso é só uma opinião pessoal minha , a única vantagem que eu vejo nele em relação ao de seqüência é a sua flexibilidade em relação a espaço.

Segue abaixo um exemplo um pouco mais complexo que o apresentado na aula:

Fonte: www.netbeans.org/images/diagram

Diagrama de seqüência: Apesar de não ter muita experiência ainda em diagramas , eu já gosto mais deste , pois a sua organização em raias facilita mais o entendimento e é bem mais simples de se entender , não tem erro , o seu fluxo vai de cima para baixo , da esquerda para a direita , sendo que o seu único problema ao contrario do diagrama de colaboração é o grande consumo de espaço.

Segue abaixo um outro exemplo de diagrama de seqüência , diferente ao apresentado na aula:


Fonte: http://www.ime.usp.br/~kon/MAC5715/2002/DesignFest/M2/diagramaDeSequenciaDeEscolheSessao.jpg

Bom , vou tentar mesmo que errando explicar este diagrama .

A mensagem obterSessoes é enviada para uma instancia de ControladordeSessões só que ao contrário do exemplo da aula , essa mensagem é enviada por um ator “Interface do Jogador”.
O objeto ControladorDeSessões envia uma mensagem obterSessões para o objeto ServidorDeSessões ,este por sua vez envia uma mensagem de retorno “Lista de sessões” ao objeto ControladorDeSessões que por sua vez envia esta mesma mensagem “Lista de sessões” ao ator do sistema “Interface do Jogador” e assim por diante os objetos vão se comunicando através das mensagens enviadas.

Obs: Se houver erro na minha tentativa de explicação , aceito opiniões na boa !!!

Bom já expliquei mais ou menos como funcionam os diagramas , agora vêm a parte de como confeciona-los , e como tudo na vida é baseado em regras , aqui vão umas boas regras para uma boa confecção de um diagrama:

Primeiramente , um diagrama precisa ser bem detalhado , fiel ao que esta sendo proposto no projeto , não pode apresentar falhas e nem brechas , deve consumir cerca de 10% do tempo necessário para iteração e deve ser feito por duas pessoas de preferência , pois como foi dito em sala duas cabeças pensam melhor do que uma, dependendo do tipo de projeto até mais cabeças pensantes seriam bem vindas.

Representando as ilustrações no diagrama:

Como foi visto nos exemplos anteriores , os diagramas possuem classes e instancias, vou representa-las a seguir:

Classe: é representada por um retângulo com o nome da classe em sublinhado.

Instância: é representada por um retângulo com o nome da classe em sublinhado precedido de dois pontos.

Mensagens :

Mensagem de retorno: representa uma resposta de um objeto dentro do diagrama de iteração, sendo essa mesma mensagem omitida se for considerada óbvia ou não muito importante.

São indicadas por setas ,essas indicam o fluxo da mensagem dentro do diagrama:

Seta contínua: Mensagem
Seta tracejada: Retorno

Existe um outro tipo de mensagem chamada SELF , onde um objeto "Compra" por exemplo envia uma mensagem para ele mesmo.

Terminando o assunto até esta 4ª aula chegamos a um diagrama bem curioso , no qual existe uma iteração entre um objeto sobre uma coleção de métodos.

Exemplo:

Fonte: Material de aula do professor João Bosco

Bom , para quem leu e gostou , isso é o que me foi entendido até agora , não deixem de entrar , pois semana que vêm tem mais novidades

abraços a todos !!!!!