Técnicas de Programação 1 - Programação Orientada a Objetos (Fernando Albuquerque)

Prévia do material em texto

1 
1 
TÉCNICAS DE PROGRAMAÇÃO 1 
Fernando Albuquerque 
Tópicos 
 Decomposição de problemas usando classes e objetos. 
 Técnicas de desenho e programação orientada a objetos. 
 Reuso com herança e composição de classes. 
 Polimorfismo por subtipos/parametrizado. 
 Tratamento de exceções. 
 Tópicos especiais (distribuição, concorrência). 
 Técnicas avançadas de modularização. 
 
 
2 
2 
CONCEITOS DE BASE 
3 
4 
Introdução 
 Decomposição de um sistema: 
1. Sistema 
2. Subsistema 
3. Programa 
4. Módulo 
5. Classe 
6. Função 
7. Bloco de código 
8. Linha de código 
Complexidade decrescente. 
3 
5 
Introdução 
 Sistema: 
• Composto por um conjunto de elementos. 
• Elementos são conectados. 
• Elementos conectados compõem um todo. 
• Um sistema pode ser descrito por um ou mais modelos. 
• Sistema computacional composto por hardware e 
software. 
• Sistema computacional processa dados com um objetivo 
bem definido. 
6 
Introdução 
 Subsistema: 
• Um sistema que é parte de um outro sistema. 
• Possibilita a decomposição de sistemas complexos.  Programa: 
• Lista organizada de instruções passo-a-passo. 
• Escrito para uma arquitetura de computador. 
• Escrito em uma linguagem de programação. 
• Faz o computador se comportar de uma certa forma. 
• É composto por um ou mais módulos. 
 
 
4 
7 
Introdução 
 Módulo: 
• Elemento auto-contido de um programa. 
• Implementa conceitos lógicos bem delimitados. 
• Tem interfaces bem definidas. 
• Agrupa partes de programas e estruturas de dados. 
• É uma unidade de compilação independente. 
• Pode ser independentemente desenvolvido. 
• É combinado com outros módulos na ligação (link). 
• É composto por um ou mais arquivos. 
• Pode conter várias rotinas e classes. 
• Promove o encapsulamento. 
8 
Introdução 
 Interface: 
• Expressa elementos providos e requeridos. 
• Elementos em uma interface são visíveis externamente. 
• Implementação contém código que realiza a interface. 
• Estabelece-se um relacionamento entre cliente e servidor. 
• Uma interface possui sintaxe. 
• A sintaxe são as regras e restrições aplicáveis. 
• Uma interface possui semântica. 
• Semântica é o significado da interface.. 
• Um protocolo de uso determina como usar uma interface. 
5 
9 
Introdução 
Programas 
Interfaces 
Módulos 
10 
Introdução 
 Encapsulamento: 
• Aspectos internos escondidos do mundo externo. 
• Maior controle sobre os efeitos das manutenções. 
• Unidades podem ser alteradas sem afetar seus usuários. 
• Os dados são escondidos dentro das unidades. 
• Os acessos aos dados ocorrem via códigos apropriados. 
 
 
6 
11 
Introdução 
 
 
 A decomposição dos módulos em funções apresenta 
 alguns inconvenientes: dados e códigos são 
 fracamente acoplados, isso pode dificultar a 
 construção e a manutenção do software. 
12 
Introdução 
MÓDULO 
variáveis globais 
função ( ) { 
 variáveis locais 
 código 
} 
função ( ) { 
 variáveis locais 
 código 
} 
7 
13 
Introdução 
VARIÁVEIS GLOBAIS 
Função 1 ( ) { 
 variáveis locais 
 código 
} 
Função N ( ) { 
 variáveis locais 
 código 
} 
As variáveis 
não estão 
encapsuladas 
14 
Introdução 
 
 A orientação a objetos existe há décadas. 
 É considerado um paradigma fundamental 
 no desenvolvimento de softwares. 
 
 
 Softwares desenvolvidos segundo a orientação 
 os módulos são decompostos de tal modo 
 que variáveis e códigos relacionados são mantidos 
 acoplados. 
 
8 
15 
Introdução 
MÓDULO 
VARIÁVEIS 
função ( ) { 
 variáveis locais 
 código 
} 
função ( ) { 
 variáveis locais 
 código 
} 
VARIÁVEIS 
função ( ) { 
 variáveis locais 
 código 
} 
função ( ) { 
 variáveis locais 
 código 
} 
16 
Classes 
 Introdução: 
• Padrões a partir dos quais objetos são criados 
• Especificam comportamento comum aos objetos 
• Descrevem a estrutura de um objeto 
• Objetos de uma mesma classe são idênticos 
• Contém a declaração de atributos e métodos  Responsabilidades de uma classe: 
• Comportamento estático. 
• Comportamento dinâmico. 
9 
17 
Classes 
18 
Classes 
 Atributos: 
• Definem o comportamento estático das instâncias. 
• Apresentam nome e valor. 
• Tem os seus valores restritos à uma faixa. 
• Podem ter valores default iniciais. 
• Podem ter valores fixos ou variáveis. 
• Podem ter valores diferentes para cada instância. 
• Podem ter valores iguais para cada instância. 
10 
19 
Classes 
 Métodos: 
• Definem o comportamento dinâmico de uma classe. 
• Controlam o acesso aos atributos. 
• Atributos são encapsulados. 
• Se diz que os métodos são invocados. 
• Métodos podem ser públicos ou privados. 
• Métodos privados são de uso interno. 
• Métodos públicos definem serviços. 
 
20 
Classes 
VARIÁVEIS 
Método 1 ( ) { 
 variáveis locais 
 código 
} 
Método N ( ) { 
 variáveis locais 
 código 
} 
As variáveis 
estão 
encapsuladas 
11 
21 
Classes 
 Erros comuns: 
• Classes que modificam atributos de outras classes. 
• Classes com muitas responsabilidades. 
• Classes sem responsabilidades. 
• Classes com responsabilidades não utilizadas. 
• Nomes que levam à uma incorreta interpretação. 
• Classes com responsabilidades não relacionadas. 
• Uso não apropriado de herança. 
• Responsabilidades replicadas em classes. 
22 
Classes 
 Recomendações quanto aos métodos: 
• Implementar o código visando facilitar o entendimento. 
• Usar nomes de métodos e atributos significativos. 
• Evitar abreviações confusas. 
• Realizar uma atividade claramente definida. 
• Métodos devem ser pequenos. 
• Centralizar código comum. 
• Centralizar métodos comuns e herdar. 
• Esconder a estrutura interna de uma classe. 
• Esconder as estruturas de dados usadas pelos métodos. 
• Classificar os métodos como públicos ou privados. 
 
 
12 
23 
Classes 
 Métodos abstratos: 
• Compostos por uma assinatura sem implementação. 
• Classes com métodos abstratos são abstratas. 
• Não podem haver instâncias de uma classe abstrata. 
• Sub-classes podem prover a implementação. 
• Sub-classes sem implementação são abstratas. 
24 
Objetos 
 Introdução: 
• São instâncias das classes. 
• Classes descrevem estruturas das instâncias. 
• Podem existir múltiplos objetos de mesma classe. 
• Estado do objeto escondido do mundo exterior. 
• Estado definido pelas operações anteriormente executadas. 
• Métodos determinam a interface com o objeto. 
• A um objeto tem-se associado um identificador (uoid). 
13 
25 
Objetos 
VARIÁVEIS 1 
Método 1 ( ) { 
 variáveis locais 
 código 
} 
Método N ( ) { 
 variáveis locais 
 código 
} 
VARIÁVEIS 2 Objetos 
26 
Objetos 
As informações em um sistema orientado a 
objetos são armazenadas dentro de objetos e são 
manipuladas quando o objeto é ordenado 
a executar uma ação. 
14 
27 
Interações entre objetos 
 Alternativas de interação: 
• Produtor-consumidor apresenta apenas comunicação em 
uma única direção, por exemplo, quando o usuário 
seleciona uma opção em um menu. 
• Cliente-servidor apresenta comunicação em duas direções, 
um cliente solicita um serviço e espera por uma resposta. 
• Metodologias usam diagramas de interação de modo a 
descrever os padrões de interação entre instâncias das 
classes. 
28 
Interações entre objetos 
 Mensagem: 
• Possibilita a interação entre os objetos 
• Ocorre via chamadas a métodos. 
• Contém nome do objeto, do método e parâmetros. 
cliente servidorsolicitação 
resposta 
produtor consumidor 
mensagem 
15 
29 
Interações entre objetos 
xxx 
xxxxxx 
xxxx 
xxxxxx 
Modelo conceitual Modelo conceitual 
Implementação convencional Implementação orientada a objetos 
30 
Interações entre objetos 
 Polimorfismo: 
• Diferentes reações à um mesmo nome de mensagem. 
• Mesmo identificador para mesma ação lógica. 
• Nomes de operadores e funções sobrecarregados.  Métodos similares devem ter: 
• Os mesmos nomes. 
• A mesma ordem dos argumentos. 
• Os mesmos tipos dos argumentos. 
• Os mesmos tipos de valores retornados. 
• As mesmas notificações de erros. 
 
16 
31 
Interações entre objetos 
 Static binding: 
• Mais seguro. 
• Erros identificados em tempo de compilação. 
• Mais eficiente. 
• Resolução é executada apenas uma vez.  Dynamic binding: 
• Mais flexível. 
• Modificações podem ser facilmente adaptadas. 
32 
Interações entre objetos 
 Sobrecarga: 
• Podem existir métodos com um mesmo nome. 
• Cada método deve ter uma assinatura diferente. 
• Compilador compara as assinaturas.  Exemplo: 
public CalculaMedia ( ); 
public CalculaMedia ( int e ); 
public CalculaMedia ( int e , int f ); 
Diferentes 
quantidades 
ou tipos de 
parâmetros. 
17 
33 
Estados e eventos 
 Estados: 
• Durante a execução de um programa, alguns objetos de 
comportamento dinâmico complexo passam por diversos 
estados 
• O estado de um objeto é definido pelos valores dos seus 
atributos e ligações 
• Uma transição entre estados ocorre após a conclusão de 
operações ou em resposta a eventos 
• Estados e transições são representados através de 
diagramas de estados 
 
