Aula 20

Pardão Singleton

O padrão singleton tem o objetivo de instanciar somente uma vez o objeto que é varias vezes requisitado, assim não haverá varias instancias do mesmo objeto e consequentemente todos serão iguais.
Este padrão funciona quando se quer reaproveitar algo que já foi usado uma vez, e com isso diminuir o tempo gasto para processar essa operação.
O código para esse padrão é um código que verifica a existencia de uma instancia, caso essa verificação for positiva, ele somente retornará a instancia e não a fará novamente, se for negativa o sistema irá fazer a instancia para que na proxima não precise faze-la novamente.

O uso do atributo SYNCHRONIZED
O uso desse atributo server para que o método seja realizado por completo antes que seja chamado para ser executado por outro. Isso impossibilitaria que, no caso do singleton, seja instanciado 2 vezes, e quebrando o objetivo primário do padrão.

Padrões GOF

Padrão Adapter

O padrão adapter como o próprio nome já diz é um adaptador, serve para que uma classe possa usufruir de um método, por exemplo, de uma outra classe que de maneiras normais essa operação não seria possível.
Então temos, a classe origem que será a classe que vai querer executar o método e a classe destino, que possui o método a ser executado. Entre elas não há a comunicação, portanto deve haver a classe adapter que fará essa ligação. Na classe adapterOp, que é a classe adapter, vai ter a instancia do método que quer ser executado, e na classe origem vai ter a chamada do método da classe adapterOP e nela vai ter a chamada do método na classe destino, assim a chamada na classe origem executa a operação no método destino sem ter a comunicação direta com ela.

Padrões GRASP

· Especialista da Informação
· Criador
+ Coesão
· Acoplamento fraco
· Controlador


Coesão Alta


Problema: Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento?
Solução: Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas

Uma classe com baixa coesão sofre dos seguintes problemas:
- Difícil de compreender
- Difícil de reutilizar
- Difícil de manter
- Frágil; freqüentemente tem de ser alterada.

Como um princípio básico, uma classe com alta coesão:
- Tem um número relativamente pequeno de métodos
- A funcionalidade desses métodos é altamente relacionada
- Não faz trabalho de mais.

Padrões GRASP

· Especialista da Informação
· Criador
· Coesão
+ Acoplamento fraco
· Controlador


Baixo Acoplamento

Problema: Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização?

Solução: Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.Ponto-chave: O padrão especialista fornece "baixo acoplamento", pois o ele nos pede uma classe que tenha a maior parte da informação para executar uma tarefa em específico, se delegarmos a responsabilidade para uma classe "Animal" para tratar uma responsabilidade de persistência ao banco de dados o acoplamento será muito maior, pois eu terei de fazer algo para "Animal" entender sobre persistir o banco de dados que não tem nada a ver com sua função.

Padrões GRASP

· Especialista da Informação
+ Criador
· Coesão
· Acoplamento fraco
· Controlador


Padrão Criador
Nas aulas anteriores podemos ver que um software construido no paradigma de orientação a objetos é nada mais que uma coleção de objetos interagindo entre si, e o que vem a ser um objeto? Na linguagem técnica, é uma instancia de uma classe, e instância, o que é? É criar um objeto apartir de uma ou varias variaveis. Mas como é feito esse trabalho de criar objetos? Objetos são criados a partir de chamadas de procedimento, ou seja, de mensagens(métodos) enviadas por classes para que sejam criados novos objetos, mas agora, vem o ponto crucial deste assunto que estamos estudando, qual a classe correta, ou seja, qual a mais indicada para criar novas instâncias de outra classe(objetos)? Afinal, existem muitos deles dentro de um programa, e não é qualquer classe que pode sair criando objetos à vontade, portanto vamos à explicação: Segundo o Padrão Criador (Creator), para que uma classe tenha a responsabilidade de criar instâncias de outra classe é necessário que se aplique o procedimento a seguir: Vamos supor que existam duas classes A e B, a classe responsável por criar instância da outra será aquela em que mais de uma das seguintes condições se aplicar:

a. B agrega objetos da classe A.
b. B contém objetos da classe A.
c. B registra instâncias da classe A.
d. B usa muitos objetos da classe A.
e. B possui os dados usados para inicializar A.

