C Advnotes PDF

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
Apresentar principais tendncias no desenvolvimento de software;

Slide 2
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++.
ilmr 3
Pblico-alvo
Programadores com conhecimento de C++ e com experincia de

participao em projetos de sistemas de software.
Slide 3
Como voc se descreveria em termos de sua atividade profissional?
Por que desenvolver software parte de sua atividade?
Viso geral
Desenvolvimento de software
Estratgias bsicas
Slide 4 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
ilmr 5
Desenvolvimento
Slide 5
de
software
Por que se investe tanto no desenvolvimento de software?
Dependncia da sociedade em relao aos produtos de software

Atividades cotidianas
Slide 6
Sistemas crticos
Busca pela melhor qualidade do software

Confiabilidade
Uso de software no processo de desenvolvimento de software
ilmr 7
Evoluo do desenvolvimento de software
195060s Software orientado pelo hardware

196070s Software como produto
Slide 7 bibliotecas de software

197080s 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
O foco na qualidade em desenvolvimento de software depende da

Slide 8 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
ilmr 9
A promessa da Engenharia de Software
Qualidade de software
Slide 9 Ferramentas
Mtodos
Processo
Modelos para processos
Combinaes e variaes em torno de

Anlise: capturar informao sobre o domnio do problema e construir
modelos operacionais para o sistema
Slide 10 Projeto: transformar modelos da anlise em modelos de elementos
computacionais
Codificao: implementar os elementos computacionais do sistema
Teste: encontrar erros na implementao
Manuteno: tudo de novo a cada mudana
Resultado: cdigo (o produto final)
ilmr 11
Por que desenvolver software difcil?
Frederick Brooks: No Silver Bullet para construir software

Conjunto de construes conceituais
Complexo e no-linear
Slide 11
Sujeito a mudanas e modificaes
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

Slide 12 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
ilmr 13
As cinco ordens de ignorncia
OI-0: falta de ignorncia

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

no sabe alguma coisa e sabe identificar este fato
Slide 13
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
Slide 14 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
ilmr 15
O papel da orientao a objetos
Por si, no a resposta definitiva s nossas preces

Porm, no momento a melhor maneira de expressar nosso conhecimento
sobre software
Slide 15
Diversas metodologias
Diversas linguagens
UML
Java
...
C++
O desenvolvimento orientado a objetos
Desenvolvimento no comea na codificao

Vises da arquitetura do sistema
Slide 16 Sistema: coleo de subsistemas
Subsistema: agrupamento de elementos
Modelos
Abstrao de um sistema semanticamente fechada
Diagramas sobre aspectos estticos e dinmicos

Apresentao grfica de um conjunto de elementos
ilmr 17
A programao orientada a objetos
Transio dos modelos de projeto para o cdigo facilitada pelo

vocabulrio comum
Slide 17 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 definies
A velha promessa no cumprida. . .
Com a orientao a objetos, voc poder reaproveitar cdigo j

Slide 18 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.
ilmr 19
Como desenvolver software que pode ser reaproveitado,

sem cair nas velhas armadilhas do desenvolvimento de
Slide 19
software?
Reaproveitando experincias no desenvolvimento de

software
Slide 20 Boas experincias

Padres: solues reconhecidas
Ms experincias
Antipadres: enganos usuais
ilmr 21
Por que estudar antipadres?
Cinco em cada seis projetos no so considerados de sucesso

Um tero de projetos cancelados
Recursos de custo e tempo inadequados
Resultados pouco flexveis ou extensveis
Slide 21
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)
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 23
Como usar antipadres
No para caar bruxas

A empresa no necessariamente precisa estar livre de antipadres
enderear problemas crnicos
Propsito desenvolver e implementar estratgias para resolver os

Slide 23
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
Slide 24
No desenvolvimento de software, tcnicas bsicas de refabricao de
programas incluem:
Abstrao para superclasse
Eliminao condicional
Abstrao agregada
ilmr 25
Abstrao para superclasse
Aplicvel a duas ou mais classes similares

Slide 25 1. Transformar assinaturas de mtodos similares em assinaturas
comuns
2. Criar superclasse abstrata
3. Modificar 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
Slide 26
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
ilmr 27
Abstrao agregada
Reorganiza relacionamentos de classes para melhorar estrutura e

