SISMO - Sistemas e Mobilidade Departamento de Informática / UFMA. Junho de 2008

Introdu¸c˜ao

SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br

Departamento de Inform´atica / UFMA

Junho de 2008

Padr˜oes de Software

Comp˜oem uma disciplina da Engenharia de Software voltada para a resolu¸c˜ao de problemas baseada na documenta¸c˜ao de “melhores pr´aticas” e de li¸c˜oes adquiridas com a experiˆencia

Objetivos do uso Padr˜oes de Software

Criar uma base documental para ajudar na solu¸c˜ao de problemas recorrentes em atividades de desenvolvimento Disseminar o uso de uma linguagem comum para compartilhar id´eias e experiˆencias sobre esses problemas e suas solu¸c˜oes

Qual a melhor maneira de fazer um pedido na lanchonete?

Uma fatia de carne bovina mo´ıda grelhada na chapa coberta com folhas de alface, uma fatia de derivado de leite s´olido, salgado e quente, tudo isso envolvido em duas fatias de p˜ao redondo coberto com sementes de gergelim (ufa!), por favor!

Figura: nhammm!!!!

Um pouco de hist´oria...

Livros do arquiteto Christopher Alexander relacionados a planejamento urbano e arquitetura de edif´ıcios (1964, 1975, 1977, 1979)

Ward Cunningham and Kent Beck – artigo apresentado no OOPSLA’87, Orlando, Florida, USA - ”Using Pattern Languages for ObjectOriented Programs”(OOPSLA -Object-Oriented Programming, Systems, Languages, and Applications)

Um pouco de hist´oria...

Jim Coplien – publica em 1991 um cat´alogo de idioms de C++ (um tipo de padr˜ao espec´ıfico de uma

linguagem),“Advanced C++ Programming Styles and Idioms” Workshops da OOPSLA relevantes para o amadurecimento dos padr˜oes de software: 1990 - 1993

1995 - Livro “Design Patterns: Elements of Reusable Object-Oriented Software”. Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides (referidos como the Gang of Four ou GoF) 2000 - “Pattern-Oriented Software

Architecture: A System of Pattern” (the POSA book). Frank Buschmann, Regine Meunier, Hans Rohnert, Peter

Sommerlad, e Michael Stal

Tipos de Padr˜oes

Padr˜oes de an´alise (Martin Fowler) Padr˜oes organizacionais

Padr˜oes arquiteturais Padr˜oes de projeto Idioms

Padr˜oes Arquiteturais

expressam uma organiza¸c˜ao estrutural fundamental ou esquema de sistemas de software

provˆeem um conjunto de subsistemas predefinidos, suas responsabilidades e regras para organiza¸c˜ao do relacionamento entre eles

Exemplo: MVC (Model, View, Controller)

Padr˜oes de Projeto

provˆeem um esquema para refinar subsistemas ou

componentes de um sistema de software, ou o relacionamento entre eles

descrevem estruturas recorrentes de componentes conectados que resolvem um problema geral de projeto dentro de um contexto particular

Idioms

um idiom ´e um padr˜ao de baixo n´ıvel espec´ıfico de uma linguagem de programa¸c˜ao

idioms descrevem como implementar aspectos espec´ıficos de componentes ou de seus relacionamentos usando

caracter´ısticas de uma determinada linguagem exemplos

interfaces, classes parametrizadas e reflex˜ao em java templates em C++

Padr˜oes n˜ao s˜ao algoritmos

algoritmos e estruturas de dados resolvem geralmente problemas computacionais de granularidade mais fina (e.g., ordena¸c˜ao e busca)

Padr˜oes s˜ao relacionados tipicamente com problemas arquiteturais mais abrangentes com efeitos em mais larga escala. Por exemplo, os padr˜oes de projeto no livro da GoF tratam problemas como manutenibilidade, reusabilidade e varia¸c˜oes de encapsulamento

Padr˜oes n˜ao s˜ao Frameworks

um arcabou¸co de software ´e um conjunto de classes

cooperantes que constituem um projeto reutiliz´avel para um tipo espec´ıfico de software

exemplo: Swing do java

Padr˜oes n˜ao s˜ao Frameworks II