34 
Estados e eventos 
Inicializa Inat S1 S2 S3 
Menu 
Ejeta cartão Lê cartão Lê senha Apresenta 
 Menu 
Fim 
18 
35 
Estados e eventos 
 Eventos: 
• São descritos por classes. 
• Quando o evento ocorre a classe é instanciada. 
• Cada classe contém os atributos que descrevem o evento. 
• Classes que descrevem eventos semelhantes são agrupadas 
em hierarquias. 
• Quando um evento ocorre, é comunicados ao interessado. 
36 
Herança entre classes 
 Introdução: 
• Possibilita reutilização de classes. 
• Classes podem herdar variáveis e métodos. 
• Possibilita especialização e generalização. 
• Podem haver múltiplos níveis. 
• Classes são organizadas em hierarquias. 
• Herança definida em tempo de compilação. 
• Declaração de uma classe pode incluir as classes das quais 
são herdados atributos e métodos. 
• Métodos e atributos da super-classe devem ser aplicáveis 
às subclasses. 
19 
37 
Herança entre classes 
38 
Herança entre classes 
 Situações de generalização e especialização: 
• Atributo adicional. 
• Restrições quanto ao valor do atributo. 
• Atributo passando a ter valor constante. 
• Método adicional. 
• Redefinição de método. 
20 
39 
Herança entre classes 
BASE 
DERIV 1 
 ativar () 
DERIV 2 
ativar () 
a.ativar () 
 
 
 b.ativar () 
 
 
 
 
 c.ativar () 
BASE 
DERIVADA DERIVADA 
40 
Herança entre classes 
 Herança simples e múltipla: 
A 
B C 
D E 
A B 
C D 
E 
21 
41 
Herança entre classes 
 Ambigüidade em herança múltipla: 
 A - f ( ) 
? 
O método é herdado 
via os dois ramos da 
hierarquia. 
Algumas 
linguagens 
contém operadores 
para resolução de 
escopo. 
42 
Herança entre classes 
 Inserindo na hierarquia: 
A 
 A 
B - f ( ) C - f ( ) D - f ( ) B - f ( ) C - f ( ) 
 A D 
B - f ( ) C - f ( ) 
 D E 
22 
43 
Herança entre classes 
 Alterando a hierarquia: 
A A 
 BC B 
 D E C F 
 D E 
DESEJA-SE ABF 
44 
Herança entre classes 
 Bibliotecas: 
• Depósitos de classes reutilizáveis. 
• Objetivo é programar reutilizando classes. 
• Classes organizadas em hierarquias. 
• Compartilhamento determinado pela herança.  Exemplos de bibliotecas: 
• Interface com o usuário. 
• Gráficas. 
• Comunicação de dados. 
23 
45 
Herança entre classes 
46 
Herança entre classes 
 Desenvolvimento de bibliotecas: 
• Estudar o domínio da aplicação. 
• Definir as interfaces com as classes. 
• Ajustar interface de modo a torná-la intuitiva. 
• Refinar interface facilitando reutilização. 
• Verificar possibilidade de derivação. 
• Verificar impacto sobre classes na hierarquia. 
• Codificar e integrar à hierarquias já existentes. 
• Testar e documentar a implementação. 
24 
Persistência 
Objetos são copiados de uma memória 
rápida e volátil para uma memória 
secundária lenta e não volátil. 
 
Usado um SGBD de modo a tornar 
transparente ao desenvolvedor os 
detalhes envolvidos no armazenamento. 
47 
Persistência 
 Responsabilidades do SGBD : 
• Controle de concorrência. 
• Manutenção da consistência em caso de erros. 
• Método para acesso fácil aos dados.  Necessário SGBD quando : 
• Existem informações persistentes. 
• Diferentes aplicações compartilham os dados. 
• Pesquisas e relatórios complexos envolvendo dados. 
• Aplicação apresenta característica transacional. 
• Número de instâncias é muito elevado. 
48 
25 
Persistência 
A especificação e os modelos gerados na 
análise devem ser estudados de modo a 
se identificar que objetos precisam ser 
persistentes. 
49 
Persistência 
 
 
 APLICAÇÃO 
 
 CLASSES CONTAINERS 
 BANCO 
TECNOLOGIA INTERFACE DADOS 
 
PROTOCOLO DE ACESO 
50 
26 
Persistência 
 Bancos de dados orientados a objetos : 
• Armazenam objetos. 
• Simplifica o uso de bancos de dados em projetos 
orientados a objetos. 
• Facilita persistência de objetos complexos. 
• Maioria dos produtos comerciais não utilizam uma 
linguagem específica para acesso aos dados. 
• Usam diretamente uma linguagem de programação. 
• O projeto da base de dados é integrada à análise e ao 
projeto da aplicação. 
51 
Persistência 
 Requisitos de um ODBMS : 
• Suporte à noção de objetos complexos. 
• Cada objeto deve ter uma identidade. 
• Suporte ao encapsulamento dos dados. 
• Suporte ao comportamento dos objetos. 
• Suporte à implementação de hierarquias e herança. 
• Possibilidade de definição de novas classes. 
52 
27 
 
 
 
 
MODELAGEM 
53 
Linguagens de modelagem 
 A Unified Modeling Language: 
• É uma popular linguagem de modelagem. 
• O desenvolvimento da UML foi iniciado em 1994 e 1995 
quando Booch, Rumbaugh e Jacobson passaram a 
trabalhar na Rational. 
• A UML pode ser usada para especificar as decisões 
tomadas nas fases de análise, projeto e implementação. 
 
28 
Linguagens de modelagem 
 Diagramas na UML : 
• Diagramas de classes 
• Diagramas de objetos 
• Diagramas de casos de uso 
• Diagramas de seqüências 
• Diagramas de colaborações 
• Diagramas de atividades 
• Diagramas de componentes 
• Diagramas de implantação 
Organização de modelos 
 Pacotes na UML : 
• Mecanismo para organizar elementos relacionados. 
ContaEspecial ContaInvestimento
ContaCorrente Cliente
ControleContas 
29 
Organização de modelos Relacionamentos entre pacotes : 
• Importação 
• Generalização  Importação : 
Sensores 
Controlador 
Gerente 
<<import>> 
<<import>> 
+Temperatura 
+Volume 
#Alarme 
+ MonitorTemperatura 
+ MonitorVolume 
+ SupervisorGeral 
+ SupervisorAlarmes 
Organização de modelos 
• A importação possibilita o acesso aos elementos públicos 
em um outro pacote. 
• Os elementos no pacote que importou tem acesso aos 
elementos no pacote importado. 
• A parte pública de um pacote contém os elementos 
exportados. 
• A importação não é transitiva , os elementos de um pacote 
só tem acesso aos elementos dos pacotes que tiverem sido 
explicitamente importados. 
• Se os elementos de um pacote A são visíveis aos 
elementos de um pacote B, são também visíveis aos 
elementos dos pacotes contidos em B. 
 
30 
Organização de modelos 
 Generalização : 
• Pacotes podem herdar elementos públicos e protegidos de 
outros pacotes. 
• Pacotes podem substituir ou acrescentar elementos. 
GuiXWin 
Gui 
+ Radio 
+ Formulario 
+ CheckBox 
+ Botao 
+ Formulario 
Representando classes 
 Classes : 
Nome 
 
Atributos 
 
Métodos 
 Pessoa 
 
nome 
nascimento 
endereço 
telefone 
RG 
CPF 
 Pessoa 
 
-nome:String 
-nascimento:Date 
-endereço:String 
-telefone:Integer 
-RG:Integer 
-CPF:Integer 
31 
Representando classes 
 Nomes das classes : 
• Nome simples Button 
• Nome de trajeto java::awt::Button 
• Texto composto por letras, números e alguns caracteres de 
pontuação 
Motor ContaCorrente 
java :: awt :: Button 
Representando classes 
 Nomes dos atributos : 
• Texto como no caso dos nomes das classes. 
• Pode ser especificado o tipo do atributo e um valor inicial. 
 
 
  Propriedades : 
• changeable 
• addOnly 
• frozen 
 
