Programação Orientada A Objetos

 Tutorial POO 
Tutorial POO
Tutorial POO
1ª Edição
Criado em fevereiro de 2007.
Por Marcelo Cavaco (marcelocavaco@click21.com.br)
Programação Orientada a Objetos

Programaçao Orientada a Objetos
O Mundo ao Alcance de suas Mãos
Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

 Tutorial POO 
Considerações Iniciais
Já vi algumas pessoas tentarem se aventurar em programação, mas sem obter sucesso. Qual a
causa disso? O desenvolvimento de sistemas é uma tarefa bastante complexa. Além disso,
muitas pessoas inexperientes na programação não conhecem os conceitos básicos de orientação
a objetos.
Este será o foco deste tutorial. Demonstrar os conceitos da programação orientada a objetos e
dar sugestões de como programar melhor, ou seja, as boas práticas de programação.
Este tutorial foi revisado extensivamente, mas, apesar disso, podem ocorrer erros. Por favor me
avisem caso encontrem algum.
Como já é de praxe, gostaria de lembrar que não estou aqui querendo afirmar nada sobre nada
nem ninguém. Não quero ofender nenhum leitor, ou o vizinho, ou o cachorro do vizinho, ou o
papagaio de qualquer um que seja. Não estou tentando provar nada. Não sou “guru” da
programação. Portanto, tenham paciência...
E me desculpem por qualquer tipo de transtorno e muito obrigado aos que me ajudaram e
incentivaram.
Fora isso, boa leitura...

 Tutorial POO 
Cavaco's Creations
Você pode copiar, distribuir, exibir, executar ou criar obras derivadas sob as seguintes condições:
Atribuição: Você deve dar crédito ao autor original, da forma especificada pelo
autor ou licenciante.
Uso Não-Comercial: Você não pode utilizar esta obra com finalidades comerciais.
Compartilhamento pela mesma Licença: Se você alterar, transformar, ou criar