extensibilidade
Slide 27 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!
Forma geral: Uma classe monopoliza o processamento, outras classes

encapsulam dados
Tipicamente, herana de projeto procedimental (processos vs. 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: identificar atributos e operaes relacionadas de acordo com

contratos coesos, migrando essas colees de funcionalidades para seus
lares naturais; revisar associaes
ilmr 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
Sintomas e conseqncias: segmentos complexos sem documentao,
Slide 29
blocos de cdigo comentados sem explicao; se no removido,
continua a proliferar pelo sistema e outros desenvolvedores
(apressados, intimidados) vo trabalhando ao redor dos fluxos de lava,
gerando um sistema impossvel de se entender ou documentar
Soluo: no desenvolvimento, ter uma arquitetura slida (interfaces
estveis, bem definidas 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: definir 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 proficiente
Sintomas e conseqncias: Mesmas ferramentas e produtos usadas em
Slide 32
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 filosofia 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

Sintomas e conseqncias: Mtodos muito orientados a processos, com o
Slide 33 fluxo 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 eficincia: 100000 linhas de cdigo em duas semanas!
Forma geral: Presena de vrios segmentos similares de cdigo

Slide 34 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 Ingresso do lobo: suportamos padro X (mas interfaces so proprietrias)
Arquitetura por implicao: j fizemos sistemas assim antes

Projeto por comit: camelo (s.m.): cavalo projetado por um comit
Canivete suo: tudo que pensamos foi includo no projeto
Reinventar a roda: nosso problema diferente dos outros
Antipadres de gerncia de projetos de software
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 37
Padres de projeto
Slide 37
Onde esto os caminhos para as boas solues?
O que um padro de projeto?
Solues para problemas especficos em projeto de software orientado

a objetos
Slide 38 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
ilmr 39
Por que reusar projetos ao invs de cdigo?
Pode ser aplicado em mais contextos

mais compartilhvel
Ocorre mais cedo no processo de desenvolvimento

Slide 39
maior impacto
Projeto
Cdigo
Problemas de projeto abordados por padres
Identificao de objetos: auxiliam a identificar abstraes recorrentes de

forma genrica
Granularidade de objetos: indicam como representar subsistemas como
Slide 40 objetos ou suportar vrios objetos pequenos
Especificao de interfaces: indicam os conceitos chaves que devem (ou
no devem) estar na interface de um objeto, assim como
relacionamentos entre interfaces
Especificao de implementao: indicam que classes devem ser
abstratas (puras) ou concretas, embora a implementao deva sempre
favorecer referncias a interfaces
ilmr 41
Padres, orientao a objetos e reuso
Objetos, interfaces, classes e herana no garantem reuso
Abordagens de reuso na orientao a objetos:

Herana de classes: reuso caixa-branca, definio esttica (tempo de
Slide 41
compilao), simples, mas expe superclasse
Composio de objetos: reuso caixa-preta, definio 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 Window Rectangle

rec ta ng le
area( ) re tu rn wid th*h e igh t area( ) area( )
Slide 42 width width

height height
re tu rn rec ta ng le > a rea ()
Window
ilmr 43
Agregao vs associao
Agregao: objeto composto por outros objetos ou um objeto parte

de outro objeto
Slide 43 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

modificveis: Criar objetos especificando explicitamente
sua classe
Slide 44
Assume compromisso com uma implementao em particular, podendo
comprometer futuras modificaes
Padres de projeto associados: Mtodo Fbrica, Fbrica Abstrata,

Prottipo
ilmr 45
Padro: Mtodo Fbrica
Objetivo: Definir 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
Slide 45 ponto do cdigo no sabe que tipo de objeto ser criado
Conseqncias: isola classes especficas 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
Estrutura:
Criador
metodoFabrica()
Produto 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 especificar suas classes concretas
Motivao: trabalhar com uma interface no cdigo que seja comum para
distintas alternativas de implementao daquele conjunto de
Slide 47 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
Estrutura:
Cliente Fbr icaAbs tr ata
P r odutoAAbs tr ato criaProdutoA()
criaProdutoB()
ProdutoA1 ProdutoA2
F bricaConcreta2 F bricaConcreta1
Slide 48
criaProdu toA() criaProdu toA()
P r odutoBAbs tr ato criaProdu toB() criaProdu toB()
ProdutoB1 ProdutoB2
ilmr 49
Padro: Prottipo
Objetivo: Especificar 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
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
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 prototype
Prototipo
clone()
operacao()
Slide 50
p = prototype > clone() PrototipoConcreto1 PrototipoConcreto2
clone() clone()
ilmr 51

modificveis: Estar dependente de operaes especficas
Slide 51
Assume compromisso com uma forma de atender a uma requisio;
seria melhor no ter essa definio amarrada ao cdigo
Padres de projeto associados: Cadeia de responsabilidade, Comando
Padro: Cadeia de responsabilidade
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
Slide 52 requisio passada por eles at que um dos objetos a atenda.
Conseqncias: reduz acoplamento e obtm maior flexibilidade 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 53
Estrutura:
Cliente Hand ler

successor
hand leR equest( )
Slide 53
ConcreteHandler1 ConcreteHandler2
handleRequest( ) handleRequest( )
Padro: Comando
Objetivo: encapsular uma requisio como um objeto, permitindo

Slide 54 parametrizar clientes com diferentes solicitaes, enfileirar 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.
ilmr 55
Estrutura:
Invoker Command
Client
ex ecute( )
Slide 55
receiver
Receiver ConcreteCommand
action( ) ex ecute( ) receiver > action( );
state

modificveis: Depender da plataforma de hardware e
software
Slide 56
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
ilmr 57
Padro: Ponte
Objetivo: desacoplar uma abstrao de sua implementao de forma que

os dois possam variar independentemente.
Slide 57
Motivao: uma forma de evitar o acoplamento definitivo entre abstrao e
implementao que se d atravs de herana
Conseqncias: desacopla interface e implementao, melhora
extensibilidade e esconde detalhes de implementao de clientes.
Estrutura:
Client
impl Implementor
Abstraction
operation( ) operationImp( )
Slide 58 impl > operationImpl( );
RefinedAbstraction ConcreteImplementorA
usesOperation( ) operationImpl( )
ilmr 59

modificveis: Depender de representaes ou
implementaes de objetos
Slide 59
Clientes que sabem como um objeto representado, armazenado,
localizado ou implementado podem ter que sofrer modificaes quando
o objeto muda.
Padres de projeto associados: Fbrica abstrata, Memento, Proxy
Padro: Memento
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 61
Estrutura:
memento
Originator M emento Caretaker
setMemento(Memento m) g etS tate()

createMemento() setS tate()
Slide 61
state state
m = new Memento(); state = m>getState();

m>setState(state);
return m;
Padro: Proxy
Objetivo: Oferecer um surrogate para outro objeto para controlar o acesso

a ele.
Aplicabilidade: Sempre que for necessrio ter uma referncia para um
Slide 62 objeto que seja mais verstil ou sofisticada 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 ...
real
R ealSub ject P roxy
...
request( ) request( ) real>request( );
...

modificveis: Depender de algoritmos
Slide 64
Algoritmos podem ser estendidos, otimizados ou substitudos durante
desenvolvimento ou reuso; se objeto depender de um algoritmo
especificamente, tambm dever ser alterado nesses casos
Padres de projeto associados: Estratgia, Mtodo Gabarito, Iterador
ilmr 65
Padro: Estratgia
Objetivo: definir uma famlia de algoritmos, encapsul-los e torn-los

intercambiveis, permitindo que o algoritmo varie independentemente
de seus clientes
Aplicabilidade: usar quando classes relacionadas diferem apenas em seu
Slide 65
comportamento; quando diferentes variantes de um algoritmo so
necessrias; quando se deseja encapsular estruturas de dados
complexas, especficas do algoritmo; quando a classe define 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
algorithmInterface( ) algorithmInterface( )
ilmr 67
Padro: Mtodo Gabarito
Objetivo: definir 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 redefinidas 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 redefinidas) ou operaes abstratas (tem que ser
redefinidas); leva ao Princpio de Holywood (superclasse invoca
mtodos de classe derivada e no ao contrrio)
Estrutura:
AbstractClass
templateMethod( ) ...
primitiveOperation1( ) primitiveOperation1( );
primitiveOperation2( ) ...
primitiveOperation2( );
Slide 68 ...
ConcreteClass
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: simplifica a interface do agregado; pode ter mais de uma
varredura sobre o mesmo agregado em um dado momento
Estrutura:
Iterator
Agg reg ate Cliente
first( )
createIterator( )
next( )
current( )
Slide 70 isDone( )
ConcreteAggregate ConcreteIterator
createIterator( )
ilmr 71

modificveis: Acoplamento forte
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
Objetivo: oferecer uma interface unificada para um conjunto de interfaces

em um subsistema
Slide 72 Motivao: definir 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 73
Estrutura:
F acade
Slide 73
Padro: Mediador
Objetivo: definir 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; simplifica protocolos entre

objetos; porm, mediador centraliza controle, tornando-se
eventualmente um elemento complexo e de difcil reuso
ilmr 75
Estrutura:
m ediator
Mediator Colleag ue
Slide 75
ConcreteMediator ConcreteColleague1 ConcreteColleague2
Padro: Observador
Objetivo: definir uma dependncia de um objeto para muitos de forma que,

quando um objeto muda de estado, todos os seus dependentes so
notificados 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 notificar outros sem assumir
nenhum conhecimento sobre quais so esses outros objetos
ilmr 77
Estrutura:
Subject observers
Observer
attach(Observer)
update( )
detach(Observer)
notify( )
for all o in observers

o>update()
Slide 77
ConcreteSubject subject ConcreteObserv er
getS tate( ) u pdate( )

setS tate( )
observerS tate
subjectS tate
return observerState =
subjectState 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 modifique seu comportamento quando seu
estado interno muda (padro de comportamento);
ilmr 79
Interpretador: define 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 eficiente (padro estrutural);
Slide 79
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);
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
menos abstratos que padres
tipicamente contm vrios padres
ilmr 81
Frameworks e reuso
Reuso de projeto
um framework define um esqueleto de aplicao que pode ser adaptado por
um desenvolvedor de aplicao
Slide 81
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
Modularidade: detalhes de implementao so encapsulados por trs de

