UNIVERSIDADE FEDERAL DO PARAN - UFPR

Bacharelado em Cincia da Computao

SOFT DISCIPLINA: Engenharia de Software AULA NMERO: 11

DATA: _____/_____/______ PROFESSOR: Andrey

APRESENTAO
O objetivo desta aula apresentar e discutir os conceitos de Refatorao e Padres.

DESENVOLVIMENTO
PADRES Os padres de projeto de software ou padres de desenho de software, tambm muito conhecido pelo termo original em ingls: Design Patterns, descrevem solues para problemas recorrentes no desenvolvimento de sistemas de software orientado a objetos Um padro de projeto estabelece um nome e define o problema, a soluo, quando aplicar esta soluo e suas conseqncias. Os padres de projeto visam facilitar a reutilizao de solues de desenho - isto , solues na fase de projeto do software, sem considerar reutilizao de cdigo. Tambm acarretam um vocabulrio comum de desenho, facilitando comunicao, documentao e aprendizado dos sistemas de software. Um padro de projeto uma estrutura estrutura recorrente no projeto de software orientado a objetos. Pelo fato de ser recorrente, vale a pena que seja documentada e estudada. Um padro de projeto nomeia, abstrai e identifica os aspectos chave de uma estrutura de projeto comum para torn-la til para a criao de um projeto orientado a objetos reutilizvel. Os principais atributos de uma boa descrio de um padro de projeto so:

Nome: referncia que descreve de forma bastante sucinta o padro. Problema (motivao, inteno e objetivos, aplicabilidade): apresenta o contexto do padro e quando ele pode ser usado. Soluo (estrutura, participantes, exemplo de cdigo): descreve a soluo e os elementos que a compem. Conseqncias e padres relacionados: analisa os resultados, vantagens e desvantagens obtidos com a aplicao do padro.

Em geral os padres de projeto podem ser classificados em trs diferentes tipos:

Padres de criao: abstraem o processo de criao de objetos a partir da instanciao de classes. Padres estruturais: tratam da forma como classes e objetos esto organizados para a formao de estruturas maiores. Padres comportamentais: preocupam-se com algoritmos e a atribuio de responsabilidade entre objetos. Especialista Criador Alta Coeso Baixo Acoplamento Controlador
1

Padres GRASP (General Responsibility Assignment Software Pattern)

UNIVERSIDADE FEDERAL DO PARAN - UFPR

Padro Especialista

Bacharelado em Cincia da Computao

Problema: Qual o princpio mais bsico pelo qual as responsabilidades so atribudas em um projeto Orientado a Objetos? Soluo: Atribuir a responsabilidade ao especialista da Informao a classe que tem a informao necessria para resolver a responsabilidade. Padro Criador Problema: De quem a responsabilidade de criar uma nova instncia de uma classe? Soluo: Atribuir uma classe B a responsabilidade de criar uma instncia de uma classe A se:

B agrega objetos de A B contm objetos de A B registra objetos de A B usa muito de perto objetos de A B tem a informao para a inicializao dos objetos de A

Padro Alta Coeso Problema: Como manter a complexidade gerencivel? Soluo: Atribua a responsabilidade de tal forma que a coeso se mantenha alta. Padro Baixo Acoplamento Problema: Como dar suporte baixa dependncia e aumentar o reuso? Soluo: Atribua a responsabilidade de tal forma que o acoplamento se mantenha baixo. Padro Controlador Problema: Quem deve ser responsvel pelo tratamento de um evento do sistema? Soluo: Atribua a responsabilidade de tratar o evento uma classe que:

represente o sistema como um todo represente a organizao ou negcio represente algo no mundo real que seja ativo e que esteja envolvido na tarefa represente um tratador artificial de todos os eventos de um caso de uso.