outra obra com base nesta, você somente poderá distribuir a obra resultante sob
uma licença idêntica a esta.
Para cada novo uso ou distribuição, você deve deixar claro os termos da licença desta obra.
Qualquer uma destas condições podem ser renunciadas, desde que você obtenha permissão do
autor. Qualquer direito de uso legítimo (ou "fair use") concedido por lei, ou qualquer outro direito
protegido pela legislação local, não são em hipótese alguma afetados pelo disposto acima.
Este é um sumário para leigos da Licença Jurídica (que pode ser obtida na íntegra em
http://www.4shared.com/file/11081399/19b3184f/Licena_de_Uso.html).
Termo de exoneração de responsabilidade
Esta Licença Simplificada não é uma licença propriamente dita. Ela é apenas uma referência útil
para entender a Licença Jurídica (a licença integral). Ela é uma expressão dos seus termos-chave
que pode ser compreendida por qualquer pessoa. A Licença Simplificada em si não tem valor
legal e seu conteúdo não aparece na licença integral. A Cavaco's Creations não é um escritório de
advocacia e não presta serviços jurídicos. A distribuição, exibição ou inclusão de links para esta
Licença Simplificada não estabelece qualquer relação advocatícia.

 Tutorial POO 
Agradecimentos
Agradeço à:
Minha família, por me criar e aturar...

Meus amigos de RPG, por jogarem comigo...
Meus colegas de programação por viverem 8 horas por dia comigo...
Aos amigos internautas, adquiridos nas horas de navegação e noites e madrugadas insones...

 Tutorial POO 
Sumário
Tutorial POO............................................................................. 1
Considerações Iniciais................................................................ 2
Cavaco's Creations..................................................................... 3
Agradecimentos......................................................................... 4
Sumário................................................................................... 5
Índice de Ilustrações.................................................................. 7
Como Utilizar este Tutorial.......................................................... 8
Começando............................................................................... 9
Programação Orientada a Objetos.............................................. 11
O que é Programação Orientada a Objetos? ..............................................11
E o que são Objetos?..............................................................................12
Mas, afinal, qual é a diferença entre Classe e Objeto?................................. 13
Conceitos Básicos de POO....................................................................... 14
Abstração.............................................................................................................. 15
Encapsulamento...................................................................................................... 15
Proteção da informação (information/data hiding) ....................................................... 17
Sobreposição (Overriding)........................................................................................ 19
Passagem de mensagens (parâmetros)...................................................................... 20
Delegação ............................................................................................................. 20
Classes/objetos/instâncias........................................................................................ 21
Herança (Generalização/Especialização) .................................................................... 21
Polimorfismo ......................................................................................................... 23
Relacionamentos..................................................................................................... 23
Uma palavra de cautela ......................................................................... 24
Programar Orientado a Objetos é modelar ................................................24

 Tutorial POO 
Criando Objetos....................................................................... 25
Identificação de substantivos ..................................................................25
Identificação das classes.........................................................................27
Boas Práticas de Programação................................................... 29

Critérios para criação de funções, procedimentos e métodos........................29
Programação Defensiva ......................................................................... 30
Recomendações sobre dados................................................................... 30
Escopo das variáveis.............................................................................. 31
Conceito de Memória (Variáveis)..............................................................32
Nomes de variáveis e constantes............................................................. 32
Nomes de funções, procedimentos e métodos............................................33
Estruturas de controle: testes (ifs)........................................................... 33
Ifs simples............................................................................................................. 33
Ifs aninhados.......................................................................................................... 33
Estruturas de controle: loops...................................................................34
Layout de programa .............................................................................. 34
Princípios............................................................................................................... 34
Indentação das estruturas de controle...................................................... 35
Comentários..........................................................................................36
Comentários de linha .............................................................................................. 36
Refletindo sobre as boas práticas............................................................. 37
Uma última recomendação ..................................................................... 37
Você sabe o que esse código faz? ............................................................38
Conclusão............................................................................... 48

 Tutorial POO 
Índice de Ilustrações
Figura 1: Diferença entre Classes e Objetos...................................................................................... 13
Figura 2: Programação Convencional................................................................................................ 15
Figura 3: Representação de uma classe/objeto.................................................................................. 15
Figura 4: Exemplo de Objeto........................................................................................................... 16
Figura 5: Objeto lâmpada............................................................................................................... 16
Figura 6: Data hiding..................................................................................................................... 17
Figura 7: Analogia com um Iceberg.................................................................................................. 18
Figura 8: Passagem de mensagens.................................................................................................. 20
Figura 9: Exemplo de Herança........................................................................................................ 21
Figura 10: Outro exemplo de Herança.............................................................................................. 21
Figura 11: Definição de Herança...................................................................................................... 21
Figura 12: Exemplo de uma Classe.................................................................................................. 28
Figura 13: Exemplo detalhado de uma Classe.................................................................................... 28

 Tutorial POO 
Como Utilizar este Tutorial

Para aproveitar da melhor forma possível este tutorial, devemos saber para que ele serve. Este
documento é onde estaremos exemplificando e demonstrando alguns dos conceitos da
programação orientada a objetos (POO).
Este tutorial é de nível básico. A leitura deste tutorial é aconselhável para todos os leigos no
universos de desenvolvimento de sistemas e programação.
Existem diversos modelos de desenvolvimento de sistemas, mas o modelo que mais utilizado
atualmente é a orientação a objetos. Portanto, veremos como chegar no âmago deste
paradigma.
Este tutorial deve ser compreendido antes de qualquer aprofundamento em qualquer linguagem
orientada a objeto (Java, C, dentre outros, incluindo o Ruby). Principalmente se você se
considera leigo no assunto. Agora, vamos deixar de “enrolar” e partir pro que interessa.

 Tutorial POO 
Começando
A programação orientada a objetos (POO) é um paradigma de programação que tenta aproximar
o código fonte da realidade. Antigamente, o que existia era o paradigma procedural, ou seja,
procedimentos seqüenciais. Este paradigma antigo distanciava a programação do mundo real,
pois uma seqüência lógica de procedimentos não se mostrava realista o suficiente.
No mundo real o que existem são objetos. Exemplo: Um copo! Para que serve este objeto? Ele
pode ser enchido com algum líqüido, ou esvaziado, além de possuir um volume máximo, etc. Na
programação orientada a objetos (POO) o Copo é uma classe, a ação de Encher o Copo e
Esvaziar o Copo são dois métodos que fazem duas coisas distintas e Volume Máximo é um
atributo. Este é o fator que diferencia a programação orientada a objetos (POO) de outros
paradigmas.
Por causa deste diferencial, a programação orientada a objetos (POO) se aproxima mais do
mundo como nós realmente o vemos.
Os computadores não são apenas máquinas, mas ferramentas de amplificação da mente. As

ferramentas deveriam se parecer menos com a máquina e mais com nossas mentes (com o
mundo real). Para tanto, devemos buscar a redução no desnível entre as abstrações e a
implementação e utilizar abstrações básicas como os algoritmos e tipos abstratos de dados.
As soluções para se implementar “Tipos Abstratos de Dados” (TADs):
a) tipos compostos, funções e procedimentos;

b) módulos;
c) classes/objetos.
As classes e objetos são uma forma de TAD que é muito utilizado atualmente, mas... O que leva
um programador a mudar do paradigma procedimental para um novo?

 Tutorial POO 
A resposta esta na complexidade crescente dos sistemas e nas limitações da capacidade humana
de compreensão de um sistema como um todo. Um sistema fica complexo quando se usa um
conjunto grande de tarefas e diversos de comportamentos tendo um longo ciclo de vida e muitos
usuários dependendo dele. A complexidade está na quantidade e diversidade.
Tudo o que vemos à nossa volta são objetos. Estamos acostumados a ver objetos (classes) e
saber imediatamente para que eles servem (seus métodos) e quais as suas características
(atributos). Por causa disso fica muito mais fácil compreender o sistema como um todo quando
se usa a POO.
Curiosidade:
Paradigma é um conjunto de regras que estabelecem fronteiras e descrevem como resolver os

