C Advnotes

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO
Programao orientada a objetos: Desenvolvimento avanado em C++

Slide 1 Ivan Luiz Marques Ricarte
DCA/FEEC/UNICAMP
Objetivos
ilmr
Slide 2
Apresentar principais tendncias no desenvolvimento de software; Compreender conceitos da orientao a objetos de modo a obter software que pode ser (de fato) reutilizado; e Como aplicar esses conceitos para o desenvolvimento de software reutilizvel em C++.
Pblico-alvo
Programadores com conhecimento de C++ e com experincia de participao em projetos de sistemas de software. Slide 3
Slide 4
ilmr
Como voc se descreveria em termos de sua atividade prossional? Por que desenvolver software parte de sua atividade?
Viso geral
Desenvolvimento de software
Estratgias bsicas Tendncias atuais Problemas no desenvolvimento de projetos
Solues para o desenvolvimento de projetos

padres de projetos tcnicas para programao genrica uso efetivo de C++ e STL
Desenvolvimento
Slide 5
de software
Por que se investe tanto no desenvolvimento de software?
Slide 6
ilmr
Dependncia da sociedade em relao aos produtos de software

Atividades cotidianas Sistemas crticos
Busca pela melhor qualidade do software

Conabilidade
Uso de software no processo de desenvolvimento de software
Evoluo do desenvolvimento de software

195060s 196070s Slide 7 197080s Software orientado pelo hardware Software como produto bibliotecas de software Software em sistemas complexos popularizao de microprocessadores sistemas distribudos 1990s?? Software responsvel pela maior parte do custo em sistemas computacionais
Disciplina no desenvolvimento de software
Slide 8
ilmr
O foco na qualidade em desenvolvimento de software depende da aplicao consistente e disciplinada de processos: estabelecimento de uma base slida para o desenvolvimento de software mtodos: estratgias e tcnicas para a construo de software ferramentas: suporte automatizado para processos e mtodos
A promessa da Engenharia de Software
Qualidade de software
Slide 9
Ferramentas
Mtodos
Processo
Modelos para processos
Slide 10
ilmr
Combinaes e variaes em torno de Anlise: capturar informao sobre o domnio do problema e construir modelos operacionais para o sistema Projeto: transformar modelos da anlise em modelos de elementos computacionais Codicao: implementar os elementos computacionais do sistema Teste: encontrar erros na implementao Manuteno: tudo de novo a cada mudana Resultado: cdigo (o produto nal)
11
Por que desenvolver software difcil?
Slide 11
Slide 12
ilmr
Frederick Brooks: No Silver Bullet para construir software

Conjunto de construes conceituais Complexo e no-linear Sujeito a mudanas e modicaes Invisvel e no-visualizvel
Phillip Armour: software no um produto, mas uma forma de armazenar conhecimento

desenvolver software no produzir um produto, mas adquirir conhecimento
Como desenvolver bom software?
Balano entre nfase no produto vs. nfase no processo

construes e linguagens de programao estratgias e metodologias
Porm o produto no o cdigo, mas sim o conhecimento nele embutido P. Armour

Encerrado o desenvolvimento, todo o software deveria ser reescrito
13
As cinco ordens de ignorncia
Slide 13
Slide 14
ilmr
OI-0: falta de ignorncia

conhece alguma coisa e pode demonstrar esse conhecimento
OI-1: falta de conhecimento

no sabe alguma coisa e sabe identicar este fato
OI-2: falta de conscincia

no sabe alguma coisa e nem sabe que no sabe
OI-3: falta de processo

OI-2 e no sabe como fazer para descobrir que h coisas que no sabe
OI-4: meta-ignorncia
no sabe sobre as cinco ordens de ignorncia
Ordens de ignorncia e desenvolvimento de software
OI-0: sistema funcionando corretamento

tem a resposta
OI-1: variveis so conhecidas

tem a questo
OI-2: onde muitos projetos comeam. . .

nem a resposta, nem a questo
OI-3: onde mora o perigo. . .

metodologias de desenvolvimento devem mostrar onde falta conhecimento
15
O papel da orientao a objetos
Slide 16
ilmr
Slide 15
Por si, no a resposta denitiva s nossas preces

Porm, no momento a melhor maneira de expressar nosso conhecimento sobre software
Diversas metodologias Diversas linguagens

UML Java ... C++
O desenvolvimento orientado a objetos
Desenvolvimento no comea na codicao Vises da arquitetura do sistema

Sistema: coleo de subsistemas Subsistema: agrupamento de elementos
Modelos
Abstrao de um sistema semanticamente fechada
Diagramas sobre aspectos estticos e dinmicos

Apresentao grca de um conjunto de elementos
17
A programao orientada a objetos
Slide 17
Slide 18
ilmr
Transio dos modelos de projeto para o cdigo facilitada pelo vocabulrio comum Linguagens orientadas a objetos permitem expressar diretamente os conceitos usados no desenvolvimento orientado a objetos
classes, atributos e mtodos objetos associaes e composies herana: reaproveitamento de denies
A velha promessa no cumprida. . .
Com a orientao a objetos, voc poder reaproveitar cdigo j desenvolvido e assim acelerar a produo de software. Porm, muitas vezes usamos software genrico em nossos desenvolvimentos
na forma como est ou adaptado s nossas necessidades.
19
Slide 19
Como desenvolver software que pode ser reaproveitado, sem cair nas velhas armadilhas do desenvolvimento de software?
Reaproveitando experincias no desenvolvimento de software
ilmr
Slide 20
Boas experincias Padres: solues reconhecidas Ms experincias Antipadres: enganos usuais
21
Por que estudar antipadres?
Slide 21
Pressa: quando o deadline se aproxima, qualquer coisa que parece funcionar aceitvel Apatia: no resolver problemas conhecidos Slide 22 Mente estreita: no praticar solues reconhecidas como efetivas Preguia: tomar decises pobres usando a resposta fcil Avareza: apegar-se a detalhes excessivos na modelagem Ignorncia: no buscar compreender (e.g., migrao de cdigo) Orgulho: sndrome do no-foi-feito-por-ns
ilmr
Cinco em cada seis projetos no so considerados de sucesso

Um tero de projetos cancelados Recursos de custo e tempo inadequados Resultados pouco exveis ou extensveis
Antipadres: soluo para um problema que gera decididamente conseqncias negativas

Antipadres de desenvolvimento: problemas tcnicos encontrados pelos programadores Antipadres de arquitetura: problemas na estrutura do sistema Antipadres de gerncia: problemas na organizao de processos e desenvolvimento
Antipadres: causas primrias (7 pecados capitais)
23
Como usar antipadres
Slide 23
ilmr
Slide 24
No para caar bruxas A empresa no necessariamente precisa estar livre de antipadres

enderear problemas crnicos
Propsito desenvolver e implementar estratgias para resolver os problemas decorrentes das ms prticas Se h problemas, preciso motivar pessoas a assumirem responsabilidades
1. Qual o problema? 2. O que outras pessoas esto fazendo para contribuir para a soluo deste problema? 3. O que voc est fazendo para contribuir para a soluo deste problema?
Antipadres no desenvolvimento de software
No basta apontar onde est o problema, mas preciso indicar caminhos para a soluo No desenvolvimento de software, tcnicas bsicas de refabricao de programas incluem:
Abstrao para superclasse Eliminao condicional Abstrao agregada
25
Abstrao para superclasse
Slide 25
Slide 26
ilmr
Aplicvel a duas ou mais classes similares 1. Transformar assinaturas de mtodos similares em assinaturas comuns 2. Criar superclasse abstrata 3. Modicar cdigo para combinar implementaes selecionadas 4. Migrar mtodos comuns para superclasse
Eliminao condicional
Estrutura e comportamento de uma classe muito dependente de um comando condicional 1. Criar novas subclasses correspondentes a cada condio 2. Migrar o cdigo de ao associado a cada condio para a nova subclasse 3. Redirecionar as referncias s classes para indicar a subclasse adequada
Pode afetar construtores, declaraes de tipo e invocaes a mtodos sobrecarregados
27
Abstrao agregada
Slide 27
Forma geral: Uma classe monopoliza o processamento, outras classes encapsulam dados Slide 28
Sintomas e conseqncias: classes com grande nmero de atributos ou mtodos, perdendo as vantagens da orientao a objetos e tornando difcil teste e reuso Soluo: identicar atributos e operaes relacionadas de acordo com contratos coesos, migrando essas colees de funcionalidades para seus lares naturais; revisar associaes
ilmr
Reorganiza relacionamentos de classes para melhorar estrutura e extensibilidade Possveis formas Transformar relacionamentos de herana em relacionamentos de agregao Migrar classes agregadas para relacionamentos de componentes Migrar relacionamentos de componentes para relacionamentos de agregao
Antipadro: A Bolha
Esta classe o corao de nossa arquitetura!
Tipicamente, herana de projeto procedimental (processos vs. dados)
29
Antipadro: Fluxo de Lava