[visibilidade] nome[multiplicidade][ 
 [: tipo][ = valor_inicial] [{propriedades}] 
32 
Representando classes 
 Nomes dos métodos : 
• Texto como no caso dos nomes das classes. 
• Pode ser especificado o nome, o tipo e o valor default dos 
parâmetro e um tipo de retorno. 
 
 
 
• Os parâmetros tem a sintaxe seguinte. 
[visibilidade] nome [(parametros)] 
 [: tipo-retorno][ {propriedades}] 
[direção] nome : tipo [ = valor-default ] 
Representando classes 
 Direções : 
• in parâmetro de entrada não modificável 
• out parâmetro de saída, modificável 
• inout parâmetro de entrada modificável  Propriedades : 
• isQuery estado do objeto não é modificado 
• sequential execução tem que ser seqüêncial 
• guarded 
• concurrent possibilita a execução concorrente 
33 
Representando classes 
 Visibilidade : 
• público + 
• protegido # 
• privado - 
 Pessoa 
 
-nome:String 
-nascimento:Date 
-endereço:String 
-telefone:Integer 
-RG:Integer 
-CPF:Integer 
 Conta Corrente 
 
-cliente:String 
-endereço:String 
-telefone:Integer 
-RG:Integer 
-CPF:Integer 
-saldo:Real = 0 
 
+ depositar ( valor : Real ) 
+ sacar ( valor : Real ) : Real 
+ obterExtrato ( ) : Real 
Representando classes 
 Escopo : 
• instance 
• classifier 
 Conta Corrente 
 
-cliente:String 
-endereço:String 
-telefone:Integer 
-RG:Integer 
-CPF:Integer 
-codigoBanco 
Atributos de instância 
 
 
Atributo de classe 
34 
Representando classes 
 Multiplicidade de um atributo : 
 1 
 ControladorComunicação 
 
-portaSerial [2..*] 
Multiplicidades 
Representando objetos 
 Objetos : 
 Autor : Pessoa 
 
-nome = “Pedro Silva” 
-endereço = “Brasilia” 
-telefone = 2733589 
-RG = 5889993 
-CPF = 23887877 
O nome de uma instância é 
sublinhado. 
 
Os nomes dos objetos 
e das classes são opcionais. 
35 
Representando objetos 
 Nomes para as instâncias : 
• nomes simples a:Botao 
• nomes de trajeto b:java::awt::Botao  Alternativas para nomes nos diagramas : 
BotaoOK a : CheckBox : CampoTexto 
 
 
 
 
 
: Cliente 
Instâncias anônimas 
 
Instâncias com nomes 
 
Múltiplas instâncias 
Representando objetos 
 Pedro : Cliente 
 
nome = “Pedro Silva” 
idade = 45 
CPF = 445633 
 Artur : Gerente 
 
nome = “Artur Araujo” 
idade = 56 
agencia = 101 
matricula = 234432 
Ligações são instâncias de 
relacionamentos entre 
classes 
36 
Relacionamentos entre classes 
 Dependência: 
DriverManager OracleConnection 
PBancoDadosJdbc OracleDriver 
Relacionamentos entre classes 
 Associação: 
Empregado Empresa 
Trabalha para 
Carro Pessoa 
Pertence a 
Carro Pessoa 
dono 
37 
Relacionamentos entre classes 
 Multiplicidade na associação : 
 
• Muitos para um 
 
 
• Um para muitos 
 
 
• Muitos para muitos 
 
A B 
* 1 
A B 
1 * 
A B * * 
Relacionamentos entre classes 
 Navegabilidade na associação : 
LinhaPedido Produto 
ContaUsuario Senha 
- chave acesso 
Indica a visibilidade 
38 
Relacionamentos entre classes 
 Visibilidade na associação : 
• Pode-se limitar a visibilidade relativa a objetos que não 
façam parte da associação. 
• A visibilidade relativa a uma associação pode ser pública, 
privada ou protegida. 
ContaUsuario Senha 
- chave acesso 
Indica a visibilidade 
Relacionamentos entre classes 
 Classes de associações: 
Assinatura
Pessoa Revista
0..*0..* 0..*0..*
Classe de associação 
39 
Relacionamentos entre classes 
 Agregação e composição: 
Composição ( partes não existem sem o todo ) 
Agregação 
PessoaEquipe
* **
Barra Manu ItemMenu
1 *
1
** *
*
1 1
Relacionamentos entre classes 
 Herança: 
Conta Especial Conta Investimento
Conta Corrente Cliente1
1..*1..* 1
Generalização 
40 
Relacionamentos entre classes 
Conta Especial 
 
+ sacar ( valor : Real ) : Real 
Conta Investimento 
 
+ sacar ( valor : Real ) : Real 
Conta Corrente 
 
+ sacar ( valor : Real ) : Real 
Classe e método 
abstratos 
Relacionamentos entre classes 
 Conta Especial 
 {leaf} 
 
 
+ sacar ( valor : Real ) : Real 
Conta Investimento 
 
+ sacar ( valor : Real ) : Real 
 Conta Corrente 
 {root} 
 
 
+ sacar ( valor : Real ) : Real 
Classe base 
Classe final 
41 
Diagrama de classes 
 Conceitos : 
• Diagramas de classe são representações gráfica que 
descrevem objetos e seus relacionamentos. 
• Diagramas de instância contém apenas objetos, links e 
valores. 
• Diagramas de instância são usados para facilitar o 
entendimento de diagramas de classe. 
• Diagramas de classes podem ser desenhados segundo 
diferentes perspectivas : conceitual, especificação ou 
implementação. 
 
Diagrama de classes 
 Usuario 
 {persistent} 
 
nome 
senha 
endereco 
telefone 
cpf 
 Emprestimo 
 {persistent} 
 
dataDevolucao 
tombo 
Identifica classe 
persistente 
42 
Diagrama de objetos 
 Conceitos : 
• Apresenta um conjunto de objetos e seus relacionamentos 
estáticos em um determinado instante. 
• Um diagrama de objetos expressa ao parte estática de uma 
interação. 
• Um diagramade objetos é composto por objetos que 
colaboram, mas não são apresentadas as mensagens 
trocadas. 
• Diagramas de objetos contém principalmente objetos e 
links. 
• Um diagrama de objetos é uma instância de um diagrama 
de classes ou a parte estática de um diagrama de interação. 
Diagrama de objetos 
 r : Robot 
[ movendo ] 
a1 : Area a2 : Area 
p1 : Parede p2 : Parede 
Relacionamentos 
entre os objetos 
em um determinado 
instante. 
43 
Interações 
 Ligações : 
• Mensagens podem ser trocadas entre objetos se existirem 
ligações entre os objetos. 
• Uma ligação é um caminho através do qual uma 
mensagem pode ser enviada. 
• A multiplicidade não é aplicável a uma ligação. 
 Cliente Gerente * 1 
 a : Cliente : Gerente 
obterSaldo ( ) 
Interações 
 Diagramas de seqüência : 
:Tela 
Autenticação
: Usuário
1 : autenticar ( nome , senha )
Objeto 
 
 
Ativação 
 
 
 
Mensagem 
 
 
Linha da vida 
44 
Interações 
:Tela 
Autenticação
: Usuário : Tela Saque : ContaCorrente
1 : autenticar ( nome , senha )
2 : criar Tela Saque ( nome )
3 : obter valor
4 : sacar ( nome , valor )
Interações 
 Diagramas de colaboração : 
Sensor Temperatura Monitor Temperatura
Motor
1: analisar ( Temperatura )
2: desligar ( )
Mensagem enviada 
entre objetos 
Ligações que são 
instâncias de 
relacionamentos 
entre classes 
45 
Diagrama de atividades 
 Conceitos : 
• Descreve o fluxo de controle entre atividades. 
• Modela os passos em um processo computacional. 
• Enfatizam o fluxo de controle entre atividades. 
• Enfatizam as atividades realizadas ao longo do tempo. 
• É um tipo de diagrama de estados. 
• Estados podem representar atividades ou ações. 
• Atividades são não atômicas. 
• Ações são atômicas. 
 
Diagrama de atividades 
 Transições : 
• A transição ocorre assim que a ação ou atividade é 
concluída. 
• O fluxo de controle continua até que seja encontrado um 
estado final. 
Estado inicial 
 
 
Transições 
 
 
Estado final 
46 
Diagrama de atividades 
 Saltos : 
• Descrevem trajetos alternativos. 
• Controle de fluxo baseado em um teste. 
• A cada transição é associado um teste. 
• Os testes podem ser especificados usando-se texto ou a 
sintaxe de uma linguagem de programação. 
 
[ alarme ativado ] 
[ alarme desativado ] 
Diagrama de atividades 
 Fork e join : 
• Fluxos de atividades podem ser concorrentes. 
• Barras de sincronização são usadas. 
• Fork usado para dividir em fluxos concorrentes. 
 
 
 
Fork 
47 
Diagrama de atividades 
• Join usado para sincronizar fluxos concorrentes. 
 
 
 
 
 
 
 
 
• Atividades em fluxos concorrentes podem se comunicar 
através de sinais. 
Join 
Eventos 
 Conceitos : 
• Um evento é a especificação de uma ocorrência 
significativa. 
• Eventos podem ser síncronos ou assíncronos. 
• Eventos podem ser internos ou externos.  Exemplos de eventos : 
• Sinais. 
• Chamadas às operações. 
• Passagem do tempo. 
• Mudança de estado. 
48 
Eventos 
 Sinais : 
• Um sinal é enviado por um objeto e recebido por outro. 
• Os sinas internos mais comuns são as exceções. 
• Sinais podem ser organizados em hierarquias. 
• Sinais podem ter atributos e operações. 
• Os sinais que podem ser enviados pelas operações são 
especificados na modelagem da classe ou interface. 
 
Chamado 
 
 
abrir ( ) 
<<signal>> 
ConexãoEstabelecida 
<<send>> 
Eventos 
• Sinais não devem ser usados em substituição ao fluxo 
normal de controle. 
• Deve-se analisar quais os possíveis sinais que um objeto 
pode receber. 
• Eventos similares devem ser organizados em hierarquias. 
• Os sinais que um objeto pode receber são listados em um 
compartimento da classe. 
 
 Motor 
 
 
Sinais 
AlarmeTemperatura ( t : float ) 
AlarmeVelocidade ( v : float ) 
AlarmeChuva ( ) 
49 
Eventos 
 Exceções : 
• São tipos de sinais. 
• As exceções são enviadas quando da execução de 
operações. 
• Para cada operação é necessário identificar as exceções 
que podem ser originadas. 
• As exceções que podem ser originadas devem ser 
documentadas. 
 
Chamado 
 
 
abrir ( ) 
<<exception>> 
ErroComunicação 
<<send>> 
Eventos 
 Famílias de sinais e de exceções: 
• Devem ser identificadas as propriedades comuns e 
organizadas hierarquias. 
<<signal>> 
MouseMove 
<<signal>> 
MouseDrag 
<<signal>> 
MouseEvent 
<<exception>> 
EnunciadoSQL 
<<exception>> 
Conexão 
<<exceptionl>> 
BancoDados 
50 
Máquina de estados 
 Notação UML: 
desligado acelerando movendo 
desacelerando 
alarme temperatura 
ligar 
desligar desligar 
Interfaces 
 Dependência : 
Tela Saque ContaEspecial 
ContaCorrente 
 << interface >> 
 ContaCorrente 
 
depositar ( ) 
sacar ( ) 
ContaEspecial 
Tela Saque 
Dependência 
51 
Interfaces 
 Realizações : 
• Especifica o relacionamento entre uma interface e a classe 
que provê as operações ou serviços. 
• Uma interface pode ser realizada por diferentes classes. 
• Uma classe pode realizar diferentes interfaces. 
 
ContaEspecial 
ContaCorrente 
 << interface >> 
 ContaCorrente 
 
depositar ( ) 
sacar ( ) 
ContaEspecial 
Realização 
Implementação 
 Conceitos : 
• Um componente é uma parte física de um sistema e provê 
a realização de um conjunto de interfaces. 
• São usados para modelar executáveis, bibliotecas, tabelas, 
arquivos e documentos. 
• Nomes podem incluir o pacote no qual se encontra o 
componente. 
Tela.java interface::Tela.java 
52 
Implementação 
 Características dos componentes : 
• Provê uma abstração de um aspecto físico do sistema. 
• Provê serviços definidos em um conjunto de interfaces. 
• Implementa um conjunto de classes que colaboram de 
modo a prover os serviços definidos nas interfaces. 
• São fracamente acoplados em relação aos outros 
componentes. 
Implementação 
 Classes e componentes: 
• Classes representam abstrações lógicas. 
• Componentes representam coisas físicas. 
• Componentes são a implementação física de elementos 
lógicos como classes. 
Classes 
53 
Localização 
 Conceitos : 
• Componentes podem ser distribuídos entre os nós de um 
sistema. 
• Diferentes instâncias de um componente podem estar em 
diferentes nós. 
: ServidorTransacao 
 {location = servidor } 
 antares:servidor 
 
 Deploys 
 servtrans.exe 
Localização 
Servidor transação 
c1.exe c2.exe 
Nó 
 
 
 
 
 
 
 
Componentes 
54 
Localização 
 Diagramas de implantação : 
 
<<100BASET>> 
<<RS232>> 
Terminal 
Cliente 
Servidor 
Padrões de projeto 
 Conceitos : 
• Desenvolvimento de software é uma atividade complexa e 
desenvolvimento de software reutilizável é uma atividade 
ainda mais complexa. 
• Patterns e frameworks possibilitam a melhora da 
qualidade do software. 
• Patterns capturam estruturas identificadas nas soluções 
dadas na implementação de aplicações em um domínio. 
• Frameworks são conjuntos de componentes que 
colaboram para prover uma arquitetura reutilizável em 
uma família de aplicações relacionadas. 
 
 108 
55 
Padrões de projeto 
• Sistemas bem estruturados apresenta diversos patterns. 
• Um pattern soluciona um problema freqüente em um 
determinado contexto. 
• Patterns são aplicáveis em diferentes níveis de abstração. 
• Patterns de projeto, especificam a estrutura e o 
comportamento de conjuntos de classes.• Patterns de arquitetura , especificam a estrutura e o 
comportamento de um sistema. 
• Patterns auxiliam no entendimento, na especificação, na 
construção e na documentação de um sistema. 
• O uso de patterns é útil, mas não é uma solução milagrosa. 
109 
Padrões de projeto 
 Características de um pattern : 
• Resolve um problema real. 
• Não captura apenas princípios abstratos ou estratégias. 
• Captura soluções comprovadas. 
• Não descreve teorias ou especulações. 
• A solução não é trivial. 
• A solução para o problema normalmente é obtida 
indiretamente. 
• Descreve estruturas e mecanismos que estão presentes em 
diversos sistemas. 
110 
56 
Padrões de projeto 
 Coleções de patterns : 
• Catálogos ou sistemas de patterns.  Catálogos de patterns : 
• Coleções de patterns relacionados. 
• Patterns divididos em um pequeno número de categorias.  Sistemas de patterns : 
• Conjunto de patterns relacionados que em conjunto 
possibilitam a construção e evolução de arquiteturas 
completas. 
• Descrevem como os patterns podem ser combinados. 
 111 
Padrões de projeto 
 Documentação de um pattern : 
• Descrição resumida e visão geral. 
• Nome composto por uma palavra ou frase curta. 
• Outros nomes pelos quais o pattern é conhecido. 
• Problema e objetivo. 
• Contexto no qual o problema e solução ocorrem. 
• Cenário que descreve a motivação. 
• Descrição da solução com aspectos estáticos e dinâmicos. 
• Exemplos que ilustrem a aplicação do pattern. 
• Contexto resultante e conseqüências do uso do pattern. 
 
 112 
57 
Padrões de projeto 
• Patterns relacionados. 
• Usos conhecidos em sistemas existentes. 
• Situações nas quais o pattern pode ser utilizado. 
• Representação gráfica. 
• Responsabilidades de classes e objetos no pattern. 
• Descrição de como os participantes colaboram. 
• Detalhes envolvidos na implementação. 
113 
Padrões de projeto 
 Tipos de patterns : 
• Patterns de arquitetura, de projeto, idiomas e anti-
patterns. 
• Diferença está nos níveis de abstração e de detalhamento.  Patterns de arquitetura : 
• Estratégia de alto nível. 
• Descreve a estrutura do sistema. 
• Afeta a estrutura do sistema como um todo. 
• Provê um conjunto predefinido de subsistemas. 
• Especifica as responsabilidades dos subsistemas. 
• Organiza os relacionamentos entre subsistemas. 
114 
58 
Padrões de projeto 
 Patterns de projeto : 
• Tática de nível médio. 
• Provê um esquema para refinar os subsistemas ou 
componentes de um sistema ou os relacionamentos entre 
os mesmos. 
• Descreve a estrutura de um subsistema ou componente que 
se repete freqüentemente na solução de projetos em um 
determinado contexto. 
• Não afeta a estrutura do sistema como um todo. 
• Define uma micro-arquitetura de um subsistema ou 
componente. 
115 
Padrões de projeto 
 Idiomas : 
• Pattern de baixo nível. 
• Específico de uma linguagem de programação. 
• Descreve como implementar aspectos particulares de 
componentes ou relacionamentos em uma determinada 
linguagem de programação. 
• Descreve uma técnica de programação específica de uma 
linguagem. 
• Detalhes de baixo nível da estrutura ou comportamento de 
um componente. 
 
116 
59 
Padrões de projeto 
 Anti- patterns : 
• Representa uma “lição aprendida”. 
• Pode descrever uma solução ruim para problema. 
• Pode descrever como migrar de uma situação ruim para 
uma situação boa. 
117 
Padrões de projeto 
 Um catálogo de patterns [Gamma]: 
• Abstract Factory, provê uma interface para criar famílias 
de objetos relacionados ou dependentes sem ser necessário 
especificar as classes concretas. 
• Adapter, converte a interface de uma classe em uma outra 
interface esperada pelos clientes, torna as interfaces 
compatíveis. 
• Bridge, desacopla uma abstração da sua implementação de 
modo que possam variar independentemente. 
• etc. 
118 
60 
Padrões de projeto 
 Padrões para criar objetos: 
• Patterns usados para possibilitar que o processo de 
instanciação seja abstraído. 
• Ajudam a tornar o sistema independente de como os 
objetos são criados, compostos e representados. 
• Um pattern usado na criação de classes usa herança para 
variar a classe instanciada. 
• Um pattern usado na criação de objetos delega a 
instanciação para outros objetos. 
• São patterns importantes pois aumentam o uso de 
composição de objetos. 
119 
Padrões de projeto 
• Os patterns encapsulam o conhecimento a respeito das 
classes concretas que o sistema usa. 
• Patterns escondem como as instâncias das classes são 
criadas e colocadas em conjunto. 
• O sistema apenas conhece sobre os objetos as interfaces 
definidas. 
120 
61 
Padrões de projeto 
 Abstract Factory: 
• Provê uma interface para a criação de famílias de objetos 
relacionados ou dependentes sem especificar as classes 
concretas.  Aplicabilidade : 
• Quando o sistema deve ser independente de como os seus 
produtos são criados, compostos e representados. 
• Quando o sistema deve ser configurado com uma entre 
múltiplas famílias de produtos. 
• Quando se deseja revelar apenas as interfaces de uma 
biblioteca e não a sua implementação. 
 
121 
Padrões de projeto 
 Singleton: 
• Garantir que uma classe só tenha uma instância. 
• Prover um ponto de acesso global à mesma.  Aplicabilidade: 
• Quando só pode existir uma única instância de uma classe 
que precisa estar acessível aos clientes de um ponto de 
acesso conhecido. 
• Quando a única instância pode ser estendida por herança e 
clientes devem ser capazes de usar uma instância 
estendida sem modificar o código. 
122 
62 
Padrões de projeto 
 Padrões estruturais: 
• Descrevem como classes e objetos são compostos para 
formar estruturas maiores. 
• Patterns de estruturas de classes usam herança para 
compor interfaces ou implementações. 
• Patterns de estruturas de objetos descrevem como objetos 
podem ser compostos de modo a se obter uma nova 
funcionalidade. 
• A composição de objetos possibilita a mudança da 
composição em tempo de execução, o que é impossível 
com a composição de classes. 
123 
Padrões de projeto 
 Facade: 
• Provê uma interface unificada para um conjunto de 
interfaces em um subsistema. 
• Define uma interface de mais alto nível que facilita o uso 
do subsistema.  Aplicabilidade : 
• Quando é necessário prover uma interface simples para 
um subsistema complexo. 
• Quando existe um número elevado de dependências entre 
clientes e as implementações de uma abstração. 
• Quando se deseja organizar os subsistemas em camadas. 
124 
63 
Padrões de projeto 
 Proxy: 
• Provê um intermediário para controlar acesso ao objeto.  Aplicabilidade : 
• Quando é necessária uma referência mais sofisticada para 
um objeto do que um ponteiro. 
• Quando é necessário prover um representante local para 
um objeto em um outro espaço de endereçamento. 
• Quando é necessário criar objetos complexos sob 
demanda. 
• Quando é necessário controlar o acesso ao objeto original. 
125 
Padrões de projeto 
 Padrões de comportamento: 
• Preocupam-se com algoritmos e atribuições de 
responsabilidades entre objetos. 
• Caracterizam fluxos de controle complexos difíceis de 
seguir em tempo de execução. 
• Patterns de comportamento de classe usam herança para 
distribuir comportamento entre classes. 
• Patterns de comportamento de objetos usam composição 
para distribuir comportamento. 
126 
64 
Padrões de projeto 
 Observer: 
• Define uma dependência de um para muitos entre objetos, 
quando um objeto muda de estado, todos os dependentes 
são notificados e atualizados.  Aplicabilidade : 
• Quando uma abstração tem dois aspectos, um dependentedo outro. 
• Quando uma mudança em um objeto requer mudar outros 
e não se sabe quantos objetos precisam ser mudados. 
• Quando um objeto precisa notificar outros sem fazer 
suposições a respeito de quem são os objetos. 
127 
Padrões de projeto 
 Strategy: 
• Define uma família de algoritmos, encapsula cada um e 
possibilita a substituição dos mesmos e a variação 
independente dos clientes que os utilizam.  Aplicabilidade : 
• Quando diversas classes relacionadas diferem apenas no 
seu comportamento. 
• Quando são necessárias diversas variantes de um 
algoritmo. 
• Quando um algoritmo usa dados que o cliente não deve 
saber a respeito. 
128 
65 
LINGUAGEM C++ 
129 
CLASSES E OBJETOS 
130 
66 
Tópicos 
 Declaração e definição de classes.  Atributos de instância e de classe.  Métodos de instância.  Métodos de classe.  Métodos amigos.  Visibilidades dos atributos e métodos.  Criando objetos.  Ponteiros e alocação dinâmica de objetos.  Construtores e destrutores.  Tratamento de erros e exceções. 
131 
A linguagem C++ 
 Introdução: 
• Desenvolvida por Bjarne Stroustrup na AT&T. 
• Linguagem híbrida. 
• Possibilita introdução gradual de novos conceitos. 
• Extensão da linguagem C. 
• Mantém compatibilidade com a linguagem C. 
• Sem proprietário. 
• Diversos fornecedores de compiladores. 
• Forte verificação de tipos. 
• Sintaxe considerada complexa. 
 
132 
67 
A linguagem C++ 
• Parcialmente padronizada. 
• Código compilado para uma plataforma específica. 
• Gerado código executável para uma plataforma. 
• Migração requer recompilação. 
• Código tipicamente executado com alto desempenho. 
• Interfaces de programação parcialmente padronizadas. 
• Mudança nas bibliotecas tipicamente requer manutenção. 
133 
Espaço de nomes 
 Conceitos: 
• Particiona o espaço de nomes. 
• Evita a ocorrência de conflitos entre nomes. 
• Agrupa elementos relacionados. 
• Podem existir declarações e definições em um namespace. 
• Definições podem ser feitas fora do corpo do namespace. 
• Usado o operador de resolução de escopo ::. 
• Espaços de nomes podem ser aninhados. 
• Podem existir múltiplas ocorrências de um namespace . 
• Diretiva using identifica o namespace usado. 
134 
68 
Espaço de nomes 
namespace string { 
 void strcpy(char* source, char* from); 
 void strcat(char* source, char* from); 
 int strlen(char* source); 
} 
 
void string::strcpy(char* source, char* from) { 
... 
} 
 
void string::strcat(char* source, char* from) { 
... 
} 
 
int string::strlen(char* source) { 
... 
} 
135 
Espaço de nomes 
namespace nameSpaceA { 
 int var = 5; 
} 
 
namespace nameSpaceB { 
 double var = 3.1416; 
} 
 
... 
cout << nameSpaceA::var; 
cout << nameSpaceB::var; 
... 
namespace nameSpaceA { 
 int var = 5; 
} 
 
namespace nameSpaceB { 
 double var = 3.1416; 
} 
 
... 
using namespace nameSpaceB; 
 
cout << var; 
cout << (var*2); 
... 
136 
69 
Espaço de nomes 
 Declaração de um namespace: 
137 
Espaço de nomes 
 Definição do namespace: 
138 
70 
Espaço de nomes 
 Informando o namespace: 
 
 
 
 Declarando um sinônimo: 
139 
Espaço de nomes 
 O namespace std: 
• Espaço de nomes da biblioteca padrão. 
• Funções, classes e templates declarados no namespace. 
• Existem várias formas de se informar o espaço de nomes. 
#include <iostream> #include <iostream> #include<iostream> 
 
... ... ... 
 
using namespace std; using std::cin; std::cin >> i; 
 using std::cout; std::cout << j; 
 
 
140 
71 
Classes 
 Declaração: 
• Palavra-chave class. 
• Nome da classe. 
• Lista de atributos e métodos colocados entre chaves.  Visibilidade: 
• Aceso aos métodos e aos atributos pode ser público, 
privado ou protegido. 
• A visibilidade default é private. 
 
 
 
 
private 
public 
protected 
Especificadores 
da visibilidade de acesso. 
141 
Classes 
class nome_da_classe { 
 
 especificador_acesso_1: 
 membro1; 
 ... 
 especificador_acesso_2: 
 membro2; 
 ... 
 }; 
Palavra-chave. 
142 
72 
Classes 
 Classes aninhadas: 
• Uma classe pode ser declarada dentro de uma outra classe. 
• Uma classe aninhada é visível dentro da classe externa. 
 
class Retangulo { 
 
 class Coordenada { 
 int x, y; 
 }; 
 
 Coordenada pt1, pt2, pt3, pt4; 
}; 
143 
Atributos 
 Tipos dos atributos: 
• Valor inicial dos atributos é aleatório. 
• Atributos podem ser de instância ou de classe. 
• Atributos de classe identificador pelo modificador static. 
• Atributos constantes identificados pelo modificador const. 
 class nome_da_classe { 
 tipo nome_da_variável; 
 static tipo nome_da_variável; 
 const tipo nome_da_variável; 
 }; 
144 
73 
Atributos 
• Atributos de instância. 
 class nome_da_classe { 
 tipo nome_da_variável; 
 }; 
• Atributos de classe via modificador static. 
 class nome_da_classe { 
 static tipo nome_da_variável; 
 }; 
• Atributos constantes via modificador const. 
 class nome_da_classe { 
 const tipo nome_da_variável; 
 }; 
145 
Atributos 
class Aluno { 
 // Lista dos atributos. 
 string nome; 
 int matricula; 
 int telefone; 
} alunoA; 
class Disciplina { 
 // Lista dos atributos. 
 private : 
 string nome; 
 int codigo; 
}; 
146 
74 
Atributos 
• Constantes com escopo de classe. 
// Declaração de uma constante. 
 
class CntrComunicacao { 
 static const int LIMITE; 
 . . . 
}; 
 
// Definição de uma constante. 
 
const int CntrComunicacao::LIMITE = 10; 
 
 
147 
Atributos 
• Alternativamente para int, bool, char, etc. 
// Declaração de uma constante. 
 
class CntrComunicacao { 
 static const int LIMITE = 10; 
 . . . 
}; 
 
// Definição de uma constante. 
 
const int CntrComunicacao::LIMITE; 
 
 
148 
75 
Métodos 
 Declaração e definição: 
• Os métodos são declarados na declaração da classe. 
• Declaração informa a assinatura do método. 
• A definição pode ocorrer quando da declaração. 
• A definição pode ocorrer posteriormente. 
• Definição posterior usa operador de resolução de escopo. 
149 
Métodos 
class Aluno { 
 // Lista dos atributos. 
 private: 
 string nome; 
 int matricula; 
 int telefone; 
 
 // Lista dos métodos. 
 public: 
 void setNome(string nome) { 
 // Código do método. 
 } 
}; 
Método declarado 
e definido. 
150 
76 
Métodos 
class Aluno { 
 // Lista dos atributos. 
 private: 
 string nome; 
 int matricula; 
 int telefone; 
 
 // Lista dos métodos. 
 public: 
 void setNome(string nome); 
 void setMatricula(int matricula); 
 void setTelefone(int telefone); 
}; 
Métodos 
declarados 
mas não 
definidos. 
151 
Métodos 
// Definições dos métodos. 
 
void Aluno::setNome(string nome) { 
 this->nome = nome; 
} 
 
 
void Aluno::setMatricula(int matricula) { 
 this->matricula = matricula; 
} 
 
void Aluno::setTelefone(int telefone) { 
 this->telefone = telefone; 
} 
Operador 
de resolução 
de escopo. 
 
 
 
Ponteiro 
para o 
objeto. 
152 
77 
Métodos 
 Exemplo: 
153 
Métodos 
154 
78 
Métodos 
 Sobrecarga e polimorfismo: 
• Métodos podem ser sobrecarregados. 
• Métodos sobrecarregadostem o mesmo nome. 
• Métodos sobrecarregados podem ter a mesma assinatura 
se forem de diferentes classes. 
class Horario { 
 . . . 
 void obterHorario ( long* ticks ); 
 void obterHorario ( int* hours, 
 int* minutos, int* segundos ); 
}; 
 155 
Métodos 
• Facilita desenvolvimento de aplicações portáveis. 
• Facilita o entendimento das aplicações. 
• Ao nível de métodos. 
 class nome_da_classe { 
 tipo nome_do_método ( parâmetros ); 
 tipo nome_do_método ( parâmetros ); 
 }; 
• Ao nível dos operadores 
 tipo nome_da_classe::operator 
 símbolo (param) { . . . 
 } 
156 
79 
Métodos 
 Argumentos default: 
• Usados quando parâmetros atuais não são informados. 
• Informados nas declarações dos métodos. 
 
 
class SymTable { 
 . . . 
public : 
 SymTable ( int sz = 16 ); 
}; 
Construtor com um 
valor default para 
o argumento. 
157 
Métodos 
 Métodos inline : 
• Métodos pequenos e freqüentemente chamados. 
• Código inserido toda vez que o método é chamado. 
• Usada a palavra chave inline ou o método é definido 
dentro do corpo da classe. 
 
 
 class ContaCorrente { 
 // . . . 
 public: void sacar ( float valor ) { 
 // . . . 
 } 
 }; 
 
Método definido na 
declaração da classe 
158 
80 
Métodos 
 class ContaCorrente { 
 
 public: 
 void sacar (float valor); 
 ... 
 }; 
 
 
 inline void ContaCorrente::sacar(float valor) { 
 
 ... 
 } 
159 
Métodos 
 Métodos amigos: 
• Podem acessar membros privados de uma classe. 
• São úteis em alguns padrões de projeto. 
• Usada a palavra-chave friend. 
• Toda uma classe pode ser declarada como amiga de outra. 
 
class nome_da_classe { 
 
 public: 
 
 friend tipo nome_da_classe::nome_método(param); 
 friend class nome_da_classe; 
... 
}; 
160 
81 
Métodos 
class IntSet { 
 // . . . 
public : 
 friend void RealSet::SetToInt ( IntSet * ); 
}; 
 
class RealSet { 
 // . . . 
public : 
 friend void IntSet::SetToReal ( RealSet * ); 
}; 
Métodos 
amigos. 
161 
Métodos 
 Exemplos: 
class Horario { 
 // . . . 
 void obterHorario ( long* ticks ); 
 void obterHorario ( int* hours, 
 int* minutos, int* segundos ); 
}; 
class Conjunto { 
 // . . . 
public : 
 friend Bool operator & ( int , Conjunto ); 
 friend Bool operator < (Conjunto , Conjunto); 
}; 
 
 
Sobrecarga de 
métodos 
 
 
 
 
 
 
Sobrecarga de 
operadores 
162 
82 
Métodos 
 Métodos e atributos estáticos: 
• Atributo relacionado a uma classe e não às instâncias. 
• Atributo identificado via palavra-chave static. 
• Um atributo estático é declarado na classe. 
• Um atributo estático é definido fora da classe. 
• Atributo pode ser acessado por qualquer método da classe. 
• Método estático pode ser invocado sem se informar o alvo. 
• Um método estático só pode acessar membros estáticos. 
• Um método estático é identificado por static. 
 
163 
Métodos 
class Aluno { 
 // Lista dos atributos. 
 private: 
 static int numeroAlunos; 
 ... 
} 
 
int Aluno::numeroAlunos = 0; 
 
... 
 
Declaração. 
 
 
Posterior definição. 
164 
83 
Métodos 
class Aluno { 
 ... 
 private: 
 static int numeroAlunos; 
 ... 
 public: 
 static int getNumeroAlunos(); 
 ... 
}; 
... 
int Aluno::getNumeroAlunos() { 
 return numeroAlunos; 
} 
... 
int Aluno::numeroAlunos = 0; 
 
n = alunoA.getNumeroAlunos(); 
... 
n = alunoB->getNumeroAlunos(); 
... 
n = Aluno::getNumeroAlunos(); 
Formas de 
invocar um 
método estático. 
165 
Métodos 
 Métodos e objetos constantes: 
• Os objetos constantes são identificados via const. 
• Objetos constantes são alterados apenas via construtores. 
• Um método constante não pode alterar o estado do objeto. 
• Métodos constantes são identificados via const. 
• Métodos constantes podem ser invocados sobre objetos 
constantes. 
 
 
166 
84 
Métodos 
class Aluno { 
 ... 
 // Lista dos métodos. 
 public: 
 string getNome() const; 
 ... 
}; 
 
... 
 
string Aluno::getNome() const { 
 return nome; 
} 
const Aluno alunoE("jose"); 
 
... 
 
nome = alunoE.getNome(); 
Declaração de 
um objeto constante 
e acesso ao mesmo 
via método constante. 
167 
Métodos 
 Atributos modificáveis: 
• Pode-se ter atributos modificáveis em objeto constante. 
• Os atributos modificáveis são identificados via mutable. 
• Atributos mutable são modificáveis via método const. 
 
class Aluno { 
 private: 
 ... 
 mutable string nome; 
 public: 
 ... 
 static int getNumeroAlunos(); 
}; 
void Aluno::setNome(string nome) 
const { 
 this->nome = nome; 
} 
... 
 
const Aluno alunoE; 
... 
alunoE.setNome("Maria"); 
168 
85 
Objetos 
 Como criar objetos: 
• Quando da declaração da classe. 
• Estaticamente após a declaração da classe. 
• Dinamicamente após a declaração da classe. 
class Aluno { 
 private: 
 string nome; 
 int matricula; 
 int telefone; 
 // Lista dos métodos. 
 ... 
} alunoA, alunoB; 
Objetos 
criados quando 
da declaração 
da classe. 
169 
Objetos 
class Aluno { 
 // Lista dos atributos. 
 private: 
 string nome; 
 int matricula; 
 int telefone; 
 // Lista dos métodos. 
 ... 
 
}; 
int main(int argc, char *argv[]) { 
 
 Aluno alunoA, alunoB; 
 ... 
} 
Objetos 
posteriormente 
criados de forma 
estática. 
170 
86 
Objetos 
 Alocação dinâmica dos objetos: 
• Usados os operadores new e delete. 
• Ao usar new, aloca memória e depois invoca o construtor. 
• Ao usar delete, chama o destrutor e depois libera memória. 
• Importante ficar claro se é uma matriz de objetos. 
• Se foi alocada uma matriz, deve ser destruída uma matriz. 
• Funções malloc e free não invocam construtor e destrutor. 
 
ptrA = new NomeClasse; 
ptrB = new NomeClasse(argumentos); 
ptrC = new NomeClasse[tamanho]; 
171 
Objetos 
 Alocação dinâmica : 
 nome_da_classe *nome_do_objeto = 
 new nome_da_classe ( ); 
 delete ( nome_do_objeto );  Ponteiros : 
• Para uma classe 
 nome_da_classe *nome_do_ponteiro ; 
• Para membros de uma classe 
 tipo nome_da_classe :: *nome_do_ponteiro; 
172 
87 
Objetos 
class Aluno { 
 // Lista dos atributos. 
 ... 
 // Lista dos métodos. 
 ... 
 
}; 
int main(int argc, char *argv[]) { 
 
 Aluno *alunoA, *alunoB; 
 
 alunoA = new Aluno(); 
 alunoB = new Aluno(); 
 ... 
} 
Objetos 
dinamicamente 
criados. 
173 
Objetos 
string *stringPtr1 = new string; 
string *stringPtr2 = new string[100]; 
 
... 
 
delete stringPtr; // Destrói um objeto. 
delete [] stringPtr2; // Destrói uma matriz de objetos. 
 
 
 
typedef string SociosFirma[2]; 
 
 
string *socios = new SociosFirma; 
... 
delete [] socios; 
174 
88 
Objetos 
 Exemplo: 
 class Coordenada { 
 public : 
 int x,y; 
 ... 
}; 
 
... 
 
Coordenada coordA; 
int valor; 
int Coordenada::*ptr; // Ponteiro para atributo da classe. 
ptr = &Coordenada::x; // Obtém endereço do atributo. 
coordA.*ptr = 10; // Acessa o membro. 
valor = coordA.*ptr; // Acessa o membro. 
Visibilidade 
pública para 
possibilitar o 
acesso.175 
Objetos 
class Coordenada { 
... 
 public: 
 void setX(int x){this->x = x;} 
 int getX(){return x;} 
}; 
 
Coordenada coordA; 
int valor; 
void (Coordenada::*ptrA)(int); // Ponteiro para método. 
int (Coordenada::*ptrB)(); // Ponteiro para método. 
ptrA = &Coordenada::setX; // Obtém endereço. 
ptrB = &Coordenada::getX; // Obtém endereço. 
(coordA.*ptrA)(10); // Invoca via ponteiro. 
valor = (coordA.*ptrB)(); // Invoca via ponteiro. 
176 
89 
Objetos 
 Referências para objetos: 
• Sinônimos para objetos. 
• Similar ao uso de ponteiros. 
• Usado o símbolo & em vez do símbolo * . 
 Point pt1 ( 10 , 10 ); 
 Point& pt2 = pt1; 
• Pode-se usar referências como argumentos de métodos. 
• Argumento é passado por referência e não por valor. 
Conjunto operator * (Conjunto& cnj1 , 
 Conjunto& cnj2) { 
 // . . . 
} 
177 
Objetos 
 Envio de mensagens: 
• Usando o nome do objeto. 
 nome_do_objeto.nome_do_método (param); 
• Usando um ponteiro para o objeto. 
 nome_do_ponteiro->nome_do_método (param);  Exemplo: 
ContaCorrente a = new ContaCorrente ( ); 
ContaCorrente b; 
a->sacar ( 100 ); 
b.depositar ( 200 ); 
178 
90 
Construtores e destrutores 
 Método construtor: 
• Automaticamente invocado quando um objeto é criado. 
• Garante que as inicializações não serão esquecidas. 
• Tem o mesmo nome da classe da qual é um membro. 
• O tipo do retorno é implícito. 
• O retorno é um ponteiro para uma instância da classe. 
• Construtores podem ser sobrecarregados e ter argumentos.  Construtor default: 
• Construtor para o qual não há argumentos . 
• Construtor para o qual há defaults para todos argumentos. 
 
179 
Construtores e destrutores 
class Aluno { 
 // Lista dos atributos. 
 private: 
 string nome; 
 int matricula; 
 int telefone; 
 
 // Lista dos métodos. 
 public: 
 Aluno(); 
 Aluno(string, int, int); 
 void setNome(string nome); 
 void setMatricula(int matricula); 
 void setTelefone(int telefone); 
}; 
180 
91 
Construtores e destrutores 
// Definições dos construtores. 
 
Aluno::Aluno() { 
 nome = ""; 
 matricula = 0; 
 telefone = 0; 
} 
 
 
Aluno::Aluno(string nome, int matricula, int telefone) { 
 this->nome = nome; 
 this->matricula = matricula; 
 this->telefone = telefone; 
} 
Construtores 
tem o mesmo 
nome da 
classe 
181 
Construtores e destrutores 
Aluno alunoA("Fernando", 1234, 5678); 
Aluno alunoB("Felipe", 8901, 2345); 
 
 
Aluno *alunoC, *alunoD; 
 
 
 
alunoC = new Aluno("Margarida", 6789, 1234); 
alunoD = new Aluno("Claudia", 5678, 9012); 
Os objetos são 
inicializados 
quando são 
criados. 
182 
92 
Construtores e destrutores 
 Lista de inicialização: 
• Forma de inicializar os membros. 
• Lista separada por vírgulas. 
class ElementoGrafico { 
 int coordX, coordY; 
 public : 
 ElementoGrafico(int, int); 
 ... 
}; 
 
ElementoGrafico::ElementoGrafico(int x, int y):coordX(x), coordY(y) { 
} 
183 
Construtores e destrutores 
class Matricula { 
 Aluno &aluno; 
 Disciplina &disciplina; 
 public: 
 Matricula(Aluno&, Disciplina&); 
 ... 
}; 
 
Matricula::Matricula(Aluno &aluno, 
 Disciplina &disciplina): 
 aluno(aluno), disciplina(disciplina) { 
} 
 
Matricula::Matricula(Aluno &aluno, Disciplina &disciplina){ 
 this->aluno = aluno; 
 this->disciplina = disciplina; 
} 
Inicialização de 
referências 
deve ser feita 
em uma lista. 
Não é correto 
inicializar no 
corpo. 184 
93 
Construtores e destrutores 
 Método destrutor: 
• Programador deve destruir objetos não mais necessários. 
• Invocado quando objeto sai do escopo. 
• Invocado quando de um delete. 
• Tem o mesmo nome da classe precedido por ~ . 
• Não tem argumentos. 
• Não podem ser sobrecarregados. 
 
class nome_da_classe { 
 public: tipo_retorno nome_método (param) ; 
}; 
 
 
185 
Construtores e destrutores 
 Construtores usados para copiar objetos: 
• Possibilita criar uma cópia de um objeto. 
• O argumento referencia um objeto da classe da qual o 
construtor é membro. 
• O construtor provido pelo compilador copia membro a 
membro, isso causa problemas em certas situações.  Quando copiar objetos: 
• Ao criar um objeto que usa outro objeto para inicialização. 
• Em uma atribuição. 
• Na passagem de argumentos para uma função. 
• No retorno de um objeto por uma função. 
186 
94 
Construtores e destrutores 
 Matrizes de objetos: 
• Definida como uma matriz convencional. 
• Podem ser especificados valores para a sua inicialização. 
• Objetos podem ser criados de forma estática ou dinâmica. 
 
Aluno graduacao[2]= {Aluno("Maria", 1234, 5678), 
 Aluno("Roberto", 9012, 3456)}; 
 
 
 
Aluno *mestrado = new Aluno [3]; 
Valores iniciais 
não são 
informados. 
187 
Tratamento de exceção 
 Conceito: 
• Mecanismo provido pela linguagem de programação que 
visa facilitar o tratamento de anomalias ocorridas em 
tempo de execução. 
 Vantagens: 
• Padroniza a forma como os erros são notificados. 
• Torna explícita a notificação dos erros. 
• Aproxima a notificação do erro do tratamento do mesmo. 
• Melhora a documentação dos erros. 
 
188 
95 
Tratamento de exceção 
 Exemplos de exceções: 
• Divisão por zero. 
• Argumento inválido. 
• Overflow. 
• Acesso a um elemento fora dos limites de uma matriz. 
• Término da memória livre disponível. 
189 
Tratamento de exceção 
 exception 
 bad_alloc 
 bad_cast 
 bad_typeid 
 logic_error 
 domain_error 
 invalid_argument 
 length_error 
 out_of_range 
 runtime_error 
 overflow_error 
 range_error 
 underflow_error 
 ios_base::failure 
Algumas funções da 
biblioteca padrão 
lançam exceções. 
 
A classe base std::exception 
é definida 
em <exception>. 
 
As exceções padrões podem 
ser lançadas por funções 
na aplicação ou novas 
classes podem ser derivadas. 
190 
96 
Tratamento de exceção 
 Tratamento de exceções: 
• Bloco try - Contém código que pode lançar exceções 
• throw - Palavra-chave que lança uma exceção 
• catch - Enunciados que capturam as exceções  Palavra-chave throw: 
// Lança objeto a ser capturado por valor ou referência. 
 
throw EIntegerRange(0, 10, userValue); 
 
// Lança objeto a ser capturado por um ponteiro. 
 
throw new EIntegerRange(0, 10, userValue); 
191 
Tratamento de exceção 
 Capturando e tratando exceções: 
try { 
 ... 
 if (mystring == NULL) throw "Falha de alocacao"; 
 ... 
 if (n > 9) throw n; 
 ... 
} 
catch (int i) { ... } 
catch (char * str) { ...} 
192 
97 
Tratamento de exceção 
 A captura pode englobar toda uma função: 
int funcao () 
try { 
 
 // ... 
 
 return 0; 
} 
 
catch ( pushOnFull ) { 
 // ... 
} 
catch ( popOnEmpty ) { 
 // ... 
} 
O bloco try está 
englobando 
todo o corpo da 
função. 
 
A captura está 
ocorrendo fora 
do corpo da 
função. 
193 
Tratamento de exceção 
 Capturando qualquer exceção: 
 
 
 
 Especificando as possíveis exceções: 
void f1(); // Pode lançar qualquer exceção. 
void f2() throw(); // Não pode lançar exceções. 
void f3() throw( A, B ); // Pode lançar exceções derivadas// das classes A ou B. 
try { 
... 
} 
catch (...) { ... } 
Os três pontos 
indicam a captura de 
qualquer classe 
de exceção. 
194 
98 
Tratamento de exceção 
class iStack { 
public: 
 // ... 
 
 void pop( int &value ) throw(popOnEmpty); 
 void push( int value ) throw(pushOnFull); 
 
private: 
 // ... 
}; 
Classes das exceções que 
podem ser lançadas 
pelos métodos. 
195 
Tratamento de exceção 
 Aninhando blocos: 
• Blocos try-catch podem ser aninhados. 
• As exceções podem ser relançadas a partir de um catch. 
try { 
 try { 
 ... 
 } 
 catch (int n) { 
 throw; 
 } 
} 
catch (...) { 
 ... 
} 
Exceção relançada 
via throw sem 
argumentos. 
196 
99 
Tratamento de exceção 
 Exceções não capturadas: 
• Exceções não capturadas chamam a função terminate . 
• A função tipicamente encerra o processo corrente e 
informa que ocorreu um término anormal. 
 
  Lidando com a falta de memória: 
• new retorna um ponteiro para void em caso de sucesso. 
• new lança exceção quando não há memória para objeto 
• No C++ padrão é lançada a exceção bad_alloc. 
 
void terminate( ); 
197 
Tratamento de exceção 
• Versões do C++ sem tratamento de exceção retornam 0. 
• Pode-se também retornar 0 no C++ padrão. 
• Usada a palavra nothrow. 
if (int *ptr = new (nothrow) int[100]){ 
 
 // Sucesso na alocação. 
} 
else { 
 // Falha na alocação. 
} 
198 
100 
HERANÇA, POLIMORFISMO E 
TEMPLATES 
199 
Tópicos 
 Sobrecarga de operadores. 
 Herança. 
 Herança simples e múltipla. 
 Exemplos de hierarquias. 
 Ligação estática e dinâmica. 
 Métodos virtuais e virtuais puros. 
 Classes template. 
 Classes containers. 
 200 
101 
Sobrecarga de operadores 
 Conceitos: 
• Possibilita a redefinição do comportamento de operadores. 
• Uso dos objetos torna-se similar ao dos tipos primitivos.  A sobrecarga de um operador deve conter: 
• Tipo do dado a ser retornado. 
• Nome da classe da qual a função é membro. 
• Palavra-chave operator. 
• Símbolo que identifica o operador. 
• Tipos e identificadores dos parâmetros. 
 
201 
Sobrecarga de operadores 
 Número de argumentos: 
• 0 se operador for unário e função definida como membro. 
• 1 se operador for unário e função definida como amiga. 
• 1 se operador binário e função definida como membro. 
• 2 se operador binário e função definida como amiga.  Operadores que podem ser sobrecarregados: 
• Unário + - * ! ~ & ++ -- ( ) -> new delete 
• Binário + - * / % & | ^ << >> = += 
 -= /= %= &= |= ^= <<= >>= == != 
 < > <= >= && || [ ] ( ) 
202 
102 
Sobrecarga de operadores 
 Exemplos de restrições quanto à sobrecarga: 
• Apenas símbolos existentes podem ser sobrecarregados. 
• Não podem ser sobrecarregados ::, .*, . e ?: 
• Não podem ser funções globais =, [ ], ( ) e -> 
• Operadores ( ) [ ] e -> sobrecarregados como membros. 
• Pelo menos um operando é uma classe ou enumeração. 
• Não pode-se modificar o número de operandos original. 
• Não pode-se mudar a precedência dos operadores. 
203 
Sobrecarga de operadores 
class Ponto { 
 private: 
 int x, y; 
 public: 
 Ponto operator + (Ponto p); 
 Ponto operator - (Ponto p); 
 ... 
}; 
 
Ponto Ponto::operator + (Ponto p) { 
 return Ponto(x + p.x, y + p.y); 
} 
 
Ponto Ponto::operator - (Ponto p) { 
 return Ponto(x - p.x, y - p.y); 
} 
... 
Ponto a(1,2), b(3,4), c; 
 
c = a + b; 
Uso do operador 
sobrecarregado. 
Funções são 
membros 
da classe. 
204 
103 
Sobrecarga de operadores 
class Ponto { 
 private: 
 int x, y; 
 public: 
 friend Ponto operator + (Ponto, Ponto); 
 friend Ponto operator - (Ponto, Ponto); 
... 
}; 
 
Ponto operator + (Ponto p1, Ponto p2) { 
 return Ponto(p1.x + p2.x, p1.y + p2.y); 
} 
 
Ponto operator - (Ponto p1, Ponto p2) { 
 return Ponto(p1.x - p1.x, p1.y - p2.y); 
} 
... 
Funções 
são amigas 
da classe 
205 
Sobrecarga de operadores 
class Complexo { 
 private: 
 float r; 
 float i; 
 public: 
 Complexo operator = (Complexo x); 
 Complexo operator + (Complexo x); 
}; 
Complexo Complexo::operator = (Complexo x) { 
 r = x.r; 
 i = x.i; 
 return *this; 
} 
Complexo Complexo::operator + (Complexo x) { 
 Complexo tmp; 
 tmp.r = r + x.r; 
 tmp.i = i + x.i; 
 return tmp; 
} 
Retorno de 
referência 
this. 
 
Retorno de 
cópia do 
objeto local. 
206 
104 
Sobrecarga de operadores 
 Sobrecarga de new e delete: 
• Situações onde é necessário controlar a alocação. 
• Sobrecarga pode ser relativa a uma classe se a função for 
membro da classe. 
• Sobrecarga pode ser global se não for função membro. 
 
void *operator new(long bytes) { 
 ... 
 return ponteiro_para_memória; 
} 
 
void nome_classe::operator delete(void *p) 
 ... 
} 
Sobrecarga 
global. 
 
 
Sobrecarga 
relativa a 
uma classe. 
207 
Sobrecarga de operadores 
 Operadores de inserção << e extração >> : 