interfaces estveis
Reusabilidade: definem componentes genricos associados s interfaces
Slide 82 estveis que podem ser reutilizados para criar novas aplicaes
Extensabilidade: definem pontos de adaptao e extenso nas interfaces
estveis (pontos variveis, mtodos hook)
Inverso de controle: framework define seqncia de invocao da
aplicao
Princpio de Hollywood
ilmr 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 definir
classes que estendem as classes abstratas do framework e redefinir
Slide 83 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 especficas (como
caixa-branca)
Pontos de adaptao no framework
F ram ework F ram ework
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
Frameworks caixa-branca so mais simples de se projetar e desenvolver

Slide 86 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
ilmr 87
Desenvolvimento de software centrado em frameworks
Slide 87 Trs fases principais:

1. Desenvolvimento do framework
2. Uso do framework
3. Manuteno do framework
Tarefas para o desenvolvimento de frameworks
1. identificar domnio especfico de aplicao do framework

2. determinar os principais casos de uso suportados e atores interagindo
com o framework
3. determinar padres/solues para auxiliar desenvolvimento do
Slide 88
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 89
Desenvolvimento de framework baseado em pontos

variveis
Slide 89 Anlise do domnio identifica pontos variveis

quais aspectos do framework diferem entre aplicaes?
qual o grau de flexibilidade desejado?
o comportamento flexvel precisa ser alterado durante o
funcionamento da aplicao?
Ciclo de desenvolvimento baseado em pontos variveis
Especialista Desenv olv edor

