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.