Acho que no usado, mas no tenho certeza. . . deixe por a.
Forma geral: fragmentos de cdigo, variveis de classes aparentemente no relacionados com o sistema Slide 29 Sintomas e conseqncias: segmentos complexos sem documentao, blocos de cdigo comentados sem explicao; se no removido, continua a proliferar pelo sistema e outros desenvolvedores (apressados, intimidados) vo trabalhando ao redor dos uxos de lava, gerando um sistema impossvel de se entender ou documentar Soluo: no desenvolvimento, ter uma arquitetura slida (interfaces estveis, bem denidas e documentadas) antes de gerar cdigo; na manuteno, trabalho de detetive (descoberta de sistema)
Antipadro: Decomposio funcional

A rotina principal est aqui, na classe Listener.
Forma geral: Desenvolvimento baseado na decomposio funcional, fazendo classes a partir de subrotinas Slide 30 Sintomas e conseqncias: classes com nomes de funes, contendo um nico mtodo, e nenhum uso de princpios bsicos da orientao a objetos; nenhuma esperana de reusar software Soluo: denir modelos de anlise e de projeto para tentar compreender e explicar o sistema; para classes fora do modelo de projeto, tentar combinar com classes existentes ou transform-las em funes de uso geral
ilmr
31
Antipadro: Poltergeists
Eu no sei bem o que essa classe faz, mas certamente importante.
Forma geral: Classes com ciclo de vida breve, que aparecem brevemente e depois desaparecem Slide 31 Sintomas e conseqncias: Objetos e classes temporrios, com associaes transientes, levando a modelos de objetos desnecessariamente complexos Solues: aes associadas a poltergeists devem ser movidas para as classes que elas referenciavam, removendo as classes fantasmas do modelo
Antipadro: Martelo Dourado

Quando a nica ferramenta disponvel um martelo, todo o resto vira prego.
Forma geral: Todas as solues de uma equipe usam um produto no qual a equipe tornou-se prociente Slide 32 Sintomas e conseqncias: Mesmas ferramentas e produtos usadas em produtos conceitualmente diversos, com a arquitetura do sistema sendo melhor descrita pelo produto, ambiente ou ferramenta; resultado em geral podem ter baixo desempenho e escalabilidade, sendo dependentes do vendedor ou da tecnologia Soluo: Suportar losoa de buscar novas tecnologias; projetar e desenvolver sistemas com limites claros para a substituio de componentes individuais.
ilmr
33
Antipadro: Cdigo espaguete

Voc sabia que essa linguagem suporta mais de uma funo?
Forma geral: Programas ou sistemas com pouca estrutura de software Slide 33 Sintomas e conseqncias: Mtodos muito orientados a processos, com o uxo de execuo ditado pela implementao de objetos; muitos mtodos sem parmetros, usando variveis de classe (globais), sendo de difcil reuso Soluo: preveno (uso apropriado de orientao a objetos); manuteno para limpeza de cdigo (estratgias de refabricao de programas), principalmente quando for acrescentar alguma nova funcionalidade ao cdigo espaguete
Antipadro: Programao Cut-and-Paste

Isto que ecincia: 100000 linhas de cdigo em duas semanas!
Slide 34
Forma geral: Presena de vrios segmentos similares de cdigo espalhados pelo sistema Sintomas e conseqncias: Os mesmos bugs reaparecendo, apesar de vrias correes locais; maior tempo de reviso e inspeo de cdigo; maior custo na manuteno do software Soluo: Enfatizar estratgia de reuso caixa-preta no desenvolvimento ou re-estruturao do cdigo
ilmr
35
Antipadres de arquitetura de software
Sistemas encanamento: integrao ponto-a-ponto Travamento ao vendedor: no se esquea de renovar a licena Slide 35
Arquitetura por implicao: j zemos sistemas assim antes Projeto por comit: camelo (s.m.): cavalo projetado por um comit
Reinventar a roda: nosso problema diferente dos outros
Paralisia da anlise: melhor repensar esses modelos de anlise para torn-los mais orientados a objetos Slide 36 Morte por planejamento: no podemos comear enquanto no houver um plano completo de programao Espigas de milho: sujeitinho difcil de trabalhar. . . Gerenciamento irracional: as prioridades do projeto so as minhas! Falta de gerenciamento: o que aconteceu de errado? Estava tudo indo to bem
ilmr
Ingresso do lobo: suportamos padro X (mas interfaces so proprietrias)
Canivete suo: tudo que pensamos foi includo no projeto
Antipadres de gerncia de projetos de software
37
Padres de projeto
Slide 37
Onde esto os caminhos para as boas solues?
O que um padro de projeto?
Slide 38
ilmr
Solues para problemas especcos em projeto de software orientado a objetos

Desenvolvidas atravs da reviso e evoluo ao longo de vrios projetos
Descrio geral de um padro composta por

Nome: criao de um vocabulrio Problema: quando aplicar o padro Soluo: descrio abstrata de elementos que compem o projeto Conseqncias: resultados e compromissos associados aplicao do padro
39
Por que reusar projetos ao invs de cdigo?
Slide 39
Identicao de objetos: auxiliam a identicar abstraes recorrentes de forma genrica Granularidade de objetos: indicam como representar subsistemas como objetos ou suportar vrios objetos pequenos Especicao de interfaces: indicam os conceitos chaves que devem (ou no devem) estar na interface de um objeto, assim como relacionamentos entre interfaces Especicao de implementao: indicam que classes devem ser abstratas (puras) ou concretas, embora a implementao deva sempre favorecer referncias a interfaces
Slide 40
ilmr
Pode ser aplicado em mais contextos

mais compartilhvel
Ocorre mais cedo no processo de desenvolvimento

maior impacto
Projeto
Cdigo
Problemas de projeto abordados por padres
41
Padres, orientao a objetos e reuso
Slide 41
area( )
Slide 42
width height
re tu rn rec ta ng le > a rea ()
ilmr
Objetos, interfaces, classes e herana no garantem reuso Abordagens de reuso na orientao a objetos: Herana de classes: reuso caixa-branca, denio esttica (tempo de compilao), simples, mas expe superclasse Composio de objetos: reuso caixa-preta, denio dinmica (obter referncia durante execuo), mais complexo de compreender (uso de delegao, principalmente) Padres de projeto favorecem equilbrio desses mecanismos Outra abordagem de reuso, no ligada OO: templates (C++)
Derivao vs delegao
Rectangle
rec ta ng le re tu rn wid th*h e igh t
Rectangle
Window
area( )
area( )
width height
Window
43
Agregao vs associao
Slide 43
Slide 44
ilmr
Agregao: objeto composto por outros objetos ou um objeto parte de outro objeto
mesmo tempo de vida
Associao: objeto referencia outro objeto

acoplamento menor
Na programao, construes similares