problemas dentro destas fronteiras. Os paradigmas influenciam nossa percepção; ajudam-nos a
organizar e a coordenar a maneira como olhamos para o mundo...
Além disso, os paradigmas (na ciência da computação) explicam como os elementos que
compõem um programa são organizados e como interagem entre si.
10

 Tutorial POO 
Programação Orientada a Objetos
O que é Programação Orientada a Objetos?
É um paradigma avançado de programação que engloba um conjunto de teorias, padrões e

métodos que juntos representam uma forma de organizar conhecimento. Este paradigma é
baseado no conjunto de abstrações de classes e objetos e empacota dados e procedimentos em
um mesmo elemento (objeto). Os objetos se comunicam pela passagem de mensagens.
Como nós já sabemos, no mundo real, tudo é objeto! Estes objetos se relacionam entre si de
diversas maneiras. Exemplo: Copo e Garrafa. O objeto garrafa tem os mesmos métodos e
atributos do copo, mas com valores diferente. Quando se esvazia a garrafa pode-se estar
enchendo o copo (se o copo não estiver cheio). Esta iteração entre os objetos é muito freqüente
na POO. Um programa orientado a objetos é estruturado como uma comunidade de agentes que
interagem entre si. Os agentes são os denominados objetos. Cada objeto tem um papel a
cumprir e oferece um serviço ou realiza uma ação que é usada por outros membros da
comunidade, ou seja, outros objetos (o copo e a garrafa).
11

 Tutorial POO 
E o que são Objetos?
Um objeto é uma variável... Ele armazena dados. Então uma estrutura de variáveis é um objeto,
mas um objeto pode ser mais que uma estrutura de variáveis: você pode pedir que determinadas
operações sejam feitas sobre os objetos e suas variáveis.
Um objeto possui então atributos (dados) e comportamentos (métodos, procedimentos, funções,

que atuam sobre ele). Exemplos de objetos: cachorros, carros, videocassetes, edifícios,
funcionários, indústrias, dentre outros.
Um programa é um conjunto de objetos dizendo uns para os outros o que fazer através do envio
de mensagens. Concretamente, pode-se pensar nas mensagens como sendo chamadas a funções
que pertencem a um objeto em particular.
Cada objeto tem a sua própria região de memória, que pode ser composta por outros objetos,
também. Exemplo: o objeto carro pode ser composto pelos objetos lataria, rodas, motor, dentre
outros.
12

 Tutorial POO 
Mas, afinal, qual é a diferença entre Classe e Objeto?
Classes e objetos são praticamente a mesma coisa, com algumas pequenas diferenças. As classe
e objetos possuem uma combinação de dados e operações em um elemento único. A diferença
mais visível é a seguinte:
a) Classe: é definição do tipo, ou seja, é o código fonte de seu objeto;

b) Objeto: é cada instância derivada da classe (é a classe sendo executada).
Figura 1: Diferença entre Classes e Objetos.
Um exemplo real da utilização de objetos que podemos usar é a montagem de um computador.

Um computador é composto por vários componentes:
a) placa-mãe;
b) CPU;
c) placa de vídeo;
d) disco rígido;
e) teclado, etc.
13

 Tutorial POO 
Cada componente é bastante sofisticado, mas o usuário não precisa saber como funciona
internamente, pois cada componente é independente dos demais. Para quem está montando um
computador, interessa apenas como os componentes interagem entre si, ou seja:
a) A placa de vídeo encaixa no slot ?

b) O monitor funciona com essa placa ?
c) A CPU é compatível com a placa-mãe ?
d) O disco rígido cabe na CPU ?
É exatamente isso que fazemos ao utilizar classes (objetos). Nós sabemos que elas existem e
como interagem, então usamos elas de forma lógica e intuitiva.
Conceitos Básicos de POO
Agora vamos nos aprofundar na POO um pouco mais conhecendo alguns dos princípios da
Orientação a Objetos. Os principais são:
a) Abstração;
b) Encapsulamento;
c) Proteção/ocultação da informação (information/data hiding);
d) Sobreposição (Overriding);
e) Passagem de mensagens;
f) Delegação;
g) Classes/objetos/instâncias;
h) Herança;
i) Polimorfismo;
j) Relacionamentos.
14

 Tutorial POO 
Abstração
Abstração, nada mais é do que um conceito de POO que diz o seguinte: Devemos representar
numa entidade apenas os atributos mais importantes para um contexto particular. A abstração de
sub-programas permitem especificar O QUE deve ser feito, sem detalhar COMO.
Este é um conceito CRUCIAL de programação orientada a objetos. Com ele podemos

compreender grandes programas sem ler milhares de linhas de código.
Encapsulamento
A programação convencional separa dados e procedimentos.
Dados Procedimentos
Figura 2: Programação Convencional.
Nos objetos a iteração é maior e contém tanto os dados quanto a descrição das operações que
manipularão ou alterarão aqueles dados.
Representação de uma classe/objeto
Operações / métodos / interface