Slide 90 do domnio M etapadres
identificar identificar (R e)projeto Adaptao pontos

S
objetos e pontos do do variveis
classes variveis fram ework fram ework satisfazem ?
ilmr 91
Metapadres
Estabelecem padres de relao entre classes genricas (template

classes) e classes componentes (hook classes)
Slide 91 Classes genricas possuem os mtodos gabaritos, que definem
comportamento abstrato, fluxo 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 unificao
U nificao U nificao
Slide 92 U nificao
recursiva 1: 1 recursiva 1: n
*
thRef thList
TH TH
TH
ilmr 93
Metapadres de conexo
Conexo 1: 1 Conexo 1: n Conexo Conexo

recursiva 1: 1 recursiva 1: n
Slide 93
T T H H
*
hRef hList
* hRef hList
H H T T
Desenvolvimento de framework baseado em

generalizao sistemtica
Criao de um modelo de aplicao no domnio

Slide 94 Anlise de alto nvel dos pontos variveis
Para cada ponto varivel detectado
anlise e especificao detalhada
projeto de alto nvel
transformao do modelo de classes por generalizao com o subsistema de
ponto varivel
ilmr 95
Subsistemas de ponto varivel (hot spots)
Outra forma de estabelecer os padres bsicos de relao entre as

classes genricas e suas concretizaes
Slide 95
Variabilidade obtida por meio de uma referncia polimrfica, 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
Slide 96
C oncreta1 C oncreta2
ilmr 97
Subsistema de ponto varivel recursivo 1:1
1
cliente Bas e
Slide 97
Subsistema de ponto varivel recursivo 1:n
*
cliente Bas e
Slide 98
ilmr 99
Relao entre padres, metapadres e subsistemas de