Referncias ou ponteiros para objetos da outra classe
Potenciais problemas no projeto de sistemas modicveis: Criar objetos especicando explicitamente sua classe
Assume compromisso com uma implementao em particular, podendo comprometer futuras modicaes Padres de projeto associados: Mtodo Fbrica, Fbrica Abstrata, Prottipo
45
Padro: Mtodo Fbrica

Objetivo: Denir uma interface para criar um objeto, mas deixar que as subclasses decidam qual classe instanciar Motivao: o sistema sabe que ser preciso criar um objeto, mas naquele ponto do cdigo no sabe que tipo de objeto ser criado Conseqncias: isola classes especcas da aplicao do cdigo do sistema; oferece um ponto de extenso (hook) para subclasses Aspectos de implementao: mtodo fbrica pode ter implementao padro ou ser abstrato em Criador; pode ter parmetros para indicar tipo de objeto a criar; em C++, templates podem ser utilizados; um padro de nomeao deve ser utilizado
Slide 45
Estrutura:
Criador
Produto
metodoFabrica() umaOperacao()
produto = metodoFabrica()
Slide 46
ProdutoConcreto
CriadorConcreto
metodoFabrica()
return new ProdutoConcreto
ilmr
47
Padro: Fbrica Abstrata

Objetivo: Oferecer uma interface para criar famlias de objetos relacionados ou dependentes sem especicar suas classes concretas Motivao: trabalhar com uma interface no cdigo que seja comum para distintas alternativas de implementao daquele conjunto de funcionalidades Conseqncias: isola classes concretas do sistema; permite facilmente trocar famlias de produtos; promove consistncia entre produtos; no simples estender a fbrica para criar novos tipos de produtos Aspectos de implementao: tipicamente, apenas um objeto do tipo fbrica para uma famlia de produtos existe no sistema; a criao do produto d-se tipicamente atravs de um mtodo fbrica
Slide 47
Estrutura:
Cliente Fbr icaAbs tr ata
P r odutoAAbs tr ato
criaProdutoA() criaProdutoB()
ProdutoA1
ProdutoA2
F bricaConcreta2 F bricaConcreta1
Slide 48
P r odutoBAbs tr ato
criaProdu toA() criaProdu toB()
criaProdu toA() criaProdu toB()
ProdutoB1
ProdutoB2
ilmr
49
Padro: Prottipo
Objetivo: Especicar o tipo de objeto que deve ser criado usando uma instncia de prottipo e criar novos objetos copiando este prottipo Aplicabilidade: sistema deve ser independente de como objetos devem ser criados, compostos ou representados, e
Conseqncias: permite acrescentar e remover produtos em tempo de execuo; reduz nmero de subclasses; classes devem implementar um mtodo clone (nem sempre simples)
Estrutura:
Cliente
operacao()
prototype
Slide 50
p = prototype > clone()
ilmr
Slide 49
classes a serem instanciadas so conhecidas apenas no momento da execuo, ou para evitar construir uma hierarquia de fbricas paralela hierarquia de classes de produtos
Prototipo
clone()
PrototipoConcreto1
clone()
PrototipoConcreto2
clone()
51
Potenciais problemas no projeto de sistemas modicveis: Estar dependente de operaes especcas

Slide 51
Slide 52
Objetivo: Evitar o acoplamento direto de um solicitante em relao ao atendente de uma requisio dando a oportunidade de ter mais de um objeto respondendo solicitao. Os atendentes so encadeados e a requisio passada por eles at que um dos objetos a atenda. Conseqncias: reduz acoplamento e obtm maior exibilidade na atribuio de responsabilidades a objetos, porm no h garantia de que algum objeto atender a solicitao. Aspectos de implementao: como implementar a cadeia de sucessores (referncias novas ou existentes), como representar as solicitaes (mtodos, objetos)
ilmr
Assume compromisso com uma forma de atender a uma requisio; seria melhor no ter essa denio amarrada ao cdigo Padres de projeto associados: Cadeia de responsabilidade, Comando
Padro: Cadeia de responsabilidade
53
Estrutura:
Cliente
Hand ler
hand leR equest( )
successor
Slide 53
ConcreteHandler1
ConcreteHandler2
handleRequest( )
handleRequest( )
Padro: Comando
Objetivo: encapsular uma requisio como um objeto, permitindo parametrizar clientes com diferentes solicitaes, enleirar ou registrar solicitaes e suportar operaes que podem ser desfeitas. Conseqncias: desacopla objeto que invoca o servio daquele que sabe como execut-lo; solicitaes, sendo objetos, podem ser manipuladas e compostas como tais.
Slide 54
ilmr
55
Estrutura:
Invoker
Client Command
ex ecute( )
Slide 55
Receiver
action( )
receiver
ConcreteCommand
ex ecute( )
receiver > action( );
state
Potenciais problemas no projeto de sistemas modicveis: Depender da plataforma de hardware e software

Slide 56
ilmr
Usar diretamente APIs e interfaces para sistemas externos que dependem da plataforma de execuo torna portabilidade e mesmo atualizao na prpria plataforma difceis Padres de projeto associados: Fbrica abstrata, Ponte
57
Padro: Ponte
Objetivo: desacoplar uma abstrao de sua implementao de forma que os dois possam variar independentemente. Motivao: uma forma de evitar o acoplamento denitivo entre abstrao e implementao que se d atravs de herana Conseqncias: desacopla interface e implementao, melhora extensibilidade e esconde detalhes de implementao de clientes.
Slide 57
Estrutura:
Client
Abstraction
impl
Implementor
operationImp( )
Slide 58
operation( )
impl > operationImpl( );
RefinedAbstraction
ConcreteImplementorA
usesOperation( )
operationImpl( )
ilmr
59
Potenciais problemas no projeto de sistemas modicveis: Depender de representaes ou implementaes de objetos

Slide 59
Objetivo: Sem violar encapsulao, capturar e externalizar o estado interno de um objeto de forma que ele possa ser restaurado para esse estado em um momento posterior. Slide 60 Motivao: Um memento um objeto que armazena o estado interno de um outro objeto (o originador do memento). Aplicabilidade: usar quando um instantneo (total ou parcial) de um objeto deve ser salvo para posterior recuperao e uma interface direta para obter esse estado exporia detalhes de implementao, quebrando a encapsulao do objeto.
ilmr
Clientes que sabem como um objeto representado, armazenado, localizado ou implementado podem ter que sofrer modicaes quando o objeto muda. Padres de projeto associados: Fbrica abstrata, Memento, Proxy
Padro: Memento
61
Estrutura:
memento
Originator
setMemento(Memento m) createMemento()
M emento
g etS tate() setS tate()
Caretaker
Slide 61
state
state
m = new Memento(); m>setState(state); return m;
state = m>getState();
Padro: Proxy
Objetivo: Oferecer um surrogate para outro objeto para controlar o acesso a ele. Slide 62 Aplicabilidade: Sempre que for necessrio ter uma referncia para um objeto que seja mais verstil ou sosticada que um simples ponteiro proxy remoto (referncias fora do espao de endereamento local), proxy virtual (atrasa criao de objetos caros at que haja demanda real), proxy de proteo (controla acesso ao objeto original) e referncias espertas com funcionalidades adicionais (contar nmero de referncias para liberao automtica, carregar objetos persistentes na primeira referncia, locking).
ilmr
63
Estrutura:
Client
Sub ject
request( )
Slide 63
R ealSub ject
request( )
real
...
P roxy
request( )
... real>request( ); ...
Potenciais problemas no projeto de sistemas modicveis: Depender de algoritmos
ilmr
Slide 64
Algoritmos podem ser estendidos, otimizados ou substitudos durante desenvolvimento ou reuso; se objeto depender de um algoritmo especicamente, tambm dever ser alterado nesses casos Padres de projeto associados: Estratgia, Mtodo Gabarito, Iterador
65
Padro: Estratgia
Objetivo: denir uma famlia de algoritmos, encapsul-los e torn-los intercambiveis, permitindo que o algoritmo varie independentemente de seus clientes Slide 65 Aplicabilidade: usar quando classes relacionadas diferem apenas em seu comportamento; quando diferentes variantes de um algoritmo so necessrias; quando se deseja encapsular estruturas de dados complexas, especcas do algoritmo; quando a classe dene diversos comportamentos com mltiplas ocorrncias de um padro condicional Conseqncias: em famlias de algoritmos relacionados, herana pode fatorar funcionalidades comuns; uma alternativa para derivao direta; cliente exposto s diferentes estratgias disponveis
Estrutura:
Context
Strateg y
contextInterface( )
algorithmInterface( )
Slide 66
ConcreteStrategyA ConcreteStrategyB
ilmr
67
Padro: Mtodo Gabarito