(público)
Serviços
Dados
Dados / propriedades / atributos

(privado)
Figura 3: Representação de uma classe/objeto.
15

 Tutorial POO 
Exemplo de objeto: Lâmpada.
Operações:
• ligar
Serviços • desligar
Dados
Dados:
• ligada (s/n)
• potência
• voltagem
Figura 4: Exemplo de Objeto. Figura 5: Objeto lâmpada.
O encapsulamento é definido como uma técnica para minimizar as interdependências entre

módulos, através da definição de interfaces externas (serviços). É como se fosse uma “Caixa
preta”, ou seja, não é necessário saber como funciona internamente, mas sim como utilizar.
A interface (pública) de um objeto declara todas as operações permitidas. Todo o acesso aos
dados é feito através da chamada a um método definido pelo objeto. As mudanças na
implementação interna do objeto (que preservem a sua interface externa) não afetam o resto do
sistema.
Benefícios
a) Segurança: protege os objetos de terem seus atributos corrompidos por outros objetos.
b) Independência: “escondendo” seus atributos, um objeto protege outros de complicações
de dependência da sua estrutura interna.
16

 Tutorial POO 
Proteção da informação (information/data hiding)
O objeto que contém os dados (atributos do objeto) define que serviços estão disponíveis para
outros objetos, ou seja, você só pode usar os métodos do objeto que o programador
disponibilizou para uso. Outra característica, é que os demais objetos podem não ter acesso a
dados individuais. A informação sobre como os serviços são implementados também pode ser
protegida.
Serviços
Dados
Figura 6: Data hiding.
Não é possível chegar aos dados diretamente. Para manipular os dados, é necessário recorrer aos
serviços (métodos, variáveis públicas, dentre outros).
17

 Tutorial POO 
Podemos observar melhor o funcionamento do data hiding através da analogia do Iceberg.
Figura 7: Analogia com um Iceberg.
Observe a diferença do que é visto pelo cliente e do que realmente existe por trás da interface de
nosso programa. Note que os dados ficam escondidos. Esta é uma forma de proteção dos dados.
Tudo que o cliente vê é através da interface e portanto o cliente não manipula os dados.
18

 Tutorial POO 
Sobreposição (Overriding)
Algumas vezes, durante o processo de especialização, a sub-classe precisa modificar o

comportamento herdado da super-classe. Esta modificação é perfeitamente possível com a
sobreposição de métodos. Quando um método é sobreposto, não há nenhuma alteração na
super-classe. A sobreposição modifica somente o método herdado. Esta operação é específica da
sub-classe.
Para utilizar este conceito, a declaração do método deve ser feita com a mesma assinatura da
super-classe. O cliente que instancia a sub-classe não consegue mais acessar o método que foi
sobreposto da super-classe.
19

 Tutorial POO 
Passagem de mensagens (parâmetros)
Um objeto se comunica com outros pelo envio de mensagens. Uma ação é iniciada por uma
requisição de serviços (mensagem) e uma resposta é enviada para um objeto específico. Essa
ação é uma operação que utiliza ou altera os dados do objeto. A implementação da ação é
denominada método.
Serviços
Dados
Receptor (servidor)
Serviços
Emissor (cliente)
Dados
Figura 8: Passagem de mensagens.
As mensagens podem ser definas como sendo chamadas a funções que pertencem a um objeto
em particular. As mensagens identificam os métodos a serem executados no objeto receptor.
Para invocar um método, deve-se enviar uma mensagem para o objeto desejado. Para enviar
uma mensagem, deve-se identificar o objeto que receberá a mensagem, identificar o método que
o objeto deverá executar, passar os argumentos requeridos pelo método.
Delegação
O trabalho é transferido, pelo envio de mensagens, de um objeto (cliente) para outro (servidor).
Da perspectiva do cliente, o servidor é quem deve executar os serviços que o cliente necessita.
Trabalho é transferido continuamente até que atinja o objeto que possui os dados e os métodos
para executar a tarefa.
20

 Tutorial POO 
Classes/objetos/instâncias
Todo objeto é criado a partir (é uma instância) de uma classe. Geralmente um objeto é a classe
sendo executada no aplicativo (criadas em tempo de execução). Diversos dados (atributos)
podem ser associados a cada objeto. As classes normalmente contêm atributos gerais e
independentes das diversas instâncias (atributos de classe).
Herança (Generalização/Especialização)
Nada mais é que uma relação entre classes (tipos de objetos).

Este tipo de relação permite que classes compartilhem código.
Uma classe pode “herdar” código (ex: métodos) de outra e a
classe herdeira pode criar uma nova versão do código antigo
versão que seja mais genérica ou mais específica que a versão
original da atividade.
Através da herança, desenvolvedores podem construir novas

classes usando como base classes já existentes. Uma classe
base (super-classe) é utilizada como modelo para definir uma
casse derivada (sub-classe). As novas classes “herdam” tanto
as funções como os atributos da classe pré-existente. Figura 9: Exemplo de Herança.
Figura 11: Definição

