Aulas 14 e 15

Padrão Controlador

Problema: quem controla os eventos acionados pelos atores externos a aplicação.
Solução: adicione responsabilidade a classe controladora quando:
A classe representa o próprio sistema ou um dispositivo.
A classe que representa um caso de uso.
Mecanismos:
A decisão de se optar por um controlador baseado em caso de uso ou de um dispositivo/sistema está associado aos padrões de baixo acoplamento e alta coesão.
Atenção quanto a controladores sobrecarregados.

Alta Coesão
Problema: como manter o objeto focado, gerenciado e entendível ao mesmo tempo que se mantém com baixo acoplamento.
Solução: atribua responsabilidade de forma a manter a coesão alta.
Mecanismos:
Concentre análise nas classe com muitos métodos desconectados uns dos outros.
Analise métodos que realizam “coisas” demais.
Coesão Alta e Baixo Acoplamento: Estes dois conceitos são complementares.

Coesão coincidental
· Há nenhuma (ou pouca) relação construtiva entre os elementos de um módulo
· No linguajar OO:
· Um objeto não representa nenhum conceito OO
· Uma coleção de código comumente usado e herdado através de herança (provavelmente múltipla)

Coesão lógica
· Módulo faz um conjunto de funções relacionadas, uma das quais é escolhida através de um parâmetro ao chamar o módulo
· Semelhante a acoplamento de controle
· Cura: quebrar em métodos diferentes

Coesão temporal
· Elementos estão agrupados no mesmo módulo porque são processados no mesmo intervalo de tempo
· Exemplos comuns:
· Método de inicialização que provê valores defaults para um monte de coisas diferentes
· Método de finalização que limpa as coisas antes de terminar
· Cura: depender de construtores e destrutores, outro exemplo: arquivo de configuração típico.

Coesão procedural
· Associa elementos de acordo com seus relacionamentos procedurais ou algorítmicos
· Um módulo procedural depende muito da aplicação sendo tratada
· Junto com a aplicação, o módulo parece razoável
· Sem este contexto, o módulo parece estranho e muito difícil de entender
· "O que está acontecendo aqui!!!????!!"
· Não pode entender o módulo sem entender o programa e as condições que existem quando o módulo é chamado Cura: reprojete o sistema.

Coesão de comunicação
· Todas as operações de um módulo operam no mesmo conjunto de dados e/ou produzem o mesmo tipo de dado de saída
· Cura: isole cada elemento num módulo separado
· "Não deveria" ocorrer em sistemas OO usando polimorfismo (classes diferentes para fazer tratamentos diferentes nos dados)

Coesão sequencial
· A saída de um elemento de um módulo serve de entrada para o próximo elemento
· Cura: decompor em módulos menores

Coesão funcional (a melhor)
· Um módulo tem coesão funcional se as operações do módulo puderem ser descritas numa única frase de forma coerente
· Num sistema OO:
· Cada operação na interface pública do objeto deve ser funcionalmente coesa
· Cada objeto deve representar um único conceito coeso
· Exemplo: um objeto que esconde algum conceito ou estrutura de dados ou recurso e onde todos os métodos são relacionados por um conceito ou estrutura de dados ou recurso
· Meyer chama isso de "information-strength module"

Consequências:
Melhor claridade e facilidade de compreensão do projeto
Simplificação da manutenção
Frequentemente vai mão na mão com acoplamento fraco
Com granularidade baixa e funcionalidade bem focada, aumenta o reuso.

Aula 12 e 13

Acoplamento de dados globais.
Dois ou mais objetos compartilham estruturas de dados globais
É um acoplamento muito ruim pois está escondido
Uma chamada de método pode mudar um valor global e o código não deixa isso aparente
Um tipo de acoplamento muito ruim

Acoplamento de dados internos.
Um objeto altera os dados locais de um outro objeto
Ocorrência comum:
Dados públicos, package visibility ou mesmo protected em java Use com cuidado!

Conseqüências.
Uma classe fracamente acoplada não é afetada (ou pouco afetada) por mudanças em outras classes
Simples de entender isoladamente
Reuso mais fácil

Bibliografia:
Internet, fóruns e Artigos.
Larman, Graig. Utilizando UML e Padrões, 2ª edição 2004

Aula 12 e 13

Acoplamento de controle.

Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto.
Ocorrência comum:
· Objeto a manda uma mensagem para objeto b
· b usa um parâmetro da mensagem para decidir o que fazer

Ex.
Código.

class Lampada {
public static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);lampada.setLampada(2);

Solução: decompor a operação em múltiplas operações primitivas

Ex.
Código:

class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}

Lampada lampada = new Lampada();
lampada.on();lampada.pisca();