ponto varivel
Subsistema de ponto Metapadro Padro de projeto

varivel
Slide 99 no recusivo unificao, conexo 1:1, fbrica abstrata, mtodo fbrica,
conexo 1:n prottipo, ponte, comando, itera-
dor, observador, estratgia, m-
todo gabarito, construtor, adapta-
dor, mediador, estado, visitante
recursivo 1:1 conexo recursiva 1:1, cadeia de responsabilidade, deco-
unificao recursiva 1:1 rador
recursivo 1:n conexo recursiva 1:n, composto, interpretador
unificao recursiva 1:n
Uso do framework
Quando ocorre o desenvolvimento de aplicaes

Instanciao do framework
Sucesso dependente em grande parte da boa documentao sobre o
Slide 100
framework
Identificao dos pontos de adaptao
Padres utilizados
Exemplos
Aprender a usar um framework requer investimento de tempo e
dinheiro
ilmr 101
Manuteno de frameworks
Desenvolvimento de aplicaes aumenta reusabilidade do framework

maior disponibilidade de classes concretas (reuso caixa-preta)
Slide 101 identificao de deficincias 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
Classificao de frameworks pelo escopo de uso
Infra-estrutura: framework simplifica o desenvolvimento da

infra-estrutura de sistemas de forma porttil e eficiente; tipicamente de
Slide 102 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 finais
ilmr 103
Potenciais problemas na integrao de frameworks
Foco no desenvolvimento dos frameworks est na extenso das

funcionalidades, no na integrao com outros frameworks
Alguns frameworks podem assumir que tm controle completo sobre o
Slide 103
fluxo 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
Coeso do framework: quo amarrada est a conexo de uma classe do

framework s demais?
Cobertura do domnio: quo bem especificado e isolado est o domnio
Slide 104 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 modificaes e
adaptaes no cdigo; importante ter uma abordagem open source
Falta de padres: ainda no h padres voltados para o desenvolvimento
de frameworks
ilmr 105
Estratgias para integrao de frameworks
Usar threads de execuo independentes para cada framework

Usar padro Adaptador para estabelecer integrao com cdigo legado
Alterar cdigo do framework
Slide 105
No desenvolvimento:
Tornar explcitas e bem documentadas as decises relativas arquitetura do
framework
Construir o framework em blocos independentes
Estabelecer no framework previses para configurao, mediao e
adaptao, atravs do uso de padres
Aplicando as tcnicas de reuso na programao C++
Slide 106
Herana, composio, templates
ilmr 107
O conceito da herana
Princpio da substituio de Liskov

Slide 107 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)
Definio 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
Slide 108 Implementando hierarquias IS-A
Lidando com excees nas hierarquias
Herana de interfaces vs herana de implementaes
separao de interface e implementao
redefinies de mtodos
ilmr 109
C++ e hierarquias IS-A
Atravs da derivao public