Objetivo: denir o esqueleto de um algoritmo em uma operao, postergando alguns passos para subclasses Motivao: permite a descrio do algoritmo em termos de operaes abstratas, que devero ser redenidas nas subclasses Slide 67 Aplicabilidade: usar para implementar as partes invariantes de um algoritmo uma nica vez; quando comportamento comum pode ser fatorado em uma superclasse Conseqncias: algumas operaes usadas pelo mtodo gabarito podem ser hooks (podem ser redenidas) ou operaes abstratas (tem que ser redenidas); leva ao Princpio de Holywood (superclasse invoca mtodos de classe derivada e no ao contrrio)
Estrutura:
AbstractClass
templateMethod( ) primitiveOperation1( ) primitiveOperation2( )
Slide 68
ConcreteClass
primitiveOperation1( ) primitiveOperation2( )
... primitiveOperation1( ); ... primitiveOperation2( ); ...
ilmr
69
Padro: Iterador
Objetivo: oferecer uma forma de acessar os elementos de um objeto agregado seqencialmente sem expor sua representao interna Slide 69 Motivao: suportar formas (eventualmente, alternativas) de varrer agregados sem ter de incorporar essas funcionalidades interface do agregado; ter mecanismo uniforme de varrer estruturas agregadas distintas Conseqncias: simplica a interface do agregado; pode ter mais de uma varredura sobre o mesmo agregado em um dado momento
Estrutura:
Agg reg ate
createIterator( )
Cliente
Iterator
first( ) next( ) current( ) isDone( )
Slide 70
ConcreteAggregate
ConcreteIterator
createIterator( )
ilmr
71
Potenciais problemas no projeto de sistemas modicveis: Acoplamento forte
Objetivo: oferecer uma interface unicada para um conjunto de interfaces em um subsistema Slide 72 Motivao: denir uma interface de nvel mais alto para tornar o subsistema mais fcil de utilizar Aplicabilidade: usar quando quiser oferecer uma interface simples para um subsistema complexo; quando houver muitas dependncias entre clientes e as classes de implementao de uma abstrao; quando quiser estruturar os subsistemas em camadas
ilmr
Slide 71
Classes fortemente acopladas so difceis de reutilizar isoladamente, levando a sistemas monolticos e de difcil manuteno Padres de projeto associados: Fbrica Abstrata, Ponte, Cadeia de Responsabilidade, Comando, Fachada, Mediador, Observador
Padro: Fachada
73
Estrutura:
F acade
Slide 73
Padro: Mediador
Objetivo: denir um objeto que encapsula como conjuntos de outros objetos interagem Slide 74 Motivao: reduzir o nmero de interconexes entre objetos fazendo com que eles se comuniquem atravs do mediador Conseqncias: desacopla objetos colegas; simplica protocolos entre objetos; porm, mediador centraliza controle, tornando-se eventualmente um elemento complexo e de difcil reuso
ilmr
75
Estrutura:
Mediator
m ediator
Colleag ue
Slide 75
ConcreteMediator ConcreteColleague1 ConcreteColleague2
Padro: Observador
Objetivo: denir uma dependncia de um objeto para muitos de forma que, quando um objeto muda de estado, todos os seus dependentes so noticados e automaticamente atualizados Slide 76 Motivao: manter consistncia entre objetos da aplicao sem recorrer a um forte acoplamento entre eles Aplicabilidade: usar quando uma abstrao tem dois aspectos, um dependente do outro; quando mudana em um objeto requer mudanas em outros; quando um objeto deve poder noticar outros sem assumir nenhum conhecimento sobre quais so esses outros objetos
ilmr
77
Estrutura:
Subject
attach(Observer) detach(Observer) notify( )
for all o in observers o>update()
observers
Observer
update( )
Slide 77
ConcreteSubject
getS tate( ) setS tate( )
subject
ConcreteObserv er
u pdate( )
observerS tate
subjectS tate
return subjectState observerState = subject>getState();
Outros padres de projeto em GoF

Adaptador: converte a interface de uma classe em outra interface do tipo que o cliente espera (padro estrutural); Composto: representa hierarquias parte-todo e permite tratar a composio e os objetos individuais de forma uniforme (padro estrutural); Slide 78 Construtor: separa a construo de um objeto complexo de sua representao de forma que o mesmo processo de construo possa criar representaes diferentes (padro de criao); Decorador: acrescenta funcionalidades adicionais a um objeto de forma dinmica (padro estrutural); Estado: permite que um objeto modique seu comportamento quando seu estado interno muda (padro de comportamento);
ilmr
79
Interpretador: dene a representao para uma gramtica e um interpretador para sentenas nessa linguagem (padro de comportamento); Peso-pena: usa compartilhamento para lidar com grande nmero de pequenos objetos de forma eciente (padro estrutural); Visitante: representa uma operao a ser executada nos elementos da estrutura de um objeto; Singleton: garante que uma classe tem apenas uma instncia e oferece um ponto de acesso para essa instncia (padro de criao);
Slide 79
Padres e frameworks
Padres de projeto: descries de solues de projeto recorrentes que foram aprovadas pelo uso ao longo do tempo; Slide 80 Frameworks: projeto reutilizvel do todo ou de parte de um sistema que representada por um conjunto de classes abstratas e pela forma que suas instncias interagem
ilmr
menos abstratos que padres tipicamente contm vrios padres
81
Frameworks e reuso
Slide 81
Modularidade: detalhes de implementao so encapsulados por trs de interfaces estveis Slide 82 Reusabilidade: denem componentes genricos associados s interfaces estveis que podem ser reutilizados para criar novas aplicaes Extensabilidade: denem pontos de adaptao e extenso nas interfaces estveis (pontos variveis, mtodos hook) Inverso de controle: framework dene seqncia de invocao da aplicao
ilmr
Reuso de projeto
um framework dene um esqueleto de aplicao que pode ser adaptado por um desenvolvedor de aplicao um tipo de arquitetura voltada para um domnio
Reuso de cdigo
frameworks so expressos em linguagens de programao so programas facilita uso de componentes que se conformem s interfaces do framework tornam-se dependentes das linguagens
Caractersticas de frameworks
Princpio de Hollywood
83
Formas de adaptao em frameworks

Formas bsicas de associar os mtodos da aplicao aos mtodos do framework: Adaptao caixa-branca: reuso por herana aplicao deve denir classes que estendem as classes abstratas do framework e redenir mtodos Adaptao caixa-preta: reuso por composio aplicao escolhe subclasse concreta (dentre as disponveis) e utiliza suas funcionalidades via sua interface Adaptao caixa-cinza: oferece alternativas de implementao (como caixa-preta) mas permite implementaes especcas (como caixa-branca)
Slide 83
Pontos de adaptao no framework