de Herança
Figura 10: Outro exemplo de Herança
21

 Tutorial POO 
Em relação à classe base, a classe derivada pode ser alterada através:
a) da adição de novos membros de dados e novas funções membros (métodos);

b) da modificação de membros já existentes;
c) da modificação dos privilégios de acesso aos mesmos.
Normalmente, essas alterações geram uma classe que representa um subconjunto da classe
base, por isso, muitas vezes denominada “especialização”.
Em algumas linguagens temos a herança múltipla, onde uma dada classe pode herdar de mais de
uma classe .
Vantagens da herança múltipla:

a) encoraja o reuso de classes;
b) imita o modo das pessoas pensarem (um estagiário é estudante e trabalhador ao mesmo
tempo).
Desvantagens da herança múltipla:

a) perda da simplicidade conceitual e de implementação;
b) definição da regra de ativação de métodos herdados.
Como regra geral, deve-se evitar seu uso.
22

 Tutorial POO 
Polimorfismo
Uma certa operação, muitas vezes pode ser definida de forma equivalente para atributos de
entrada (parâmetros) de formas diferentes. Polimorfismo permite que diversos métodos (que
difiram em suas assinaturas/cabeçalhos) recebam o mesmo nome, ou seja, uma função membro
de uma classe derivada pode ser sobrescrita para produzir um comportamento diferenciado para
a sub-classe. Isso permite que métodos sejam identificados pelo seu efeito/finalidade de forma
uniforme, simplificando a tarefa do programador.
Exemplos:
area_triangulo = calcula_area(lado1,lado2,lado3);
area_triangulo = calcula_area(base,altura);
area_triangulo = calcula_area(registro_triangulo);
Resumindo:
Polimorfismo é o processo pelo qual diferentes implementações de métodos podem ser acessadas
pelo mesmo nome, além de permitir aplicar a mesma operação (conceitual) a objetos de tipos
diferentes.
Relacionamentos
Mecanismo pelo qual um objeto toma conhecimento dos demais em um programa. Basicamente,
entre os atributos de um objeto deve haver informação que lhe permita identificar um outro
objeto. Há dois (2) tipos básicos de relacionamento, que são:
a) Associação: objetos independentes trocam mensagens;

b) Agregação: um objeto é composto por/contém outros objetos.
23

 Tutorial POO 
Uma palavra de cautela
Programar um computador é uma das tarefas mais difíceis que se pode enfrentar. A orientação a
objetos não muda isso. Ela apenas oferece um conjunto de abstrações, métodos e padrões que
viabilizam o desenvolvimento de programas melhores. Não pense que por utilizar um paradigma
novo e mais funcional, tudo será facilitado. Portanto, um estudo minucioso é sempre bom para
um aprendizado eficiente.
Programar Orientado a Objetos é modelar
Um programa é um modelo executável de algum domínio ou atividade do mundo real. É mais

fácil quando se usa representações, abstrações e conceitos apropriados. Por isso que a
programação orientada a objetos surgiu. Para que possamos modelar nossas idéias num
aplicativo funcional e simples.
24

 Tutorial POO 
Criando Objetos
Identificação de substantivos
Primeiro devemos obter (ou produzir) uma narrativa textual que contenha uma descrição do
problema a ser resolvido. Para tanto podemos recorrer a casos de uso (exemplo: RUP ou Praxis),
estatísticas, categorias de itens, dentre outros. Sempre devemos usar substantivos, pronomes e
orações substantivas para identificar objetos e classes. Fora isso, os verbos e locuções verbais
devem ser usadas para identificar serviços e/ou métodos.
Na análise, devemos eliminar nomes relativos à implementação, ou seja, nomes relativos a

relatórios, arquivos, estruturas de dados. No projeto, detalhes de implementação começam a
aparecer. Depois devemos eliminar nomes não conexos com a missão do produto, por exemplo,
nomes relativos ao negócio mas não ao produto.
Exemplo de análise de uma operação:
a) O caixeiro faz a abertura da venda.

b) O caixeiro registra os itens vendidos, informando a identificação e a quantidade do item.
c) O Sistema totaliza a venda para o cliente da mercearia.
d) O caixeiro encerra a venda.
e) O Sistema emite o ticket de caixa para o cliente da mercearia.
f) O caixeiro registra a forma de pagamento.
g) O Sistema faz a baixa no estoque das mercadorias vendidas.
25

 Tutorial POO 
Substantivos descobertos (em letras vermelhas):
a) abertura;
b) venda;
c) item vendido;
d) identificação;
e) quantidade;
f) cliente da mercearia;
g) ticket de caixa;
h) forma de pagamento;
i) baixa;
j) estoque;
k) mercadoria.
Análise das candidatas a classes:
a) abertura operação
b) venda provável classe
c) item vendido provável classe (item de venda)
d) identificação atributo de item de venda
e) quantidade atributo de item de venda
f) cliente da mercearia entidade fora de escopo
g) ticket de caixa relatório (item de implementação)
h) forma de pagamento atributo de venda
i) baixa operação
j) estoque possível classe (conj. de itens cadastrados)
k) mercadoria provável classe
26

 Tutorial POO 