Padrões GRASP

+ Especialista na Informação

· Criador

· Coesão

· Acoplamento fraco

· Controlador

+ Especialista na Informação

O essa tipo de padrão é responsável por nada mais nada menos do que especializar a classe que detém mais informação sobre o assunto em questão, essa especialidade independe se a busca em outras classes é possível ou não! O encapsulamento das informações é bastante aparente nesse tipo de padrão assim o acoplamento não é tão alto, podendo fazer com que o projeto seja mais "independente" entre as classes. A coesão dos dados é algo que deve ser levado em conta, e com a especialização da classe essa coesão pode ser garantida já que a classe só recebe o método especialista quando esta detém as informações necessárias.

O padrão especialista não está realmente presente no modelo de analise, ele normalmente e preferivelmente, aparece no modelo de projeto.

Primeiras Aulas

Aula 3 e 4 - 13/02/08
Diagramas de Interação

- Colaboração
- Seqüência

Diagrama de colaboração as ligações são feitas de forma simples e, representadas no modo de grafo, os objetos não tem uma localização especifica, a indicação das mensagens neste diagrama é feita através de setas específicas e paralelas à principal (associação), essas mensagens podem ir evoluindo de acordo com o projeto. Para se criar novas instancias é preciso deixar claro utilizando o comando create seguido do estereótipo utilizado na UML. No diagrama de colaboração pode ainda ser criadas condição e iteração, ou seja, se houver necessidade, no caso da iteração para identificá-la será antecedida por um *, na seqüência a condição geralmente um looping.

Diagrama de seqüência são apresentadas através de raias com a finalidade de determinar inicio, meio e fim, as trocas de mensagens entre os objetos são apresentadas de forma clara para que no decorrer do projeto facilite na implementação, se utilizam de métodos e instancias que por sua vez indicam a qual objeto está se relacionando. Através do diagrama de seqüência podemos ter idéia de como ficará o código na prática, uma visão geral de como o código do projeto poderá ficar.
O que são comuns entre os diagramas de Seqüência e Colaboração são as classes e instancias que no projeto irão surgir.

Padrões

Padrões é um conjunto de soluções para o problema nominado, segue referencias, modelos, regras etc. São utilizados para aplicar responsabilidades a cada atribuição, de forma que possam ser respeitados os limites que são impostos a cada uma, por exemplo, só começa a realizar o trabalho logo após que a outra atribuição terminou dentro do estudo de padrões há algumas definições:

- O saber - quando algo tenha o conhecimento de determinado tarefa, atribuição.
- O fazer - diz respeito a obrigatoriedade de fazer, executar a tarefa.

- Granularidade alta quando envolve vários objetos em uma operação.

- Granularidade Baixa quando um objeto é acionado e não depende de outros para execução da tarefa.




Aulas 1 e 2 - 07/02/08

Análise:

Não tem como falar de Projeto Orientado a Objeto sem antes passarmos por Análise Orientada a Objeto, onde é feito todo o levantamento dos dados que serão utilizados no decorrer do projeto, é na análise que definimos qual caminho que o projeto deverá percorrer, ou seja, quais detalhes, interações e interfaces que o sistema deverá atender aos requisitos que foram levantados a partir da investigação inicial do projeto, partindo desse preceito, saímos da análise para o projeto propriamente dito, chamamos de Transição da Análise para o Projeto.

Projeto:

Não que a análise foi mal elaborada, mas o projeto tem como objetivo ir mais a fundo em suas atribuições, refinando todo levantamento de requisitos que foi realizado pela Análise, na Análise do Projeto serão abordados objetos de software que se interagem, desenvolver o projeto para satisfazer os requisitos se utilizando de métodos e instancias que o projeto será desenvolvido a partir de uma Linguagem OO “JAVA” , Diagramas de Interação (Seqüência ou Colaboração), colaboração entre objetos onde há uma troca de mensagens entre os objetos de um para o outro, se utilizando de métodos que são adotadas na linguagem OO, sem contar que é indispensável o uso da UML para definição de interfaces, classes, domínios, diagramas de seqüência e atividades, tendo a UML como ferramenta de Apoio ao desenvolvimento, as decisões do projeto serão tomadas com maior precisão tornando o projeto mais visível como um todo.