Slide 109 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;
Slide 110 dance(p);
dance(e);
estude(p); // oops
estude(e);
ilmr 111
Herana pblica vs. herana privada
Derivao usando private no define uma hierarquia do tipo IS-A

como todos os membros da superclasse, pblicos ou protegidos,
Slide 111
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;
Slide 112 Estudante e;
dance(p);
dance(e); // oops
estude(p); // oops
estude(e);
ilmr 113
Lidando com pingins voadores
Pssaros podem voar, pingins so pssaros. . .

class Passaro {
Slide 113 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 {

Slide 114 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++
ilmr 115
Revendo a hierarquia de classes
Se no houver um mtodo voe definido para pingins, compilao j

detectar o erro
Slide 115 class Passaro { ... };
class PassaroVoador: public Passaro (
public: virtual void voe(); ...
};
class PassaroNaoVoador: public Passaro { ... };
class Pinguim: public PassaroNaoVoador { ... };
Potenciais problemas na definio de hierarquias de

classes por herana
Uso de intuio ou bom senso pode levar a hierarquias falhas

Slide 116
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
ilmr 117
Interfaces e implementaes
Separao entre a especificao de uma interface e sua implementao

Slide 117 essencial na boa programao orientada a objetos
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;
Slide 118 string dataNascimento() const;
string endereco() const;
string nacionalidade() const;
private:
string name_;
Data birthday_;
Endereco address_;
Pais nation_;
};
ilmr 119
Destrutor virtual
Por qu?
class Base { public: ~Base(); ... };
class Derivada: public Base { public: ~Derivada(); ... };
Slide 119 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 definies
Classe Pessoa usa outras classes na definio de seus atributos

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

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

sem construtores
Slide 124 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
ilmr 125
Exemplo de protocolo C++
class Pessoa {
public:
Slide 125 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
Objetos sero de classes derivadas do protocolo

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

protocolo
class Pessoa {
public:
Slide 127 ...
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

Slide 128 classe derivada?
Apenas sua interface (declarao);
A interface e a implementao, porm permitindo que classe derivada
defina nova implementao (especializaes);
A interface e a implementao, sem permitir que a classe derivada defina
nova implementao (aspecto invariante).
ilmr 129
Trs tipos de mtodos
Para a classe abstrata Shape,

class Shape {
public:
Slide 129 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
Slide 130 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();
ilmr 131
Herana de interface com implementao padro
Obtida com mtodos virtuais normais

Classe derivada pode optar entre usar a implementao padro
Slide 131
oferecida pela superclasse ou definir a prpria implementao,
especializada
Potencial problema de manuteno
Se a hierarquia crescer (novas classes derivadas) e o padro no mais for
aplicvel
No h diferena entre pilotar um Avio ModeloA ou um Avio ModeloB;

outros poderiam ser diferentes:
class Aviao {
public:
Slide 132 virtual void voePara(string& destino);
...
};
class ModeloA : public Aviao { ... };
class ModeloB : public Aviao ( ... };
ilmr 133
J pilotar o novo Avio ModeloC diferente. . .

class ModeloC : public Aviao { ... //oops};
Aviao eqp = new ModeloC;
Slide 133 eqp->voePara("JFK"); // desastre
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:
Slide 134 virtual void voePara(string& dest) = 0;
...
private:
void vaiPorMim(string& dest);
};
void ModeloA::voePara(string& dest) {
vaiPorMim(dest);
}
ilmr 135
Separando a interface da implementao padro (2)
Alternativamente, pode usar definio para funo virtual pura:

class Aviao {
public:
virtual void voePara(string& dest) = 0;
Slide 135 ...
};
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

Slide 136
Situao obtida com uso das funes no-virtuais
Define interface e implementao mandatria
Mtodo no-virtual nunca deve ser redefinido em classes derivadas
ilmr 137
Nunca redefinir mtodos no-virtuais
class B { public: void mf(); ... };

class D: public B { ... };
Slide 137 D x;
B *pB = &x; pB->mf();
D *pD = &x; pD->mf();
Se D redefine mf, as duas invocaes de mf tero comportamento
diferente
Porque no redefinir mtodos no-virtuais
Mtodos no virtuais so ligados em tempo de compilao

Mesmo que atravs de ponteiros, a implementao utilizada ser a do
Slide 138 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 definido na classe derivada com valores padres
definidos na superclasse
concluso: no devem ser redefinidos
ilmr 139
Trabalhando com composio
Para modelar expresses do tipo tem um (objeto de outra classe) ou

implementado usando (outro tipo de objeto)
Slide 139 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
Slide 140
um conjunto no uma lista
conjuntos no podem ter elementos duplicados, listas podem
herana pblica no uma boa opo
pode definir atributo usando list da STL
ilmr 141
Definio da classe Set:

template<class T>
class Set {
public:
bool member(const T& item) const;
Slide 141 void insert(const T& item);
void remove(const T& item);
int cardinality( ) const;
private:
list<T> rep;
};
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);
}
Slide 142
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();
}
ilmr 143
Herana ou templates
Na definio de um conjunto de classes com pequenas diferenas entre

si, qual mecanismo usar?
herana: fatorar parte comum em superclasse (abstrata), derivar as
Slide 143 classes concretas e em cada uma definir a especializao da classe
template: definir o cdigo para a classe genrica em termos de um tipo
parametrizado e instanciar, para cada tipo desejado, uma verso da
definio 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 {
Slide 144 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);
};
ilmr 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;
Slide 145 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
Ponteiros genricos (void*) oferecem outra alternativa que permite

