Alta Coesão

Blog referente a aula do dia 24/3/2008

Padrão GRASP Alta Coesão

A abordagem desse assunto nos leva a seguinte pergunta sempre que nos deparamos com classes complexas.

Como gerenciar a complexidade ?

A Coesão mede quão focadas ou relacionadas estão os módulos de uma classe.

Características de uma classe com baixa coesão.

- Difícil de entender

- De difícil reuso

- De difícil manutenção

- Assumi responsabilidades demais , ou seja , causa uma sobrecarga na classe.

E qual seria a solução ???

Atribuir responsabilidades aos métodos mantendo-se a coesão.

Como nós já sabemos , quanto maior a coesão mais baixo o acoplamento e isso é a melhor solução no caso.

Tipos de Coesão

Coesão Coincidental

Nela não existe nenhuma coesão entre os módulos , eles se agrupam por coincidência

public class Angu{

public void acharPadrão ( ){

}

public void calcularMedia ( ){

}

public void obterArquivo ( ){

}

Lógica

Este Padrão tem que ser respeitado assim como o baixo acoplamento, a alta coesão deve ser mantida dentro do método.

Coesão Temporal

Os módulos estão coesos , por algum evento temporal.

Ex: inicializar , finalizar.

Um outro exemplo é o famoso arquivo "INI" do Windows, vc coloca tags nesse arquivo INI que configura tudo, isso é um exemplo de coesão temporal.

Coesão de Comunicação

Nessa coesão os métodos agem sobre o mesmo dado , mas isso não significa que sejam métodos coesos, portanto não deveriam estar juntos.

Coesão sequencial

Essa aí não é tão ruim , mas esta longe de ser a melhor

Ocorre da seguinte maneira , nela os módulos estão juntos apenas pq a saída de um é a entrada do outro.

Coesão Funcional

Nela os módulos estão coesos de tal forma a trabalhar num mesmo objetivo, ou seja todos os métodos estão focados em um único objetivo.

Coesão Procedural

Esta envolvida com agrupamento de módulos, faz com que os módulos se agrupem por procedimentos, mesmo não sendo coesos.

Agora que vimos um pouco sobre alta coesão , vamos falar um pouco sobre as suas consequencias

- Melhora o reuso da classe

- Melhora o entendimento da classe

- Nela vc regula a forma de granularidade da aplicação

Bom , isso foi tudo o que eu entendi até agora , com isso nós encerramos os Padrões GRASP, espero que tenha sido útil a alguém o que eu escrevi , e fico no aguardo de comentários !!!!!

Bom fds a todos

boa prova para todos nós !!!!

Blog referente a aula do dia 17/03

Acoplamento de controle

Ele ocorre quando se quer passar flags de controle entre objetos de forma que um objeto controle o outro objeto.

O objeto A envia uma mensagem ao objeto B e B usa o parametro para decidir o que fazer , a classe varia conforme o parametro passado para ela.

Nesse tipo de acoplamento uma classe tem o poder de controlar o comportamento da outra classe , ou seja a classe Alpha controla todo o comportamento da classe Beta, mas o que nós na verdade queremos é acabar com essa dependencia entre as classes, mas como nós fazemos isso ???

Simples , é só decompor a operação em multiplas operações primitivas.

Acoplamento de dados globais

Ocorre quando dois ou mais objetos compartilham os mesmo dados

Acoplamento de dados internos ( considerado o pior acoplamento)

Ocorre quando um objeto altera os dados globais de um outro objeto ou seja , a classe A altera a instancia de B alterando assim todo o estado de B.

Como se resolve esse problema ?

Usando - se uma variável private e um par de métodos acessores e mutatórios para controlar , principio do encapsulamento.

Bom feriado a todos !!!!!

até a próxima !!!!!!

Blog referente a aula 10 do dia 10/03/08
Baixo acoplamento
Primeiramente o que vêm a ser acoplamento ??
Nada mais é do que a medida da dependência de uma classe em relação a outra.
Baseado nessa resposta podemos definir como baixo acoplamento a não dependência de uma classe sobre outra.
Quando existe uma dependência bem destacada entre duas classes , nós podemos dizer que entre elas existe um acoplamento forte.
Acoplamento forte ocorre muito em herança , associação , agregação , pois elas nada mais são do que relacionamentos de dependência entre duas classes.
Geralmente o Acoplamento forte apresenta alguns tipos de problemas que irei listar abaixo:
1º - É de difícil entendimento , ou seja , nesse caso para se entender uma classe seria preciso entender todas as outras.
2º - Mais difícil de se reutilizar , pois para que se possa reutiliza-lo eu tenho que mudar a classe para um outro lugar , sendo assim eu teria que levar todas as outras classes junto.
3º - De difícil manutenção, ou seja a mudança em uma classe acaba se propagando para as outras classes.
Vendo todos esses problemas , qual seria a solução mais acertada para eles ?
Se alguém respondeu que é minimizando o acoplamento , acertou em cheio.
Diminuindo-se o acoplamento, diminui-se simultaneamente o problema da dependência entre as classes, e lembre-se de que em um diagrama pode ocorrer conflito entre padrões , mas já fique sabendo que sempre que isso acontecer , não perca tempo, opte sempre pelo baixo acoplamento.
Tipos de Acoplamento
- Acoplamento de dados
- Acoplamento de controle
- Acoplamento de dados globais
- Acoplamento de dados internos

Espero que tenha sido bem proveitoso este aprendizado

Até o próximo blog

Boa semana a todos !!!

PADRÃO CRIADOR - PARTE 2

Blog referente a aula 9 ministrada no dia 3/3/2008

By Marcos Vinicius

Padrão Criador – Parte 2

Vejamos a figura abaixo:




Como podemos ver logo acima ,trata-se de um diagrama de classes , onde lógicamente podemos contabilizar 4 classes, colocaremos em código todas as classes do diagrama caracterizando assim o seu criador.

Mas , por onde devemos começar ??

Fácil , aprendi uma importante dica , nós sempre começamos pela classe menos acoplada , ou seja aquela que é menos dependente.

Agora fica fácil determinar por onde começar , como podemos ver na figura acima das quatro classes a menos dependente é Produto , pois ela não depende de nenhuma outra classe , ao contrário de ItemVenda que depende de Produto , Venda que depende de ItemVenda e por ultimo a classe Main que pelo que eu entendi em aula depende de todas as outras 3 classes.

Bom , vamos começar então pela classe produto , que no nosso caso é a menos dependente.

Como ela ficaria em código ??

Confira abaixo:

CLASSE PRODUTO:

Public class Produto // declaração da classe Produto
{
// Quais seriam os atributos de produto ???
// Poderiam ser código do produto , descrição do produto e valor.

private integer idProduto;
private String descrição;
private Double valorUnitário;

// a seqüência abaixo seriam os nossos métodos assessores e multatórios GET e SET.

/*Antes de continuarmos preciso relembrar um pouco das funções de GET e SET, eles são usados para transformar atributos privados e atributos públicos , para que assim possam ser vistos por outras classes , mas principalmente são utilizados para dar controle a aplicação.*/

public string getDescrição(){

return descrição;
}

public void setDescrição (String valor){
descrição = valor;
}

CLASSE ITEMVENDA:

public class ItemVenda {

// Quais os atributos de ItemVenda ??

private Double qtde;
private Produto p;

// abaixo seguem os métodos assessores e mutatórios.

public void set p (produto p){
this.p = p; // lembre que o “p”em questão tem que ser o mesmo que esta no parâmetro.
}

public class Venda {

// Por se tartar de uma classe que executará vários itens , um array viria bem acalhar , mas o array apresenta problemas com relação a tamanho , portanto utilizaremos aqui uma coleção.

Private Set ItemVenda.list = new hashSet( );

// onde a coleção é caracterizada pelos sinais de maior e menor sobre a classe ItemVenda.

Agora fica a pergunta , de onde saiu esse hashSet???

Bom , desculpe a sinceridade , mas até a aula de ontem era novidade para mim , bom , como “Set” é uma classe e não pode ser instanciada , o hashSet é utilizado para que se possa instancia-la.

private Date dataVenda;
private Integer idVenda;

// agora depois de tudo o que foi feito é que eu poderei criar ItemVenda !!!!

public criarItemVenda (Produto p, Double qtde)
{
ItemVenda i = new ItemVenda( ); // o “i” no caso é uma variável de instancia atribuída

i.setP (p);
i.setQtde (qtde);
itemVendaList.add (i);
} // cria um item de venda e a adiciona a coleção.

Continuando a aula do dia 03/03/2008 , como de costume fomos ao laboratório para as aulas práticas onde mais uma vez me impressionei com o poder da ferramenta NETBEANS.

O seu poder compilação é fantástico , temos até a possibilidade de reforçar a nossa lógica , onde através do processo “DEBUG FILE” podemos percorrer a aplicação podendo assim conhecer o passo a passo de toda a execução, é até uma forma de atualização e melhoria de nossos conhecimentos em lógica, não espero a hora de terminar de baixa-la para assim descobrir mais de seus segredos.

Bom , por hoje é só pepepessoal !!! hehehe

Espero que tenham gostado dessa postagem , estava bem mais inspirado hoje !!!

Boa semana a todos !!!!!

Até o próximo blog!!!

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