um arcabou¸co pode ser vIsto como a implementa¸c˜ao de um sistema de padr˜oes de projeto

contudo, um arcabou¸co ´e software execut´avel, enquanto padr˜oes de projeto representam conhecimento e experiˆencia sobre software

Tipos de Padr˜oes de Projeto

Padr˜oes de Cria¸c˜ao - Se preocupam com o proceso de cria¸c˜ao de projetos

Padr˜oes Estruturais - Lidam com a composi¸c˜ao de classes ou de objetos

Padr˜oes Comportamentais - Caracterizam a maneira pelas quais classes ou objetos interagem e distribuem

responsabilidades

Uma pausa para respirar...

Figura: antes dos problemas...

Um Problema

A empresa do Z´e est´a desenvolvendo um jogo de combate e ele recebeu a tarefa de criar uma hierarquia de classes para os

combatentes. Suponha que ele criou a seguinte hierarquia inical de classes:

Figura: Diagrama de Classes de Combatentes

Tudo ia muito bem, mas...

A concorrˆencia n˜ao d´a moleza; e os executivos da empresa, depois de um estafante fim de semana num hotel de luxo, resolveram que o z´e tinha que adicionar novas funcionalidades ao jogo. Ai ele teve uma id´eia genial: Reutliza¸c˜ao de C´odigo via Heran¸ca - inserir os novos “poderes” na classe Combatente, que seriam herdados por todos os outros soldados

Figura: Classe Combatente revisada

Novos Problemas

“ˆo sua anta, quem j´a viu soldado mergulhar no deserto?”.

Figura: Cuidado! Chefe doido

Z´e n˜ao percebeu que nem todo soldado precisa (ou pode) mergulhar! Ele poderia sobrescrever os m´etodos mergulhar e nadar, mas e se pedirem para adicionar um combatente astronauta? Provavelmente ele ter´a que sobrescrever esses

m´etodos tamb´em...e continuar sobrescrevendo, a cada nova classe derivada de combatente. Eternamente...

O que aconteceu???

A grande id´eia do Z´e era usar heran¸ca com o prop´osito de reutilizar o c´odigo. Mas acabou criando problemas de manuten¸c˜ao. Quais as principais desvantagens no uso da heran¸ca no caso dos

combatentes?

duplica¸c˜ao de c´odigo nas subclasses

´e dif´ıcil mudar comportamento dos objetos em tempo de execu¸c˜ao

as mudan¸cas podem afetar outros combatentes de modo n˜ao intencional

Outra grande id´eia

Por´em o Z´e foi informado que novas mudan¸cas viriam a cada trimestre. A heran¸ca iria causar um pesadelo de manuten¸c˜ao. Dai, o Z´e teve outra grande id´eia...

E se eu criasse uma interface aqu´atica? Assim eu n˜ao teria combatentes nadando no deserto eheh. Eu sou muito esperto!!!

Figura: Usando interfaces

Ai ´e que est´a o “bus´ılis” (O X do problema)

De fato, n˜ao temos mais combatentes nadando no deserto... Mas em contrapartida, a reutiliza¸c˜ao do c´odigo para os m´etodos nadar e mergulhar foi pelo ralo!!!

O Z´e trocou um problema de manuten¸c˜ao por outro.

Figura: Chefe Mais Irado

O problema ´e que mudan¸cas s˜ao uma constante em softwaree precisamos desenvolver aplica¸c˜oes pensando nesse problema.

Princ´ıpio OO: Encapsulamento

“Identifique os aspectos variantes na sua aplica¸c˜ao e os encapsule. Posteriormente, vocˆe pode estender ou alterar as partes que variam sem afetar as que n˜ao o fazem”

Essa abordagem resultar´a em:

menos “surpresas” inesperadas em raz˜ao de altera¸c˜oes no c´odigo e

sistemas mais flex´ıveis e f´aceis de manter

Aplicando o princ´ıpio do Encapsulamento ao problema

Poss´ıveis novas classes de combatentes precisar˜ao nadar, mergulhar e at´e mesmo flutuar . (combatentes astronautas, por exemplo), enquanto outras n˜ao

Esse tipo de comportamento (mais vari´avel) deve ser separado da hierarquia da classe Combatente para promover

independˆencia e flexibilidade.