ter o mesmo comportamento para diferentes tipos de objetos
Slide 146
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
ilmr 147
Classe pilha genrica (opo 1):

class GenericStack {
public:
GenericStack();
~GenericStack();
void push(void *obj);
void *pop();
bool empty() const;
Slide 147 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); };
Classe para converso de tipos (opo 1):

class IntStack {
public:
void push(int *ip) {s.push(ip);}
Slide 148 int *pop() {return static_cast<int *>(s.pop());}
bool empty() const { return s.empty();}
private:
GenericStack s;
};
ilmr 149
Comentrios sobre essa implementao
No h custo adicional no uso de IntStack

Slide 149 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
Classe pilha genrica (opo 2):

class GenericStack {
protected:
GenericStack();
~GenericStack();
void push(void *obj);
void *pop();
bool empty() const;
Slide 150 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); };
ilmr 151
Classe para converso de tipos (opo 2):

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

interface):
template<class T>
class Stack: private GenericStack {
Slide 152 public:
void push(T *op) {GenericStack::push(op);}
T *pop() {return static_cast<T*>(GenericStack::pop());}
bool empty() const { return GenericStack::empty();}
};
ilmr 153
Herana mltipla
No h uma posio clara na comunidade de orientao a objetos sobre

Slide 153 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 Base2
faz(): int faz():void

Slide 154
D erivada
ilmr 155
Ambigidade potencial (C++)
class Base1 { class Base2 {

public: public:
int faz(); void faz();
Slide 155 }; };
class Derivada: public Base1, public Base2 {

... // sem faz()
};
Derivada d;
d.faz(); // erro de compilao
Restringir acesso no resolve o problema:

class Base1 { class Base2 {
public: private:
int faz(); void faz();
}; };
Slide 156
... // sem faz()
};
Derivada d;
int i = d.faz(); // continua erro de compilao
ilmr 157
Por que compilador no leva em conta as especificaes de acesso?

Porque modificaes na visibilidade de membros das classes no
deveria modificar o significado de programas
Slide 157 Se a abordagem anterior resolvesse o problema, apenas modificao
na visibilidade mudaria o comportamento do programa
sem modificar invocao ou corpo dos mtodos
Para resolver ambigidade, apenas atravs da qualificao dos membros

(referncias explcitas classe base):
d.Base1::faz();
d.Base2::faz();
Slide 158 Se mtodos fossem virtuais, no teria como explorar redefinies

mesmo que objeto fosse de uma classe derivada da base, a
qualificao faz com que o mtodo invocado seja exatamente o
especificado.
ilmr 159
E se dois mtodos, com os mesmos tipos de argumentos, fossem virtuais e a