F ram ew rk o F ram ew rk o
Slide 84
Ponto varivel X
Ponto varivel X
Xk
X1
Xk Xn
ilmr
85
Tipos de frameworks
Slide 85
Frameworks caixa-branca: todos os pontos variveis so caixa-branca; Frameworks caixa-preta: todos os seus pontos variveis so caixa-preta; Frameworks caixa-cinza: apresenta pontos-variveis caixa-cinza.
Aspectos de desenvolvimento e utilizao dos diferentes tipos de frameworks
Slide 86
ilmr
Frameworks caixa-branca so mais simples de se projetar e desenvolver

no precisa oferecer implementaes dos pontos variveis
Frameworks caixa-preta so de utilizao mais simples Frameworks caixa-cinza tendem a caixa-preta

Implementaes realizadas passam a fazer parte do conjunto de implementaes disponveis
87
Desenvolvimento de software centrado em frameworks
Slide 87
1. identicar domnio especco de aplicao do framework 2. determinar os principais casos de uso suportados e atores interagindo com o framework Slide 88 3. determinar padres/solues para auxiliar desenvolvimento do framework 4. projetar interfaces e componentes do framework; mapear atores e papis para as interfaces 5. desenvolver implementao padro para interfaces do framework 6. descrever e documentar os pontos de extenso do framework 7. criar planos e casos de teste
ilmr
Trs fases principais: 1. Desenvolvimento do framework 2. Uso do framework 3. Manuteno do framework
Tarefas para o desenvolvimento de frameworks
89
Desenvolvimento de framework baseado em pontos variveis
Slide 89
Slide 90
identificar objetos e classes
ilmr
Anlise do domnio identica pontos variveis quais aspectos do framework diferem entre aplicaes? qual o grau de exibilidade desejado? o comportamento exvel precisa ser alterado durante o funcionamento da aplicao?
Ciclo de desenvolvimento baseado em pontos variveis
Especialista do domnio
M etapadres
Desenv olv edor
identificar pontos variveis
(R e)projeto do fram ew rk o
Adaptao do fram ew rk o
pontos variveis satisfazem ?
91
Metapadres
Slide 91
Slide 92
ilmr
Estabelecem padres de relao entre classes genricas (template classes) e classes componentes (hook classes) Classes genricas possuem os mtodos gabaritos, que denem comportamento abstrato, uxo de controle genrico, relao entre objetos Classes componentes possuem os mtodos componentes, que fazem parte das implementaes dos mtodos gabaritos e podem ser abstratos, regulares ou novos gabaritos.
Metapadres de unicao
U nificao recursiva 1: 1
thRef
TH
U nificao
U nificao recursiva 1: n
thList
*
TH
TH
93
Metapadres de conexo
Conexo recursiva 1: 1 Conexo recursiva 1: n
Conexo 1: 1
Conexo 1: n
Slide 93
T
hRef
T
hList
* H H
hRef
hList
Desenvolvimento de framework baseado em generalizao sistemtica
Slide 94
ilmr
Criao de um modelo de aplicao no domnio Anlise de alto nvel dos pontos variveis Para cada ponto varivel detectado
anlise e especicao detalhada projeto de alto nvel transformao do modelo de classes por generalizao com o subsistema de ponto varivel
95
Subsistemas de ponto varivel (hot spots)
Slide 96
ilmr
Slide 95
Outra forma de estabelecer os padres bsicos de relao entre as classes genricas e suas concretizaes Variabilidade obtida por meio de uma referncia polimrca, que estabelece a ligao dinmica entre o mtodo genrico e as operaes concretas Quando a ligao faz referncia a servios dentro do prprio sistema, o subsistema de ponto varivel recursivo
Subsistema de ponto varivel no-recursivo
cliente
Bas e
C oncreta1
C oncreta2
97
Subsistema de ponto varivel recursivo 1:1

1
cliente
Bas e
Slide 97
C oncreta1
C oncreta2
Subsistema de ponto varivel recursivo 1:n

*
cliente
Bas e
Slide 98
C oncreta1
C oncreta2
ilmr
99
Relao entre padres, metapadres e subsistemas de ponto varivel
Subsistema de ponto varivel
Metapadro unicao, conexo conexo 1:n 1:1,
Padro de projeto fbrica abstrata, mtodo fbrica, prottipo, ponte, comando, iterador, observador, estratgia, mtodo gabarito, construtor, adaptador, mediador, estado, visitante cadeia de responsabilidade, decorador composto, interpretador
Slide 99
no recusivo
recursivo 1:1 recursivo 1:n
conexo recursiva 1:1, unicao recursiva 1:1 conexo recursiva 1:n, unicao recursiva 1:n
Uso do framework
Slide 100
ilmr
Quando ocorre o desenvolvimento de aplicaes

Instanciao do framework
Sucesso dependente em grande parte da boa documentao sobre o framework

Identicao dos pontos de adaptao Padres utilizados Exemplos
Aprender a usar um framework requer investimento de tempo e dinheiro
101
Manuteno de frameworks
Slide 101
Slide 102
Infra-estrutura: framework simplica o desenvolvimento da infra-estrutura de sistemas de forma porttil e eciente; tipicamente de uso no desenvolvimento interno s empresas Integrao middleware: framework permite a integrao de componentes e aplicaes distribudas; parte importante dos sistemas modernos Aplicao empresarial: framework voltado para uma rea de aplicao; foco de desenvolvimento nas empresas desenvolvendo aplicaes para usurios nais
ilmr
Desenvolvimento de aplicaes aumenta reusabilidade do framework

maior disponibilidade de classes concretas (reuso caixa-preta) identicao de decincias para futuras extenses
Revises em frameworks tendem a ser problemticas

compatibilidade de aplicaes j desenvolvidas com o mesmo framework; devem evoluir juntas
Em alguns casos, reviso do domnio

estabelecimento de novas fronteiras
Classicao de frameworks pelo escopo de uso
103
Potenciais problemas na integrao de frameworks
Foco no desenvolvimento dos frameworks est na extenso das funcionalidades, no na integrao com outros frameworks Slide 103
Coeso do framework: quo amarrada est a conexo de uma classe do framework s demais? Cobertura do domnio: quo bem especicado e isolado est o domnio de aplicao do framework? Objetivos do projeto: os desenvolvedores do framework devem explicitar se integrao foi uma preocupao no projeto Falta de acesso ao cdigo fonte: integrao pode requerer modicaes e adaptaes no cdigo; importante ter uma abordagem open source Falta de padres: ainda no h padres voltados para o desenvolvimento de frameworks
Slide 104
ilmr
Alguns frameworks podem assumir que tm controle completo sobre o uxo de execuo da aplicao
Quando mais de um framework em uso. . . ?
Como integrar sistemas legados a frameworks? O que acontece se dois frameworks tm componentes com sobreposio de funcionalidades?
Causas dos problemas de integrao de frameworks
105
Estratgias para integrao de frameworks
Slide 105
Slide 106
ilmr
Usar threads de execuo independentes para cada framework Usar padro Adaptador para estabelecer integrao com cdigo legado Alterar cdigo do framework No desenvolvimento:
Tornar explcitas e bem documentadas as decises relativas arquitetura do framework Construir o framework em blocos independentes Estabelecer no framework previses para congurao, mediao e adaptao, atravs do uso de padres
Aplicando as tcnicas de reuso na programao C++
Herana, composio, templates
107
O conceito da herana
Slide 107
Slide 108
ilmr
Princpio da substituio de Liskov

Se a classe D derivada da classe B, quando um objeto B for necessrio possvel usar um objeto D D is-a B (mas no vice-versa)
Denio de (boas) hierarquias de classes um dos conceitos chaves por trs da orientao a objetos
Aspectos da implementao da herana em C++
Mecanismos de derivao
Implementando hierarquias IS-A Lidando com excees nas hierarquias
Herana de interfaces vs herana de implementaes