Esse princ´ıpio est´a na base da maioria dos padr˜oes de projeto orientados a objetos

Todo padr˜ao provˆe um meio de deixar uma das partes de um sistema variar independentemente das outras partes

Separando o que muda do que permanece

Pelo que vimos at´e agora, os m´etodos mais sens´ıveis a mudan¸cas s˜ao exatamente nadar, mergulhar e (o novo m´etodo) flutuar

A hierarquia de classes Combatente deve continuar a mesma, isto ´e, com as mesmas subclasses, mas vamos tirar dela os m´etodos que representam comportamentos mais afetados por mudan¸cas

Vamos criar novas hierarquias de classes para representar esses comportamentos

Criando hierarquia separada de comportamentos

Figura: Hierarquias de comportamentos

Implementa¸c˜ao das Interfaces de Comportamento I

Figura: Comportamento Aqu´atico

Implementa¸c˜ao das Interfaces de Comportamento II

Figura: Comportamento A´ereo

Princ´ıpio OO: Programar para Interface

“Programe para uma Interface, n˜ao para uma implementa¸c˜ao”

Podemos implementar novos comportamentos aqu´atico e a´ereo, criando novas classes que implementem essas interfaces A classe Combatentes n˜ao precisa conhecer detalhes de implementa¸c˜ao desses comportamentos

Outros objetos, al´em dos Combatentes, podem usar os comportamentos aqu´atico e a´ereo, porque eles n˜ao est˜ao “escondidos” na classe combatente

Refatorando a Classe Combatente

Refatorando subclasses

O Comportamento da classe Caveira ´e definido pelas classes que implementam as interfaces AcaoAerea e AcaoAquatica

Figura: Especializando um tipo de Combatente (Caveira)

Integrando as Hierarquias

Figura: Vis˜ao do Conjunto

Adicionando Comportamento Dinamicamente

Figura: Aplica¸c˜ao Exemplo

Princ´ıpio OO: Composi¸c˜ao

“Prefira Composi¸c˜ao em vez de Heran¸ca”

a Composi¸c˜ao permitiu encapsular comportamento (algoritmos) em seu pr´oprio conjunto de clases e permitiu mudar o comportamento dos objetos dinamicamente (em tempo de execu¸c˜ao)

Padr˜ao Strategy

Parab´ens! Vocˆe acabou de ser apresentado na pr´atica ao padr˜ao Strategy

Segundo o Livro da GoF, a inten¸c˜ao do Padr˜ao Strategy ´e:

“Definir uma fam´ılia de algoritmos, encapsular cada um deles e torn´a0los intercambi´avies. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam”

Padr˜ao Strategy: Classifica¸c˜ao e Motiva¸c˜ao

Prop´osito: Comportamental Escopo: Objetos

Motiva¸c˜ao:

clientes que necessitam de diferentes algoritmos se tornam mais complexos se os incluirem em seu c´odigo

diferentes algoritmos s˜ao adequados em diferentes situa¸c˜oes na resolu¸c˜ao de um mesmo problema

Padr˜ao Strategy: Classifica¸c˜ao e Motiva¸c˜ao

Figura: Exemplo de Motiva¸c˜ao

Padr˜ao Strategy: Aplicabilidade

Use Strategy quando:

muitas classes relacionadas diferem somente no seu comportamento

vocˆe necessita de variantes de um algoritmo

um algoritmo usa dados sobre os quais o cliente n˜ao precisa ter conhecimento

comandos condicionais relacionados para escolher entre muitos comportamentos de uma classe podem ser movidos para sua pr´opria classe Strategy

Padr˜ao Strategy: Estrutura

Figura: Estrutra do Padr˜ao

Padr˜ao Strategy: Colabora¸c˜oes

Strategy e Context interagem para implementar o algoritmo escolhido

os clientes usualmente criam e passam um objeto ConcreteStrategy para o contexto e passam a interagir diretamente com o contexto

Padr˜ao Strategy: Consequˆencias

fam´ılias de algoritmos relacionados uma alternativa ao uso de subclasses possibilidade de escolha de implementa¸c˜oes os clientes devem conhecer diferentes estrat´egias custo de comunica¸c˜ao entre Strategy e Context aumento do n´umero de objetos