classe derivada quisesse redefinir os dois?
no h como fazer diretamente
Slide 159 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(); }
};
Slide 160
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
ilmr 161
Mltiplas ocorrncias da classe base
C om um
Slide 161
Base1 Base2
D erivada
Tipicamente, classe comum uma classe base virtual:

class Comum { ... };
class Base1: virtual public Comum { ... };
class Derivada: public Base1, public Base2 { ... };
Slide 162
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. . .
ilmr 163
Outros problemas na herana mltipla
Passagem de argumentos para construtor de classe base virtual:

Em herana simples, sem bases virtuais, construtores de classe em

Slide 163 nvel repassam informao para construtores da classe no nvel
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 Base2: virtual public Comum {
public: virtual void f(); ... };
class Derivada: public Base1, public Base2 { ... };
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)
ilmr 165
Como usar herana mltipla de forma segura?
Evitar grafos de hierarquia na forma de diamantes

Slide 165 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

Slide 166
ilmr 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 deficincias da implementao;
5. Se as tcnicas indicadas poderiam ser teis na implementao de outros
padres.
Slide 168 Concluses
ilmr 169
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
Slide 169
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
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 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.
Slide 171
8. Scott Meyers. Effective C++: 50 specific ways to improve your programs and
designs, 2nd edition. Addison-Wesley, 1998.
http://www.antipatterns.com/
http://hillside.net/patterns/
http://www.objenv.com/cetus/oo_patterns.html
http://www.osdn.org/
http://sourceforge.net/
ilmr 171

C Advnotes PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

C Advnotes PDF

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE E NGENHARIA

Programao orientada a objetos:

Ivan Luiz Marques Ricarte

Apresentar principais tendncias no desenvolvimento de software;

Como aplicar esses conceitos para o desenvolvimento de software

Programadores com conhecimento de C++ e com experincia de

Como voc se descreveria em termos de sua atividade profissional?

Por que desenvolver software parte de sua atividade?

Slide 4 Tendncias atuais

Solues para o desenvolvimento de projetos

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

Evoluo do desenvolvimento de software

195060s Software orientado pelo hardware

Slide 7 bibliotecas de software

Disciplina no desenvolvimento de software

O foco na qualidade em desenvolvimento de software depende da

A promessa da Engenharia de Software

Modelos para processos

Combinaes e variaes em torno de

Por que desenvolver software difcil?

Frederick Brooks: No Silver Bullet para construir software

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

Como desenvolver bom software?

Balano entre nfase no produto vs. nfase no processo

Porm o produto no o cdigo, mas sim o conhecimento nele

As cinco ordens de ignorncia

OI-0: falta de ignorncia

OI-1: falta de conhecimento

OI-3: falta de processo

Ordens de ignorncia e desenvolvimento de software

OI-0: sistema funcionando corretamento

Slide 14 OI-1: variveis so conhecidas

OI-2: onde muitos projetos comeam. . .

OI-3: onde mora o perigo. . .

O papel da orientao a objetos

Por si, no a resposta definitiva s nossas preces

O desenvolvimento orientado a objetos

Desenvolvimento no comea na codificao

Diagramas sobre aspectos estticos e dinmicos

A programao orientada a objetos

Transio dos modelos de projeto para o cdigo facilitada pelo

A velha promessa no cumprida. . .

Com a orientao a objetos, voc poder reaproveitar cdigo j

Como desenvolver software que pode ser reaproveitado,

Reaproveitando experincias no desenvolvimento de

Slide 20 Boas experincias

Por que estudar antipadres?

Cinco em cada seis projetos no so considerados de sucesso

Antipadres: causas primrias (7 pecados capitais)

Pressa: quando o deadline se aproxima, qualquer coisa que parece

Preguia: tomar decises pobres usando a resposta fcil

Como usar antipadres

No para caar bruxas

Propsito desenvolver e implementar estratgias para resolver os

Antipadres no desenvolvimento de software

No basta apontar onde est o problema, mas preciso indicar

Abstrao para superclasse

Aplicvel a duas ou mais classes similares

Estrutura e comportamento de uma classe muito dependente de um

Reorganiza relacionamentos de classes para melhorar estrutura e