separao de interface e implementao redenies de mtodos
109
C++ e hierarquias IS-A
Slide 109
Slide 110
ilmr
Atravs da derivao public class Pessoa { ... }; class Estudante : public Pessoa { ... }; Todo estudante uma pessoa Nem toda pessoa um estudante
void dance(const Pessoa& p); void estude(const Estudante& e); Pessoa p; Estudante e; dance(p); dance(e); estude(p); // oops estude(e);
111
Herana pblica vs. herana privada
Slide 111
Slide 112
ilmr
Derivao usando private no dene uma hierarquia do tipo IS-A como todos os membros da superclasse, pblicos ou protegidos, tornam-se privativos na nova classe, a interface da superclasse no herdada no h converso automtica de um objeto do tipo derivado para um objeto do tipo da classe base falha o princpio da substituio
class Pessoa { ... }; class Estudante : private Pessoa { ... }; void dance(const Pessoa& p); void estude(const Estudante& e); Pessoa p; Estudante e; dance(p); dance(e); // oops estude(p); // oops estude(e);
113
Lidando com pingins voadores
Slide 113
Slide 114
ilmr
Pssaros podem voar, pingins so pssaros. . .

class Passaro { public: virtual void voe(); ... }; class Pinguim : public Passaro { ... };
. . . mas pingins no voam!
Tratando o problema durante a execuo
void erro(const string& mens); class Pinguim : public Passaro { public: virtual void voe() { erro(Pingim no voa); } ... }; Pingins podem tentar voar, mas faz-lo um erro. Abordagem tipicamente adotada em linguagens interpretadas, mas no em C++
115
Revendo a hierarquia de classes
Slide 115
Slide 116
ilmr
Se no houver um mtodo voe denido para pingins, compilao j detectar o erro class Passaro { ... }; class PassaroVoador: public Passaro ( public: virtual void voe(); ... }; class PassaroNaoVoador: public Passaro { ... }; class Pinguim: public PassaroNaoVoador { ... };
Potenciais problemas na denio de hierarquias de classes por herana
Uso de intuio ou bom senso pode levar a hierarquias falhas

Exemplo com pingins pode parecer bvio, mas emblemtico de situaes reais de modelagem
Abuso de herana
Nem sempre a relao adequada entre duas classes a de herana Herana deve sempre ser uma expresso da relao IS-A
117
Interfaces e implementaes
Separao entre a especicao de uma interface e sua implementao essencial na boa programao orientada a objetos
Slide 117
Slide 118
ilmr
Interfaces tendem a estabilizar rapidamente, implementaes no Programar com base no conhecimento apenas da interface favorece programao genrica e reduz a dependncia de compilao entre mdulos do sistema
C++ favorece a mistura de interface e implementao
class Pessoa { public: Pessoa(string& nome, Data& aniv, Endereco& end, Pais& p); virtual ~Pessoa(); string nome() const; string dataNascimento() const; string endereco() const; string nacionalidade() const; private: string name_; Data birthday_; Endereco address_; Pais nation_; };
119
Destrutor virtual
Slide 119
Slide 120
ilmr
Por qu?
class Base { public: ~Base(); ... }; class Derivada: public Base { public: ~Derivada(); ... }; Base *p = new Derivada; delete p; // comportamento indefinido
Se destrutor na classe base for declarado como virtual, ambos sero invocados
Deve estar presente em qualquer classe que sirva de base para outras Mesmo que virtual puro, deve ter implementao
Dependncia em relao a outras denies
Classe Pessoa usa outras classes na denio de seus atributos

Tipicamente, no incio do mdulo: #include #include #include #include <string> "data.h" "endereco.h" "pais.h"
Cria dependncia deste mdulo (e dos que utilizem a classe Pessoa) em relao queles
121
Reduzindo a dependncia entre classes
Slide 121
Slide 122
ilmr
Usar declaraes ao invs de denies

Cdigo como class Data; Data hoje(); void ajustaData(Data d); no precisa conhecer a denio da classe Data para compilar
Da mesma forma, para denir ponteiros ou referncias basta conhecer a declarao, no a denio de um tipo
Separando os detalhes de implementao da interface
#include <string> class Data; class Endereco; class Pais; class PessoaImpl; class Pessoa { public: Pessoa(string& nome, Data& aniv, Endereco& end, Pais& p); virtual ~Pessoa(); string nome() const; string dataNascimento() const; string endereco() const; string nacionalidade() const; private: PessoaImpl *parte_impl; };
123
Repassando o trabalho para a implementao
Slide 123
#include "Pessoa.h" #include "PessoaImpl.h" Pessoa::Pessoa(string& n, Data& d, Endereco& e, Pais& p) { parte_impl = new PessoaImpl(n, d, e, p); } string Pessoa::nome() const { return parte_impl -> getNome(); } ...
Slide 124
ilmr
Qual padro de projeto est presente nesta abordagem?
Denindo interfaces puras (Protocolos)
Protocolos so classes abstratas sem nenhuma implementao

sem construtores sem atributos todos os mtodos abstratos (virtuais puros)
Classes que usam os protocolos operam com ponteiros ou referncias para essas classes
no possvel instanciar diretamente objetos de protocolos objetos de classes derivadas podem ser criados
125
Exemplo de protocolo C++
Slide 125
class Pessoa { public: virtual ~Pessoa(); virtual string nome() const = 0; virtual string dataNascimento() const = 0; virtual string endereco() const = 0; virtual string nacionalidade() const = 0; };
Construo de objetos associados a protocolos
Slide 126
ilmr
Objetos sero de classes derivadas do protocolo

class PessoaMesmo: public Pessoa { public: PessoaMesmo(string& n, Data& d, Endereco& e, Pais& p) : name_(n), birthday_(d), address_(e), nation_(p) {} string nome() const; ... private: string name_; ... };
127
Construo de objetos via protocolos
Slide 127
Slide 128
ilmr
Em geral, d-se atravs de mtodo esttico associado ao prprio protocolo

class Pessoa { public: ... static Pessoa * fazPessoa(string& n, Data& d, Endereco& e, Pais& p); }; Pessoa * Pessoa::fazPessoa(string& n, Data& d, Endereco& e, Pais& p) { return new PessoaMesmo(n, d, e, p); }
Algum padro reconhecido aqui?
Herana de interface e herana de implementao de mtodos

O que de um mtodo se pretende passar de uma classe base para uma classe derivada?
Apenas sua interface (declarao); A interface e a implementao, porm permitindo que classe derivada dena nova implementao (especializaes); A interface e a implementao, sem permitir que a classe derivada dena nova implementao (aspecto invariante).
129
Trs tipos de mtodos
Slide 129
Slide 130
ilmr
Para a classe abstrata Shape,

class Shape { public: virtual void draw() = 0; virtual void error(string & msg); int objectID(); ... };
os trs mtodos estaro presentes em suas classes derivadas publicamente.
Apenas herana de interface
Obtida pelo uso da funo virtual pura No exemplo, draw No precisa (mas at poderia) ter uma implementao Se Rectangle e Ellipse so derivadas de Shape,
Shape *ps1 = new Rectangle; ps1->draw(); Shape *ps2 = new Ellipse; ps2->draw(); ps1->Shape::draw();
131
Herana de interface com implementao padro
Slide 131
No h diferena entre pilotar um Avio ModeloA ou um Avio ModeloB; outros poderiam ser diferentes:
class Aviao { public: virtual void voePara(string& destino); ... }; class ModeloA : public Aviao { ... }; class ModeloB : public Aviao ( ... };
Slide 132
ilmr
Obtida com mtodos virtuais normais Classe derivada pode optar entre usar a implementao padro oferecida pela superclasse ou denir a prpria implementao, especializada Potencial problema de manuteno
Se a hierarquia crescer (novas classes derivadas) e o padro no mais for aplicvel
133
J pilotar o novo Avio ModeloC diferente. . .