Identificação das classes
Agora, vamos ver como devemos identificar nossas classes, ou seja, como dar nomes às classe
que vamos criar.
Denominação das classes: Usar nomes significativos.
• geralmente substantivos singulares, com ou sem adjetivo;

• devem caracterizar a abstração que a classe representa;
• evitar nomes vagos ou ligados à metodologia (classe, tipo etc.).
Vejamos agora alguns problemas na criação de classes e a solução para estes problemas.
• classes com nomes semelhantes e documentação parecida: Combinar as classes;

• classes com documentação muito longa: Dividir a classe;
• classes difíceis de denominar ou documentar: Necessita-se de mais análise.
Objetos podem ser de três tipos:
a) objetos com classe indeterminada;

b) objetos com classe determinada e denominação própria;
c) objetos anônimos.
De forma geral, classes são identificadas com três partes:
a) Nome;
b) Atributos (dados);
c) Operações (métodos).
27

 Tutorial POO 
Vejamos um exemplo simplificado de classe:
Figura 12: Exemplo de uma Classe
Posteriormente, a classe pode ser representada com mais detalhes:
Figura 13: Exemplo detalhado de uma Classe.
28

 Tutorial POO 
Boas Práticas de Programação
Critérios para criação de funções, procedimentos e métodos
a) isolar operações e expressões complexas;

b) aumentar a legibilidade do código;
c) ocultar detalhes de implementação (TADs);
d) ocultar acessos a dados globais, se forem permitidos;
e) evitar duplicação de código;
f) promover reutilização de código.
Além disso devemos desenvolver com coesão. Coesão é o nível de relacionamento entre as
operações pertencentes a uma dada rotina, sendo que diferentes tipos de relacionamento
identificam diferentes níveis de coesão. Nossas rotinas, quando bem planejadas, devem possuir
uma coesão forte.
As principais formas de coesão são:
a) funcional: ações relacionadas a uma única tarefa;

Boa
Prática b) seqüencial: seqüência de tarefas correlatas;
c) procedimental: tarefas ordenadas mas não correlatas;
Evite
d) lógica: executa uma dentre várias tarefas de acordo com um parâmetro.
29

 Tutorial POO 
Programação Defensiva
“Lei de Murphy: se algo pode dar errado, dará”.
Inclua código para identificar situações de erro extremas (que não deveriam ocorrer se o
programa estivesse certo). Isso evita situações com erros de difícil identificação.
Exemplo:
Os Bitmaps são armazenados em arquivos. Estes arquivos devem ser carregados para variáveis
antes de serem exibidos. Caso o arquivo não esteja disponível, a carga dele gera um lixo. A
exibição deste lixo causa o fim do programa (aborta a execução do aplicativo). Para evitar este
tipo de problema, crie um tratamento de erro que verifica se o arquivo está disponível antes de
exibi-lo.
Recomendações sobre dados
Agora, vamos ver algumas sugestões para a manipulação/criação de tipos de dados (variáveis,
constantes, estruturas, etc).
Tipos em geral:
a) usar constantes no lugar de literais (exceto 0 e 1);

b) explicitar todos os casos de conversão de tipo.
Tipos inteiros e ponto flutuante:
a) verificar se o valor dos divisores não pode ser 0;

b) prever casos de “truncamento” e estouro (overflow).
30

 Tutorial POO 
Tipo ponto flutuante:
a) evitar somas de magnitudes muito diferentes;

b) evitar comparações de igualdade;
c) considerar erros de arredondamento.
Tipos booleanos:
a) nomes devem ajudar na documentação;

b) dividir testes complexos com variáveis intermediárias;
c) não é necessário fazer comparações com true/false.
if (terminou) é melhor que if (termino=true)

while (not achou) é melhor que while (result=false)
Escopo das variáveis
O que seria um escopo de variável? É basicamente o local onde a variável pode ser usada, ou
seja, é faixa do programa na qual uma variável está acessível. Normalmente o escopo de uma
variável se inicia na declaração da mesma e termina no fim do bloco que a contém. Em blocos
aninhados, uma nova declaração “oculta” a variável definida em um bloco mais externo. Cada
variável deve ter o escopo mais limitado possível. Lembre-se que cada variável ocupa um espaço
de memória diferente. Economizar nas variáveis, evita gastar toda a memória do computador.
31

 Tutorial POO 
Conceito de Memória (Variáveis)
Cada variável está ligada a uma posição de memória. Muitos detalhes referentes a isso podem
interferir nosso modo de programar. As características mais importantes sobre variáveis que
devemos saber são:
a) Uma variável corresponde a uma posição na memória do computador;

b) Cada variável possui um nome, tipo, tamanho e valor;
c) Quando um novo valor é atribuído a uma variável, o valor anterior é sobrescrito;
d) Ler valores de variáveis não as destrói, nem “zera” seu valor.
Já as variáveis globais tendem a introduzir sérios problemas de acoplamento. Seu uso deve ser
apenas quando a rotina requerer manutenção de valores comuns ao programa inteiro ou quando
os dados que precisam chegar a rotinas profundas. Quando usadas, as variáveis globais
requerem algumas precauções:
a) Usar convenção que torne óbvios os nomes globais;