Padres GoF Padro Singleton Garante que a classe tenha apenas uma instncia e fornece um ponto global de acesso para a mesma. O padro Singleton torna a classe responsvel por manter o controle da sua nica instncia, garantindo que nenhuma outra instncia seja criada, interceptando solicitaes para criao de novos objetos, e por fornecer um meio de acesso a esta nica instncia. Padro Facade Fornece uma interface unificada para um conjunto de interfaces em um subsistema. A figura demonstra a diferena entre um sistema sem fachadas, onde os clientes acessam os subsistemas da aplicao diretamente, e outro em que o padro Facade define uma interface de nvel mais alto que torna o subsistema mais fcil de ser usado.

UNIVERSIDADE FEDERAL DO PARAN - UFPR

Bacharelado em Cincia da Computao

Padro Observer Definir uma dependncia um-para-muitos entre objetos, de maneira que quando um objeto muda de estado todos os seus dependentes so notificados e atualizados automaticamente. O padro Observer descreve como estabelecer esta dependncia. Os objetos chave neste padro so subject e observer. Um subject pode ter um nmero qualquer de observadores dependentes. Todos os observadores so notificados quando o subject muda de estado. REFATORAO O cdigo escrito o documento mais preciso de seu sistema. Quanto mais legvel, mais se pode saber sobre o sistema, mais pessoas podem dar manuteno e mais confivel o sistema. Nesta aula, vamos aprender tcnicas para deixar seu cdigo legvel. Vamos ver como diferenciar cdigo ruim de cdigo bom. E vamos aprender tcnicas de melhorar cdigo (refactoring). O cdigo uma maneira de comunicao e deve deixar claro suas intenes. Isto to importante que voc sempre deve codificar levando isto em conta. Cdigo duplicado ("a doena do copiar e colar") Em informtica, tenha como princpio que uma informao deve ter um nico endereo. Deve estar em um nico lugar e fcil de achar. Duplicao de informao, leva a falta de sincronismo das cpias e a confuso em achar a informao. Cdigo informao. Cdigos duplicados podem aparecer em um mesmo mtodo, em mtodos diferentes e em classes diferentes. O que fazer: separe o cdigo duplicado e crie uma funo (refactoring Extract method). Se o cdigo aparece em mais de uma classe, crie uma classe que represente este cdigo. Mtodos longos Programas vivem melhor, rodam melhor com mtodos curtos. Se um mtodo passou do tamanho de sua tela, ele j longo. Voc nunca deve ficar rolando a tela, fazendo anotaes do lado para entender o mtodo inteiro. Um mtodo no deve fazer mais de uma atividade. Deve ter uma linha de raciocnio homognea. Para consertar um mtodo longo, separe trechos que fazem uma nica atividade e construa um mtodo com ele (refactoring Extract method). Classes muito longas Classes devem se limitar a menor contexto possvel. Este contexto pode ser uma entidade, um algoritmo. Uma classe no deve implementar mais de uma entidade ou algoritmo. possvel que classes representem mais de uma entidade (pattern FACADE), mas no implementem mais do que uma. Para transformar uma classe grande em vrias menores, isole as variveis membros e mtodos que so afins e criei uma nova classe. Se voc consegue dar um nome adequado para esta nova classe, voc deve estar indo para o caminho certo.
3

UNIVERSIDADE FEDERAL DO PARAN - UFPR

Bacharelado em Cincia da Computao

Mtodos com muitos parmetros Se voc passa 5, 6 ou mais parmetros para um mtodo, isto confunde. Um grande nmero de parmetros indica algo que no foi modelado, uma entidade esquecida e oculta. Passe um menor nmero de parmetros possvel para um mtodo. Investigue se o mtodo pode deduzir os parmetros por si s. Um sada bastante comum criar uma classe que represente os parmetros. Exemplo:
CadastrarPessoa( "Jose", "tito", 1, "555-1111" ); // melhor seria: EnderecoPessoa endereco= new EnderecoPessoa(); endereco.rua= "tito"; endereco.numero= 1; endereco.telefone = "555-1111"; CadastrarPessoa( "Jose", endereco );