Ocorrência comum:
· Objeto a manda mensagem para objeto b
· b retorna informação de controle para a
· Exemplo: retorno de código de erro

Ex.
Código:

class Teste {
public int printFile(File aImprimir) {
if(aImprimir está corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.


Solução: use exceções

Ex.
Código:

class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir está corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}

try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: não tem miniteste amanhã!
}

Aula 10 e 11

Baixo acoplamento.

· Problema: como reduzir o impacto das mudanças?
· Solução: atribuir responsabilidade de forma o acoplamento permaneça baixo, ou seja, com menor conexão entre os objetos.
· Mecanismos de identificação:
– Procure por classes com muitas associações com outras classes.
– Procure por métodos que estão baseados em outros e métodos em demasia.
– Evitar o quanto possível novas visibilidades entre as classes do modelo conceitual.



Exemplo.

Aula 8 e 9

Padrão Criador.

· Problema: quem cria um determinado objeto A?
· Solução: atribua a uma classe B esta responsabilidade se:
– B possuir uma agregação ou composição com A.
– B possui uma relação de 1 - *
– B possui dados de inicialização de A..
– B usa A.
· Mecanismos de identificação.
– Verificação do modelo domínio ou de desenho.
– Verificação das classes de agregação e composição.


Exemplo.

Venda cria a classe iten de venda.

OU

Bibliografia:

Larman, Graig. Utilizando UML e Padrões, 2ª edição 2004

Aula 7

Relembrando.

Especialista na informação.

Atribuir uma responsabilidade ao especialista na informação: a classe que tem a INFORMAÇÃO necessária pra satisfazer as responsabilidades.

• Problema: qual o princípio básico de distribuição de responsabilidade pelas classes.


• Solução: atribua à responsabilidade a classe que possua a informação necessária a sua utilização.


• Mecanismos de identificação:

Defina a responsabilidade claramente.

Procure por classes que possuam as informações necessárias a implantação deste responsabilidade.

Responsabilidade de Cálculo do Total da Venda: classe Venda ela é a especialista nesta informação.

Aula 6

Realizada no laboratório, dando mais ênfase na aula 5.


Material pesquisado:
Proposto pelo professor e disponibilizado no portal do aluno.

Padrões GRASP

Aula 5


Descrevem princípios fundamentais de atribuição de responsabilidade a objetos.
Alguns padrões GRASP principais:
· Especialista
· Criador
· Coesão alta
· Acoplamento fraco
· Controlador

Especialista.

Problema: qual é o princípio mais básico para atribuir responsabilidades no projeto orientado a objetos?
Solução: Atribuir responsabilidade ao especialista da informação.

Criador.

Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe?
Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira:

B agrega objetos de A
B contém objetos de A
B registra instâncias de objetos de A
B usa objetos de A B tem os valores iniciais que serão passados para objetos de A, quando de sua criação.

Coesão alta.

Objeto com Coesão Alta -> objetos cujas responsabilidades são altamente relacionadas e que não executa um volume muito grande de trabalho.
Acoplamento fraco O acoplamento mede o quanto um objeto está conectado a, tem conhecimento de ou depende de outros objetos
Acoplamento fraco (ou baixo) – um objeto não depende de muitos outros. (desejavél)
Acoplamento forte (ou alto) – um objeto depende de muitos outros.

Controlador.

É um objeto de interface (não interfacede usuário) responsável por tratar um evento externo (evento de sistema). Define o método para a operação de sistema.
Referências:
http://www.google.com.br/
http://www.wikipedia.org/
Material apresentado em sala.
Abraços Diogo

Padrões

Aula 5

O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:
· encapsulamento; um padrão encapsula um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
· generalidade; todo padrão deve permitir a construção de outras realizações a partir deste padrão.
· equilíbrio; quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
· abstração; os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
· abertura; um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
· combinatoriedade; os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:

nome; uma descrição da solução, mais do que do problema ou do contexto.
exemplo; uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.
contexto; a descrição das situações sob as quais o padrão se aplica.
problema; uma descrição das forças e restrições envolvidos e como elas interagem.
solução; relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéias.
O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).

Referências:
http://pt.wikipedia.org/
http://www.google.com.br/
material associado na aula.


Abraços.
Diogo Viana Rabelo

Orientação a objetos

A orientação a objetos, também conhecida como Programação Orientada a Objetos (POO) ou ainda em inglês Object-Oriented Programming (OOP) é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos
Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de projeto.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos.

Alguns tipos de linguagem orientada a objeto são:
· Smalltalk
· Python
· Ruby
· C++
· Object Pascal
· Java
· C#