b) Manter uma lista comentada das variáveis globais;
c) Restringir os acessos a poucas funções;
d) Não agrupar artificialmente em uma estrutura monstro.
Nomes de variáveis e constantes
a) Devem ser consistentes (inclusive em idioma);

b) Descrevem elementos do problema (não da solução);
c) Descrevem o conteúdo e/ou uso do elemento;
d) Em nomes compostos, separar as palavras constituintes de forma clara e objetiva.
Exemplos: SaldoFinal, shipLog, server_address;
e) Evitar abreviaturas e nomes longos demais (Devem ser diferenciáveis pelos primeiros 15
caracteres);
f) Devem ser pronunciáveis (teste do telefone).
32

 Tutorial POO 
Nomes de funções, procedimentos e métodos
Agora, vamos ver algumas sugestões para nomear funções, procedimentos e métodos.
a) Devem descrever o que a rotina faz (verbos fortes). Exemplo: Relatório.Imprimir();

b) Operações semelhantes devem corresponder a nomes semelhantes (obter, consultar);
c) Podem ser longos, mas não demais.
Estruturas de controle: testes (ifs)
Ifs simples
Os Ifs devem sempre seguir estas 3 (três) regras básicas:
a) Primeiro caso normal, depois exceções;

b) Caso normal depois do if, e não depois do else;
c) Se não houver cláusula else, comentar por quê.
Ifs aninhados
Sobre os Ifs aninhados podemos dizer o seguinte:
a) Devemos minimizar os níveis de aninhamento;

b) Retestar condições se isso reduzir o aninhamento;
c) Passar código profundamente aninhado para rotina independente ou redesenhar como
cadeias.
33

 Tutorial POO 
Estruturas de controle: loops
Usar tipo adequado à iteração (for, while, etc.):
a) Entrada deve ocorrer em um único ponto;

b) Código de iniciação deve vir logo antes do loop;
c) O ponto e a condição de saída devem ser claros.
Cada loop deve, preferencialmente:
a) Executar apenas uma tarefa;

b) Caber em uma tela ou um folha de listagem;
c) Usar “no máximo” três níveis de aninhamento.
Layout de programa
Princípios
Os princípios básicos para organização do layout do código de um programa são:
a) Deve refletir a estrutura lógica de forma consistente;

b) Objetivo principal é a legibilidade, não a estética;
c) O tamanho máximo das linhas de código não deve exceder 80 caracteres (mesmo se sua
tela for de 21'');
d) Usar linhas em branco para separar blocos.
34

 Tutorial POO 
Indentação das estruturas de controle
A indentação também tem algumas regras para a “boa prática de programação”. São elas:
a) Ocupar de dois a quatro espaços (aconselho usar 3);

b) Evitar usar tabulação;
c) Consistente, sem dupla indentação.
Exemplo errado:
case $idade
when 0 .. 18
"criança"
else
"adulto"
end
Exemplo correto:
case $idade
when 0 .. 18
"criança"
else
"adulto"
end
35

 Tutorial POO 
Comentários
Os comentário, devem ser:
a) Feitos enquanto se codifica, e alterados com o código;

b) Focalizam o “porquê”;
c) Referentes a blocos de instruções e não à instruções individuais;
d) Fáceis de modificar;
e) Evitar comentários óbvios, obsoletos, irrelevantes, auto promocionais, insultos, obscenos,
preconceituosos, etc;
f) Atualmente, estamos na era da redução dos comentários, pois devemos criar um código
auto explicado.
Cabeçalhos de métodos e classes devem descrever as entradas, saídas e hipóteses sobre essa
unidade, não o seu conteúdo.
Algumas coisas para por em comentários de cabeçalhos: finalidade, parâmetros, problemas

conhecidos, valor de retorno, exceções.
Comentários de linha
Agora, vamos ver algumas regras para os comentários de linha:
a) Devem ser evitados (tentem a repetir a instrução);