Mtodos em classes erradas Fique atento se um mtodo est mais interessado em propriedades e mtodos de outra classe do que da sua prpria. Em muitos casos, melhor mudar o mtodo de classe. Dados que gostam de andar juntos Voc j viu aquelas variveis que sempre andam juntas, quer em classes ou em parmetros? Elas esto pedindo para virar uma classe. Atenda-as! Um bom teste : imagine que voc tire uma delas, as outras perdem o sentido? Se sim, elas esto pedindo para ser um objeto. Exemplo:
class Aluno { String String String String } _Nome; _Logradouro; _Numero; _Bairro;

//fica melhor: class Endereco { String _Logradouro; String _Numero; String _Bairro; }; class Aluno { String _Nome; Endereco _Endereco; };

Classe de dados (data class) No deve ter atributos pblicos, torne-os privados e crie get_ e set_ mtodos. Se um atributo nunca deve ser alterado, s consultado, coloque s o mtodo get_. Expresses complexas No deixe expresses complexas soltas no cdigo. Crie funes cujo nome digam o que a expresso faz. Veja o seguinte cdigo:
if( ano % 4 == 0 && (ano % 100 != 0 || ano % 400 == 0) )
4

UNIVERSIDADE FEDERAL DO PARAN - UFPR

Bacharelado em Cincia da Computao {

no ficaria melhor assim?

if( ehBisexto(ano) ) { } /** * Method ehBisexto. * @param ano * @return boolean */ private boolean ehBisexto(int ano) { return ano % 4 == 0 && (ano % 100 != 0 || ano % 400 == 0); }

Dar nomes a variveis, classes e mtodos Sempre d nomes que dispensem comentrios. Voc cria uma varivel e d a ela o nome de 'k' e depois comenta dizendo que ela um contador. Por qu no a chama de 'contador'? No relute em mudar nomes, quando eles no esto claros o suficiente. H editores (exemplo: eclipse) que j lhe do ferramentas para mudar nomes e ele sai mudando tudo que referencia. No tente reutilizar uma varivel local para mais de uma finalidade. Esta prtica faz a varivel ter um nome que no diz nada. Comentrios No algo ruim, mas muitas vezes so colocados para melhorar um cdigo ruim. Um comentrio no deve dizer o que o cdigo faz, o cdigo deve dizer. Voc pode usar um comentrio para dizer por qu voc tomou uma deciso em vez de outra. Exemplo:
int CalcularArea() { // l --> largura // c --> comprimento int l= calc1(x2,x1); // calc1 calcula a diferenca entre x2 e x1 int c= calc1(y2,y1); return c * l; }

ficaria melhor:
int CalcularArea() { int largura= CalcularDiferenca(x2,x1); int comprimento= CalcularDiferenca(y2,y1); return comprimento * largura; }

ATIVIDADE
1. Para cada um dos problemas relatados, escreva um exemplo onde ocorre o problema e mostre uma soluo 2. O que um Padro? 3. Qual a vantagem de usar padres de projeto? 4. Cite alguns padres de projeto? 5. O que o padro facade?

BIBLIOGRAFIA BSICA
PRESSMAN, R. S.. Engenharia de Software. Makron Books. 1995 FOWLER, Martin - REFACTORING, Improving the design of existing code.
5

UNIVERSIDADE FEDERAL DO PARAN - UFPR

FOWLER, Martin e BECK, Kent - Bad Smells in Code - http://home.sprintmail.com/~wconrad/refactoringlive/smells.html GAMMA, Erich et. al., Padres de projeto: solues reutilizveis de software orientado a objetos. Porto Alegre: Bookman, 2000. Booch, G.; Rumbaugh, J.; Jacobson, I.. UML guia do usurio. Editora Campus. 2000. BEZERRA, E.. Princpios de Anlise e Projeto de Sistemas com UML. Ed. Campus. 2003.

Bacharelado em Cincia da Computao