class ModeloC : public Aviao { ... //oops}; Aviao eqp = new ModeloC; eqp->voePara("JFK"); // desastre
Slide 133
Slide 134
ilmr
Problema no ter uma implementao padro, mas permitir que a classe derivada a utilize sem dizer explicitamente que ir faz-lo
Separando a interface da implementao padro

Usar mtodo privativo, no-virtual:
class Aviao { public: virtual void voePara(string& dest) = 0; ... private: void vaiPorMim(string& dest); }; void ModeloA::voePara(string& dest) { vaiPorMim(dest); }
135
Separando a interface da implementao padro (2)
Slide 135
Slide 136
ilmr
Alternativamente, pode usar denio para funo virtual pura:

class Aviao { public: virtual void voePara(string& dest) = 0; ... }; void Aviao::voePara(string& dest) { // procedimento padro } void ModeloA::voePara(string& dest) { Aviao::voePara(dest); }
Perde a proteo para implementao padro
Mtodos invariantes na especializao
Comportamento no pode ser alterado em classes derivadas Situao obtida com uso das funes no-virtuais Dene interface e implementao mandatria Mtodo no-virtual nunca deve ser redenido em classes derivadas
137
Nunca redenir mtodos no-virtuais

class class D x; B *pB D *pD B { public: void mf(); ... }; D: public B { ... }; = &x; pB->mf(); = &x; pD->mf();
Slide 137
Slide 138
ilmr
Se D redene mf, as duas invocaes de mf tero comportamento diferente
Porque no redenir mtodos no-virtuais
Mtodos no virtuais so ligados em tempo de compilao Mesmo que atravs de ponteiros, a implementao utilizada ser a do tipo do ponteiro e no a do tipo do objeto na execuo O mesmo ocorre para valores padro de funes virtuais
valores padro so ligados estaticamente pode invocar corpo denido na classe derivada com valores padres denidos na superclasse concluso: no devem ser redenidos
139
Trabalhando com composio
Slide 139
Slide 140
ilmr
Para modelar expresses do tipo tem um (objeto de outra classe) ou implementado usando (outro tipo de objeto)
class Pessoa { ... private: string nome; // Pessoa tem um nome Endereco end; // e tem um endereco ... };
Composio e implementado usando
Exemplo: implementar uma coleo do tipo conjunto usando uma estrutura de dados do tipo lista um conjunto no uma lista
conjuntos no podem ter elementos duplicados, listas podem herana pblica no uma boa opo
pode denir atributo usando list da STL
141
Denio da classe Set:

template<class T> class Set { public: bool member(const void insert(const void remove(const int cardinality( private: list<T> rep; };
Slide 141
T& item) const; T& item); T& item); ) const;
Exemplo de mtodos de Set:

template<class T> bool Set<T>::member(const T& item) const { return find(rep.begin(), rep.end(), item) != rep.end(); } template<class T> void Set<T>::insert(const T& item) { if(!member(item)) rep.push_back(item); } template<class T> void Set<T>::remove(const T& item) { list<T>::iterator it = find(rep.begin(), rep.end(), item); if (it != rep.end()) rep.erase(it); } template<class T> int Set<T>::cardinality( ) const { return rep.size(); }
Slide 142
ilmr
143
Herana ou templates
Slide 143
Slide 144
ilmr
Na denio de um conjunto de classes com pequenas diferenas entre si, qual mecanismo usar? herana: fatorar parte comum em superclasse (abstrata), derivar as classes concretas e em cada uma denir a especializao da classe template: denir o cdigo para a classe genrica em termos de um tipo parametrizado e instanciar, para cada tipo desejado, uma verso da denio da classe especializada Usar herana quando o tipo do objeto muda o comportamento dos mtodos, usar template quando comportamento invariante com o tipo parametrizado
template<class T> class Stack { public: Stack(); ~Stack(); void push(const T& obj); T pop(); bool empty() const; private: struct StackNode { T data; StackNode *next; StackNode(const T& newData, StackNode *nextNode) : data(newData), next(nextNode) { } }; StackNode *top; Stack(const Stack& rhs); Stack& operator=(const Stack& rhs); };
145
Slide 145
[--- template<class T> ---] Stack<T>::Stack() : top(0) {} void Stack::push(const T& obj) { top = new StackNode(obj, top); } T Stack<T>::pop() { StackNode *topOfStack = top; top = top->next; T data = topOfStack->data; delete topOfStack; return data; } Stack<T>::~Stack() { while(top) { StackNode *toDie = top; top = top->next; delete toDie; } } bool Stack<T>::empty() const { return top == 0; }
Templates vs ponteiros genricos
Slide 146
ilmr
Ponteiros genricos (void*) oferecem outra alternativa que permite ter o mesmo comportamento para diferentes tipos de objetos sem a replicao de cdigo que templates geram Dois passos 1. criar a classe que manipula os ponteiros genricos 2. criar classes que enforam a converso correta dos ponteiros
147
Classe pilha genrica (opo 1):

class GenericStack { public: GenericStack(); ~GenericStack(); void push(void *obj); void *pop(); bool empty() const; private: struct StackNode { void *data; StackNode *next; StackNode(void *newData, StackNode *nextNode) : data(newData), next(nextNode) { } }; StackNode *top; GenericStack(const GenericStack& rhs); GenericStack& operator=(const GenericStack& rhs); };
Slide 147
Classe para converso de tipos (opo 1):

class IntStack { public: void push(int *ip) {s.push(ip);} int *pop() {return static_cast<int *>(s.pop());} bool empty() const { return s.empty();} private: GenericStack s; };
Slide 148
ilmr
149
Comentrios sobre essa implementao
Slide 149
Classe pilha genrica (opo 2):

class GenericStack { protected: GenericStack(); ~GenericStack(); void push(void *obj); void *pop(); bool empty() const; private: struct StackNode { void *data; StackNode *next; StackNode(void *newData, StackNode *nextNode) : data(newData), next(nextNode) { } }; StackNode *top; GenericStack(const GenericStack& rhs); GenericStack& operator=(const GenericStack& rhs); };
Slide 150
ilmr
No h custo adicional no uso de IntStack todos os mtodos so inline Nada impede que cliente use diretamente objetos da classe GenericStack Alternativa: evitar manipulao direta de GenericStack protegendo sua criao e interface
151
Classe para converso de tipos (opo 2):

class IntStack: private GenericStack { public: void push(int *ip) {GenericStack::push(ip);} int *pop() {return static_cast<int *>(GenericStack::pop());} bool empty() const { return GenericStack::empty();} };
Slide 151
Classe para converso de tipos (generalizando os tipos possveis de interface):

template<class T> class Stack: private GenericStack { public: void push(T *op) {GenericStack::push(op);} T *pop() {return static_cast<T*>(GenericStack::pop());} bool empty() const { return GenericStack::empty();} };
Slide 152
ilmr
153
Herana mltipla
Slide 153
Slide 154
ilmr
No h uma posio clara na comunidade de orientao a objetos sobre os benefcios da herana mltipla Por que deve ser evitada (ou, pelo menos, usada com muito cuidado. . . )? Ambigidade potencial Mltiplas ocorrncias da base
Ambigidade potencial
Base1
faz(): int
Base2
faz():void
D erivada
155
Ambigidade potencial (C++)
Slide 155
class Base1 { public: int faz(); };
class Base2 { public: void faz(); };
class Derivada: public Base1, public Base2 { ... // sem faz() }; Derivada d; d.faz();
// erro de compilao
Restringir acesso no resolve o problema:

class Base1 { public: int faz(); }; class Base2 { private: void faz(); };
Slide 156
class Derivada: public Base1, public Base2 { ... // sem faz() }; Derivada d; int i = d.faz();
// continua erro de compilao
ilmr
157
Por que compilador no leva em conta as especicaes de acesso?
Para resolver ambigidade, apenas atravs da qualicao dos membros (referncias explcitas classe base):
d.Base1::faz(); d.Base2::faz();
ilmr
Slide 158
Slide 157
Porque modicaes na visibilidade de membros das classes no deveria modicar o signicado de programas Se a abordagem anterior resolvesse o problema, apenas modicao na visibilidade mudaria o comportamento do programa sem modicar invocao ou corpo dos mtodos
Se mtodos fossem virtuais, no teria como explorar redenies mesmo que objeto fosse de uma classe derivada da base, a qualicao faz com que o mtodo invocado seja exatamente o especicado.
159
E se dois mtodos, com os mesmos tipos de argumentos, fossem virtuais e a classe derivada quisesse redenir os dois?
Slide 159
Slide 160
ilmr
no h como fazer diretamente Apenas um mtodo pode existir numa classe com um dado nome e lista de tipos de argumentos possvel atravs da criao de classes auxiliares, sem correspondncia com a modelagem da aplicao
class AuxBase1: public Base1 { public: virtual int faz1() = 0; virtual int faz() { return faz1(); } }; class AuxBase2: public Base2 { public: virtual void faz2() = 0; virtual void faz() { faz2(); } }; class Derivada: public Base1, public Base2 { public: virtual int faz1(); virtual void faz2(); }; Derivada *d = new Derivada; Base1 *p1 = d; Base2 *p2 = d; p1->faz(); // chama faz1 p2->faz(); // chama faz2
161
Mltiplas ocorrncias da classe base
C om um
Slide 161
Base1 Base2
D erivada
Tipicamente, classe comum uma classe base virtual:

class class class class Comum { ... }; Base1: virtual public Comum { ... }; Base2: virtual public Comum { ... }; Derivada: public Base1, public Base2 { ... };
Slide 162
ilmr
Classe base virtual impe penalidades de acesso (tipicamente, implementao por ponteiros na estrutura interna) Mas e se Comum, Base1 e Base2 existissem antes e independentemente de Derivada (por exemplo, em uma biblioteca)? bom projeto requer viso proftica. . .
163
Outros problemas na herana mltipla
Passagem de argumentos para construtor de classe base virtual:
Slide 163
Na herana mltipla, lista de inicializao do construtor est na classe que mais derivada da base pode estar distante na hierarquia de classes pode variar a posio com evoluo da hierarquia
Soluo: classes bases virtuais sem atributos (estilo interface de Java)
Dominncia das funes virtuais:

class Comum { public: virtual void f(); ... }; class Base1: virtual public Comum { ... }; class Base2: virtual public Comum { public: virtual void f(); ... }; class Derivada: public Base1, public Base2 { ... };
ilmr
Slide 164
H ambigidade nesse cdigo?

Derivada *pd = new Derivada; pd->f();
Se Comum no fosse base virtual de Base1 ou Base2, haveria
Como , f da Base2 utilizada (domina a hierarquia)

165
Em herana simples, sem bases virtuais, construtores de classe em nvel repassam informao para construtores da classe no nvel
Como usar herana mltipla de forma segura?
Slide 165
Slide 166
ilmr
Evitar grafos de hierarquia na forma de diamantes Evita problemas associados a classes bases virtuais seguro combinar herana pblica de interface com herana privada de implementao Rever hierarquia: herana mltipla mesmo a melhor soluo?
Usando C++ para expressar padres de projeto
167
Atividades
Analisar as implementaes fornecidas em C++ com usos dos padres de projeto Adaptador, Decorador, Mediador, Singleton e TemplateMethod. Para cada um deles, descreva Slide 167 1. Qual o problema que est sendo abordado; 2. Que alternativas de implementao so consideradas; 3. Que construes de C++ so relevantes para a implementao; 4. Quais os potenciais problemas ou decincias da implementao; 5. Se as tcnicas indicadas poderiam ser teis na implementao de outros padres.
Slide 168
Concluses
ilmr
169
Slide 169
1. Frederick P. Brooks, Jr. No Silver Bullet: Essence and accidents of software engineering. IEEE Computer, pp.1019, April 1987. Disponvel em http://www.virtualschool.edu/mon/SoftwareEngineering/ BrooksNoSilverBullet.html.
Slide 170
2. Phillip G. Armour. The Five Orders of Ignorance. Communications of the ACM 43(10), pp.1720, October 2000. 3. William H. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J Mowbray. Antipatterns: Refactoring software, architectures, and projects in crisis. John Wiley & Sons, 1998. 4. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of reusable object-oriented software. Addison-Wesley, 1995.
ilmr
Origem dos maiores problemas na programao em C++ Falta de compreenso do paradigma de orientao a objetos Vcios no desenvolvimento de software Problemas no projeto Mal uso dos recursos da linguagem Para o ltimo item, soluo passa por Reconhecer as mensagens implcitas associadas a cada recurso Estar atento s situaes de risco Aplicar solues reconhecidas
Referncias e sugestes de leitura
171
5. Ralph E. Johnson. Frameworks=Components+Patterns. Communications of tha ACM 40(10), pp.3942, October 1997. 6. W. Pree. Design patterns for object-oriented software development. Addison-Wesley, 1995. 7. H. A. Schmid. Framework Design by Systematic Generalization. Building Application Frameworks: Object-Oriented Foundations of Framework Design, Mohamed E. Fayad, Douglas C. Schmidt e Ralph E. Johnson (Eds.). John Wiley & Sons, 1999, Cap. 15, pp.353378. 8. Scott Meyers. Effective C++: 50 specic ways to improve your programs and designs, 2nd edition. Addison-Wesley, 1998.
Slide 171
ilmr
http://www.antipatterns.com/ http://hillside.net/patterns/ http://www.objenv.com/cetus/oo_patterns.html http://www.osdn.org/ http://sourceforge.net/
171

C Advnotes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

C Advnotes

Transféré par

Droits d'auteur :

Formats disponibles

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Programao orientada a objetos: Desenvolvimento avanado em C++

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Solues para o desenvolvimento de projetos

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Por que se investe tanto no desenvolvimento de software?

Dependncia da sociedade em relao aos produtos de software

Busca pela melhor qualidade do software

Uso de software no processo de desenvolvimento de software

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Evoluo do desenvolvimento de software

Disciplina no desenvolvimento de software

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

A promessa da Engenharia de Software

Modelos para processos

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Por que desenvolver software difcil?

Frederick Brooks: No Silver Bullet para construir software

Phillip Armour: software no um produto, mas uma forma de armazenar conhecimento

Como desenvolver bom software?

Balano entre nfase no produto vs. nfase no processo

Porm o produto no o cdigo, mas sim o conhecimento nele embutido P. Armour

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

As cinco ordens de ignorncia

OI-0: falta de ignorncia

OI-1: falta de conhecimento

OI-2: falta de conscincia

OI-3: falta de processo

Ordens de ignorncia e desenvolvimento de software

OI-0: sistema funcionando corretamento

OI-1: variveis so conhecidas

OI-2: onde muitos projetos comeam. . .

OI-3: onde mora o perigo. . .

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

O papel da orientao a objetos

Por si, no a resposta denitiva s nossas preces

Diversas metodologias Diversas linguagens

O desenvolvimento orientado a objetos

Desenvolvimento no comea na codicao Vises da arquitetura do sistema

Diagramas sobre aspectos estticos e dinmicos

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

A programao orientada a objetos

A velha promessa no cumprida. . .

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Reaproveitando experincias no desenvolvimento de software

Boas experincias Padres: solues reconhecidas Ms experincias Antipadres: enganos usuais

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Por que estudar antipadres?

Cinco em cada seis projetos no so considerados de sucesso

Antipadres: soluo para um problema que gera decididamente conseqncias negativas

Antipadres: causas primrias (7 pecados capitais)

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Como usar antipadres

No para caar bruxas A empresa no necessariamente precisa estar livre de antipadres

Antipadres no desenvolvimento de software

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Abstrao para superclasse

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Tipicamente, herana de projeto procedimental (processos vs. dados)

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO

Antipadro: Fluxo de Lava

Antipadro: Decomposio funcional

FACULDADE DE E NGENHARIA E LTRICA E DE C OMPUTAO