b) Aparecem no final das linhas de código (instrução # comentário);
c) Não devem ser usados em em linhas isoladas (sem uma instrução) e para comentários
que se estendem por várias linhas;
d) Podem ser usados em alguns casos:
1. para comentar declarações de dados;
2. para anotações de manutenção;
3. para marcar fim de blocos ( end # if result=true ).
36

 Tutorial POO 
Refletindo sobre as boas práticas
Não basta que o programa execute corretamente, é importante que ele seja legível. As alterações
futuras só serão possíveis se o código for bem organizado e as manutenções dependem do
entendimento do código. O processo de documentação se torna mais simples se o código for bem
organizado e comentado. E lembre-se: Mesmo o autor costuma ter dificuldade em entender um
programa complexo depois de algum tempo.
Uma última recomendação
Resista às tentações!!!
Só porque uma linguagem permite que se escreva uma expressão de forma abreviada e
complexa não quer dizer que seja a forma correta de fazer algo. As demonstrações de domínio da
linguagem só impressionam programadores novatos. A qualidade do programador está na
qualidade do código que ele gera, não na complexidade
O que é um código de qualidade? É um código correto, facilmente entendido, auditável e de

manutenção simples.
37

 Tutorial POO 
Você sabe o que esse código faz?
int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
(Um dos ganhadores do 1st International Obfuscated C Code Contest, 1984)
38

 Tutorial POO 
39

 Tutorial POO 
40

 Tutorial POO 
41

 Tutorial POO 
42

 Tutorial POO 
43

 Tutorial POO 
44

 Tutorial POO 
45

 Tutorial POO 
46

 Tutorial POO 
Muito legal, se o objetivo é ganhar o concurso de C “ofuscado” (ou servir exemplo nesta
discussão), mas, fora isso, o código bagunçado como estava antes não serve para mais nada.
47

 Tutorial POO 
Conclusão
O desenvolvimento de sistemas é uma das atividades mais interessantes e mais complexas na
área da computação pois integra os mais diversos assuntos como Sistemas Distribuídos,
Engenharia de Software, Estrutura de Dados e Multimídia.
A grande dificuldade no processo de desenvolvimento de um sistema se deve à sua

complexidade, ele é um processo multidisciplinar e exige a participação de bastantes pessoas se
o objetivo é construir algo grande. Uma das minhas principais dificuldades que encontrei no
desenvolvimento de sistemas foi a quantidade de tarefas de deve ser feita para atingir um
pequeno objetivo (teoria do Iceberg, lembra?).
É recomendado que se crie um grupo de pessoas, cada um com um conhecimento específico que
esteja relacionado com as tarefas que devem ser executadas para se desenvolver um bom
sistema.
Espero que este tutorial sirva como um estímulo para o desenvolvimento de outros trabalhos
voltados para a programação. Principalmente em regiões onde ainda não há muitos
programadores.
O autor deste tutorial é Marcelo Cavaco, formado em Processamento de Dados pela Faculdade
Rui Barbosa e formado em Engenharia de Produção pela Unibahia. Já trabalhou como Analista de
Sistemas e Engenheiro e sempre teve um hobby, o RPG... mas esta é uma outra história.
Qualquer dúvida, crítica, sugestão, reclamação, comentário ou algo semelhante, favor mandar
um e-mail para marcelocavaco@click21.com.br.
48

Programação Orientada A Objetos

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

Programação Orientada A Objetos

Enviado por

Direitos autorais:

Formatos disponíveis

 Tutorial POO 

Por Marcelo Cavaco (marcelocavaco@click21.com.br)

Programação Orientada a Objetos

O Mundo ao Alcance de suas Mãos

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Fora isso, boa leitura...

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Compartilhamento pela mesma Licença: Se você alterar, transformar, ou criar

Termo de exoneração de responsabilidade

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Minha família, por me criar e aturar...

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Boas Práticas de Programação................................................... 29

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Como Utilizar este Tutorial

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Os computadores não são apenas máquinas, mas ferramentas de amplificação da mente. As

As soluções para se implementar “Tipos Abstratos de Dados” (TADs):

a) tipos compostos, funções e procedimentos;

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Paradigma é um conjunto de regras que estabelecem fronteiras e descrevem como resolver os

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Programação Orientada a Objetos

O que é Programação Orientada a Objetos?

É um paradigma avançado de programação que engloba um conjunto de teorias, padrões e

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

E o que são Objetos?

Um objeto possui então atributos (dados) e comportamentos (métodos, procedimentos, funções,

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Mas, afinal, qual é a diferença entre Classe e Objeto?

a) Classe: é definição do tipo, ou seja, é o código fonte de seu objeto;

Figura 1: Diferença entre Classes e Objetos.

Um exemplo real da utilização de objetos que podemos usar é a montagem de um computador.

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

a) A placa de vídeo encaixa no slot ?

Conceitos Básicos de POO

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Este é um conceito CRUCIAL de programação orientada a objetos. Com ele podemos

A programação convencional separa dados e procedimentos.

Representação de uma classe/objeto

Operações / métodos / interface

Dados / propriedades / atributos

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Exemplo de objeto: Lâmpada.

O encapsulamento é definido como uma técnica para minimizar as interdependências entre

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Proteção da informação (information/data hiding)

Figura 6: Data hiding.

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Podemos observar melhor o funcionamento do data hiding através da analogia do Iceberg.

Figura 7: Analogia com um Iceberg.

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Algumas vezes, durante o processo de especialização, a sub-classe precisa modificar o

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Passagem de mensagens (parâmetros)

Figura 8: Passagem de mensagens.

Tutorial criado por Marcelo Cavaco (marcelocavaco@click21.com.br)

Nada mais é que uma relação entre classes (tipos de objetos).

Através da herança, desenvolvedores podem construir novas

Figura 11: Definição

Figura 10: Outro exemplo de Herança