• Preferível esses operadores do que as função em stdio.h. 
• Funções printf e scanf não são extensíveis. 
• Funções separam das variáveis as formatações. 
 
 
 
int i; 
 
cin >> i; // Extração. 
 
cout << i; // Inserção. 
208 
105 
Sobrecarga de operadores 
class Coordenada { 
 int x, y; 
 public: 
 friend ostream& operator << (ostream &str, Coordenada coord); 
 ... 
}; 
 
ostream &operator << (ostream &str, Coordenada coord) { 
 str << "Coordenada x : " << coord.x; 
 str << "Coordenada y : " << coord.y; 
} 
... 
cout << coordA; 
Operador de inserção. 
209 
Herança 
 Conceitos: 
• Permite a reutilização do código. 
• Pode ser simples ou múltipla.  Declaração de herança deve conter: 
• Palavra-chave class. 
• Nome da nova classe. 
• Operador : 
• Nomes da classe herdada e do modo de acesso. 
class nome_classe:modo_acesso nome_classe_base { 
 
}; 
210 
106 
Herança 
 Herança simples: 
class nome_da_classe_A { // . . . }; 
class nome_da_classe_B:nome_da_classe_A { //... }; 
class nome_da_classe_C:nome_da_classe_A { //... }; 
A 
B C 
D E 
211 
Herança 
 Modo de acesso: 
• No modo public, os membros públicos na classe base 
permanecem públicos na classe derivada e os membros 
protegidos permanecem protegidos. 
• No modo private, os membros públicos e protegidos na 
classe base se tornam privados na classe derivada. 
• No modo protected, os membros públicos e protegidos 
podem ser usados somente por membros e friends da 
classe derivada e de classes que venham a ser derivadas 
dessa. 
212 
107 
Herança 
• O modo de acesso default é private na herança entre 
classes, restringindo automaticamente a visibilidade dos 
membros nas classes derivadas. 
• O modo de acesso default é public na herança entre 
structs. 
 
 class A : public B { ... } 
class C : protected B { ... } 
class D : private B { ... } 
class E : B { ... } // Privado. 
 
213 
Herança 
 Sobrecarga: BASE 
DERIV 1 
 ativar () 
DERIV 2 
ativar () 
a.ativar () 
 
 
 b.ativar () 
 
 
 
 
 c.ativar () 
214 
108 
Herança 
 Métodos e atributos sobrecarregados: 
• Podem ser acessados a partir das classes derivadas. 
• Usado o operador de resolução de escopo.• Necessário especificar a visibilidade como protected. 
cadastrar( ) 
cadastrar( ) 
215 
Herança 
class Aluno { 
 ... 
 protected: 
 void cadastrar(); 
 ... 
}; 
 
class AlunoEspecial:public Aluno { 
 ... 
 public: 
 void cadastrar(); 
 ... 
}; 
void AlunoEspecial::cadastrar() { 
 ... 
 Aluno::cadastrar(); 
 ... 
} 
216 
109 
Herança 
 Herança múltipla: 
class nome_da_classe_A { // . . . }; 
class nome_da_classe_B { //. . . }; 
class nome_da_classe_C:nome_da_classe_A , 
 nome_da_classe_B {//...}; 
 A B 
C D 
E 
217 
Herança 
 Ambigüidades na herança múltipla: 
• Diferentes classes base tendo membros com mesmo nome. 
• Uma mesma classe base mais de uma vez na hierarquia.  Solução da ambigüidade: 
• Necessário identificar a classe com o membro. 
• Especifica-se a classe do membro. 
• Usa-se o operador de resolução de escopo. 
NomeClasseA::NomeMetodo(); 
NomeClasseB::NomeMetodo(); 
NomeClasseA::NomeAtributo; 
NomeClasseB::NomeAtributo; 
218 
110 
Herança 
 Resolução de ambigüidade: 
class ProfessorOrientador:public Docente, public Funcionario { 
 ... 
}; 
 
class ProfessorCoordenador:public ProfessorOrientador { 
 ... 
 ProfessorOrientador::Docente::cadastrar(); 
 Docente::cadastrar(); 
 Funcionario::cadastrar(); 
 cadastrar(); 
 ... 
}; 
Procura em 
ProfessorCoordenador 
depois em 
ProfessorOrientador 
depois em 
Docente 
e depois em Funcionario. 219 
Herança 
 Herança e declaração using: 
class Docente { 
 ... 
 void cadastrar(int); 
}; 
 
class Funcionario { 
 ... 
 void cadastrar(float); 
}; 
 
class Professor:public Docente, public Funcionario { 
 ... 
 cadastrar(123); 
 ... 
} 
As ambigüidades entre 
métodos de diferentes classes 
base não são resolvidas com 
base nos tipos dos 
argumentos. 
 
 
 
 
Ambigüidade. 
220 
111 
Herança 
class Docente { 
 ... 
 void cadastrar(int); 
}; 
 
class Funcionario { 
 ... 
 void cadastrar(float); 
}; 
 
class Professor:public Docente, public Funcionario { 
 ... 
 using Docente::cadastrar; 
 using Funcionario::cadastrar; 
 ... 
 cadastrar(123); // Invoca Docente::cadastrar 
 cadastrar(1.2); // Invoca Funcionario::cadastrar 
 ... 
} 
Declarações using 
trazem os métodos 
para o mesmo escopo 
possibilitando a 
resolução a partir dos tipos 
dos argumentos. 
221 
Herança 
 Replicação de classes base: 
class Profissional { 
 Profissional *primeiro; 
 ... 
}; 
class Docente:public Profissional { 
 ... 
}; 
class Funcionario:public Profissional { 
 ... 
 void cadastrar(float); 
}; 
class Professor:public Docente, public Funcionario { 
 ... 
} 
Instâncias da 
classe Professor 
terão duas 
listas de 
profissionais. 
222 
112 
Herança 
class Profissional { 
 Profissional *primeiro; 
 ... 
}; 
 
class Docente:public virtual Profissional { 
 ... 
}; 
 
class Funcionario:public virtual Profissional { 
 ... 
 void cadastrar(float); 
}; 
 
class Professor:public Docente, public Funcionario { 
 ... 
} 
As instâncias da 
classe Professor 
terão uma 
lista de profissionais 
devido ao uso de 
classes base virtuais. 
223 
Herança 
 Construtores e destrutores: 
• Podem existir construtores e destrutores em uma classe 
base e nas suas derivadas. 
• O construtor na classe base é invocado primeiro. 
• O destrutor de uma classe derivada é executado antes do 
destrutor da sua classe base. 
• Se um construtor de uma classe base requer argumentos, 
devem ser providos pela classe derivada. 
• Se houver herança múltipla, os construtores são invocados 
seguindo-se a ordem da esquerda para a direita e os 
destrutores da direita para a esquerda. 
224 
113 
Herança 
class ElementoGrafico { 
... 
 public : 
 ElementoGrafico(int, int); 
 ~ElementoGrafico(); 
}; 
 
class Retangulo:public ElementoGrafico { 
... 
 public : 
 Retangulo(int, int, int); 
 ~Retangulo(); 
}; 
 
Retangulo::Retangulo(int x, int y, int z):ElementoGrafico(x,y) { 
... 
} 
Construtor que requer 
parâmetros sendo 
explicitamente 
invocado. 
225 
Herança 
A 
B C 
D E 
Ordem de 
execução 
dos métodos 
construtores. 
Ordem de 
execução 
dos métodos 
destrutores. 
226 
114 
Herança 
class ElementoGrafico { 
 
 public : 
 ElementoGrafico(); 
 ~ElementoGrafico(); 
... 
}; 
... 
 
 
class Retangulo:public ElementoGrafico { 
 public : 
 Retangulo(); 
 ~Retangulo(); 
... 
}; 
... 
{ 
... 
ElementoGrafico elemento; 
Retangulo retangulo; 
... 
} 
 ElementoGrafico() 
~ElementoGrafico() 
 ... 
 ElementoGrafico() 
 Retangulo() 
~Retangulo() 
~ElementoGrafico() 
227 
Herança 
class ElementoGrafico { 
 
 public : 
 ElementoGrafico(); 
 ~ElementoGrafico(); 
... 
}; 
... 
 
 
class Retangulo:public ElementoGrafico { 
 public : 
 Retangulo(); 
 ~Retangulo(); 
... 
}; 
... 
ElementoGrafico *ptrA; 
... 
ptrA = new ElementoGrafico(); 
delete ptrA; 
... 
Retangulo *ptrB; 
ptrB = new Retangulo(); 
delete ptrB; 
... 
 ElementoGrafico() 
~ElementoGrafico() 
 ... 
 ElementoGrafico() 
 Retangulo() 
~Retangulo() 
~ElementoGrafico() 
228 
115 
Herança 
 Método virtual: 
• Definido em uma classe. 
• Pode se redefinido em classes derivadas. 
• Identificado pela palavra-chave virtual. 
• Novas declarações são feitas nas classes derivadas. 
• Pode facilitar a evolução futura. 
• Possibilita a especificação de interfaces.  Classes sem métodos virtuais: 
• Classe tipicamente projetadas para não serem classes base 
em hierarquias. 
229 
Herança 
class Lista { 
 public : virtual Bool inserir (int); 
... 
}; 
 
class Conjunto : Lista { 
 public : Bool inserir (int); 
... 
}; 
Declaração de 
um método 
virtual. 
 
 
 
 
 
 
 
Presença do 
método em 
uma subclasse. 
230 
116 
Herança 
 Construtores e destrutores: 
• Os métodos construtores não podem ser métodos virtuais. 
• Os métodos destrutores podem ser virtuais.  Destrutores não virtuais e virtuais: 
• Quando é destruído um objeto de uma classe derivada 
referenciado por um ponteiro para a classe base, o 
resultado é indefinido se o destrutor na classe base for não 
virtual. Tipicamente o destrutor da classe derivada não é 
invocado. 
231 
Herança 
class ElementoGrafico { 
 
 public : 
 ElementoGrafico(); 
 ~ElementoGrafico(); 
... 
}; 
... 
 
 
class Retangulo:public ElementoGrafico { 
 public : 
 Retangulo(); 
 ~Retangulo(); 
... 
}; 
... 
ElementoGrafico *ptr; 
... 
ptr = new ElementoGrafico(); 
delete ptr; 
... 
ptr = new Retangulo(); 
delete ptr; 
 ElementoGrafico() 
~ElementoGrafico() 
 ... 
 ElementoGrafico() 
 Retangulo() 
~ElementoGrafico() 
232 
117 
Herança 
class ElementoGrafico { 
 
 public : 
 ElementoGrafico(); 
 virtual ~ElementoGrafico(); 
... 
}; 
... 
 
 
class Retangulo:public ElementoGrafico { 
 public : 
 Retangulo();